Rethinking newsletter distribution and other content sources

Bundl is a versatile web service for combining and customizing various content sources together in a personalized recurring digest.

Introduction & Appeal

The web is a very efficient venue for exchanging ideas; but has quickly become a hub of information glut. The combination of advertisers using the web as a primary medium with the aftermath of a user-generated content revolution [1] quickly created an abundance of various forms of content on the internet.

Journalists are becoming more and more information “managers”. They are behaving like human filters which due to the absence of boundaries (i.e. space limitations, like television's airtime or newspapers’ pages) typical of the digital world, verify and add context to what user-generated content they think to be relevant, and feed it onto Web pages or mobile applications.

Several forms of curated content have emerged as a result—including email newsletters, podcasts, and social news aggregation websites. Content can be found algorithmically, but various publishers leverage the humanistic quality of their selection, in which a human curator chooses specific content to share to a larger audience. This humanistic curation creates perceived value and quality to online content, and affirms the context in which it's delivered is something the curator's audience can relate with.

Currently, whether online users are conscious of it or not, they are also playing the role of a curator by shaping their own consumption of content as per their personal taste. Bundl aims to serve as a central platform for various forms of curated content to come together in a personalized manner for users.

From a product standpoint, I decided to pick email newsletters as the first type of content to cover, before expanding to other content sources. For the purpose of this case study, I will cover Bundl as a newsletter aggregation tool. Newsletters provide a great niche to start with because they correctly align with Bundl's highest level goal—to take a form of overflowing curated content, and allow it to be personalized into one channel.

The Challenge

Newsletters provide curated content with the convenience of arriving in your inbox, but can easily become daunting for users as multiple subscriptions arrive at different times and with varying amounts of content.

My Role

Conduct user research, evaluate the specific needs of various users, convey key ideas in initial mockups, execute high-fidelity designs, and ultimately design a functional experience.

Before I dove into research, I declared these high-level goals:

Note about Iteration: Usability tests and iteration were done in several rounds and for certain aspects of the project, but for the sake of this case study, I present a summary of iteration towards the end of the case study.


First, I wanted to take a general tally on the most popular newsletter genres to understand which curators and specific users to initially target. Finding the most favored genres would not only reveal a majority of potential users, but also let me consider the specific newsletters of said genres. I established a few goals for my user surveys: to obtain common subscription behaviors from recipients of newsletters, to probe the most popular categories of newsletters, and to find popular curators within those categories.

After surveying around 70 random participants, I found that about 90% of people who are subscribed to at least one newsletter are subscribed to two or more. There were also three popular categories between participants: software development, product design, and marketing. This is possibly due to the fact that there are an abundance of newsletters in each, as email newsletters are a popular marketing technique within the tech industry.

Going forward, I set out to conduct several user interviews pertaining to users subscribed to newsletters. Interviews provided me with a greater context of users’ attitudes towards newsletters, and allowed me to become mindful of any possible caveats or challenges to address in my design process. With user interviews, I planned to target and validate two specific assumptions I had previously made: newsletters are a valued form of curation, and newsletters tend to cause digital clutter due to the medium in which they're sent (the inbox).

I carefully constructed questions to avoid insinuating bias, taking a neutral standpoint as the interviewer. I wanted to avoid the common pitfalls of user interviews such as the query effect. Some questions I asked included:

After conducting around 30 interviews with various people that were subscribed to some number of newsletters, I observed responses and noticed some common trends to address.

There seemed to be an aversion to newsletters due to their disorganized nature, but still an apparent appreciation for the humanistic curation they bring.

To focus my results into a concrete declaration, I outlined prominent problem statements and concerns to address them. I based these statements on the qualitative data of my interviews, including behavioral anxieties about users' pain points and observed mental models of their current solutions. Materializing these anxieties into concrete statements would allow me to obtain a general audit of user concerns, and help guide further brainstorming and ideation.

Some key points and possible areas of concern I found were:

  1. Fear of unsolicited spam: newsletters arrive unprompted on an unpredictable schedule. (Concern: Allow users control over the email's delivery date)
  2. Fear of polluting inbox: newsletters afford a binary subscription, you’re either subscribed or you’re unsubscribed. (Concern: Introduce variability, users can gain back control by being able to re-tune their email frequency to daily, weekly, or even monthly.)
  3. Value reputability of content curators: the producers behind newsletters often have some sort of experience or wisdom. (Concern: Support popular newsletters that people know and love, and put an emphasis on discoverability by author)

Information Architecture

Before jumping into wireframing and prototyping, I decided to take an audit of all necessary pages, and solidify the information architecture. Staying true to the formal definition of information architecture, I aimed to simplify each form of content as much as possible. I conceptualized three main labels for which each form of content could fall into:

From these basic labels, I then outlined the sitemap of Bundl as a whole, reusing particular labels in various locations to promote familiarity:

Initial Sketches and Wireframing

While sketching out the designs for the delivery email, I made various design decisions regarding the content of each article/resource in the newsletter. After performing Google VC's Comparable Problem, I realized the necessary content for each newsletter could simply be: a main hero image, article header, and lead-in. Additionally, since Bundl is aggregating multiple newsletters, I decided to include the original newsletter author and their logo.

A newsletter article atom.

While the atom for each delivery email may seem like a simple task, compromises were made when considering developmental constraints. Since Bundl would be dynamically scraping other newsletters, a hero image, or lead-in description might not always be captured. To design for this, I planned to have placeholder illustrations relating to each newsletter genre, so all edge cases could be considered.

An article with placeholder hero image.

Onboarding & Signup

For the onboarding experience of Bundl, perhaps the most important aspect, I wanted to create a simple and to-the-point user flow while still being mindful of the main objectives I outlined earlier. To align my scope before jumping straight in, I referenced one of my high level goal as outlined earlier as the main direction for onboarding:

Nourish a personable and customizable experience for users to feel in control of the content in their digest.

Regarding this main objective, I considered the areas of concern I discovered while conducting research, and outlined how these steps could be taken in a basic user flow for the onboarding experience:

At the top level, I considered searching and filtering of newsletters and scheduling delivery essential aspects of satisfying customizability for users. I prioritized newsletter discoverability in the configuration step, as it would tend to users who are completely new to newsletters.

Since I was introducing a new interaction (bundling newsletter together) I wanted to stay cognizant of potential friction that could occur for users. When transitioning into low-fidelity sketches, I considered two principles to implement that could address this: framing and priming. Framing is a technique that influences decision making and judgement by manipulating the way information is presented. Priming is the activation of specific concepts in memory for the purpose of influencing subsequent behaviors. [2] Taking both of these into account, I designed a two-panel visual system that would allow me to frame each step of the onboarding process on the left, with a small description of the task to be completed to provide context. On the right, would be the task at hand. Here's some of my initial low-fidelity sketches of this concept with applications into the user flow as outlined earlier.

Initial onboarding sketches and concept.

After illustrating the basis for my signup process, I moved towards high fidelity. While creating hi-fi designs, I designed for particular edge cases that I didn't previously consider, and ironed out small kinks.

I utilized a static skeleton UI to prime each following step in the sign up flow. This allows the two-panel system to exist for particular screens that don't necessarily fit the schema. Furthermore, I decided to use a pin for email verification rather than a link for two reasons. First, a pin maintains consistency in the flow, making the experience one cohesive journey rather than needing to open email links in multiple tabs. A verification pin also has more innate advantages over a link, allowing the user to use extra devices (like their phone) to quickly confirm their email and move on.

For the bundling screen, I added a small microinteraction that displays the accumulation of newsletters during the process. I drew inspiration for this from eCommerce 'shopping carts'. I leverage the familiarity of adding items to your cart (or bundl) to progress the user through the act of bundling—a previously alien task. Additionally, displaying the current bundl allows the user to review their collection, and quickly remove or take count of the newsletters they added.

Testing and Iteration

In our first round of testing, we prefaced the product by describing what Bundl does for users (similarly to a landing page), and then let participants sign up through our hi-fi prototype.

After running moderated usability tests on five users (who have and have not previously had newsletter subscriptions), we found one recurring problem when interviewing participants afterwards. Users who hadn't previously had newsletter subscriptions had trouble finding where to start. One user, when followed up upon, didn't even realize there was a filter menu to display specific categorical newsletters.

My first intention was to make the filter menu more prominent, but after further consideration, I decided to add an extra step the onboarding flow remedy this case. Adding an extra step to onboarding runs against the grain of my main objective: to keep the onboarding simple and to-the-point, but adding a preliminary 'taste acquirement' step would streamline two user cases: newcomers to newsletters could enter their taste and be shown relevant newsletters rather than the default list (categorized by popularity), and experienced newsletter subscribers might see newsletters they're already previously subscribed to and remedy the need to search.

Outcomes and Onward

As I continue to build out the tangible version of Bundl, I plan to conduct additional usability tests to validate assumptions made over the course of the design process. There are a couple spikes and areas of concern for additional iterations and design sprints as outlined: