Role: Primary Designer on Personal Project

Timeline: Summer 2016 - Spring 2017

Key Activities: User Interviews, External Research, Task Analysis, Wireframing


In order to address one of my own problems with finding articles that I had read, I worked through a product design process in order to explore the space and identify what a potential solution could look like. I conducted user research and a task analysis to arrive at principles for a solution. I then created wireframes and mocks of the solution. I hope to revisit this project at some point and potentially build it out.

problem Definition

Users of the internet consume a large volume of content in a given day, and there’s no easy way document and refer back to that information in an accessible format.


The target users here are anyone who consumes content through the internet. Now this covers a huge amount of people, but the largest population that would be reading articles with the greatest amount of frequency would be students and professionals focusing on a particular industry.


Strangely enough, the biggest constraint was the lack of constraints. Since this was a personal project, it lacked real-life constraints, which made it hard to figure out where a stopping point was and prevented it from teaching many vital lessons that a real project may reveal.



"13 Stats That Prove That Nobody is Reading Your Content (And What You Can Do About It)":

  • People spend very small amounts of time on most pages. Most people will bounce off of a given article immediately, or in a time that is entirely too short to have read with any level of depth.

  • Skimming is the most common pattern to read a given article, with little time with eyes focused on the end of sentences or the bottom of an article. The first few words of the first few paragraphs are the most likely to be read.

  • Sharing frequently occurs without any correlation to how much of the article is actually read. So, we share without really knowing what a given article is about.

  • Those who read an article for over 3 minutes were twice as likely to return.

So what?

The small amount of time spent on most articles doesn’t mean that a given user doesn’t get anything out of the article. In fact, the fact that people tend to skim through articles makes it likely that he/she remembers one or two lines that he/she thinks is important before leaving the page.


Since people share articles more than ever before, the average person encounters more articles than before.

Finally, the last point is what makes this problem seem viable to me. The fact is that the people who are most likely to return are those that read the furthest into a given article. It’s also possible skimmers wish to return but are unable to locate an article they read because they remember less of the article.

What is already known?

To get a better understanding of the problem and users, I interviewed six young professionals and college students who read a lot of articles online with the following questions:

  1. Do you read a lot of articles on the internet?

  2. Do you keep track of articles that you read and like?

  3. Have you ever liked an article and forgotten to log it? Did you ever find it again?

All of the participants I interviewed read a lot of articles, with varying systems for keeping track of what they read. However, for about half of them, their systems worked well enough that they didn't see it as a problem. For the other half, they would never find some articles and could benefit from a way to keep track of them all. 

Task Analysis - What is the current process?

There are several different ways one can go about archiving/keeping tracking of articles:

  1. Note-taking services - services like Evernote have extensions to “Save to Evernote” and organize them inside different notebooks/folders

  2. Read it later services - services like Instapaper and Pocket allow one to save articles to be read later, complete with tags for organization. Pocket also has a built-in social network for communicating about articles.

  3. A Piece of Paper - one can write down article names

  4. Sharing with people - when one finds an article interesting, he/she may send that article to someone, which allows them to search for it in their messages at a later time

  5. Sharing to a social network - when one finds an article interesting, he/she may share that article on Facebook or Twitter, and look back at their profile to find it later

  6. Bookmarks - users can organize their bookmarks and keep articles there for reference

  7. History - if a user doesn’t use any of these methods, he/she can try to dig through their history (which tabs have made extremely difficult to navigate through)

  8. Search - a user could try and piece together a Facebook or Google search based on memory that may lead to the article they are looking for

The overarching issue with the first five of these requires the foresight that a given article will be important and involve the manual effort of logging those articles deemed "important." If this logging process doesn't occur for any reason, the article may be lost.

Principles for a Solution

No foresight needed - a solution would automatically log articles

Easy to navigate - the first principle would lead to a lot of content, so there would need to be a digestible format for organizing the information

Search - an effective search would be the easiest way to find an article someone is looking for

Potential Solutions

Browser Extension and web app - this would be the most straightforward way for background gathering of data to occur and displaying it in an easy-to-navigate manner

Redesigning browsing history - the way that browsing history is presented has largely been the same since the beginning of the internet — just one big list with a bunch of times. Despite the commonness of various tabs (and how they interweave in and out of browsing histories), there is no part of browsing history that shows that idea, making it difficult to understand the path you may have taken to get to a given page. If browser history were to include timelines of different tabs, users would be able to understand their past more clearly.

Chosen Solution

I’m going to focus on a browser extension and webapp, due to technical constraints and concerns about user privacy and the fact that redesigning browsing history would require users to share their entire browsing history. 

What would a solution look like?

I started out with a few sketches of how the webapp may display data and how one can navigate through it and how the chrome extension may look. 

2016-08-03 20.42.27.png
2016-08-03 20.48.38.png

Electronic Wireframe

Higher Fidelity Prototype

My next step was to build out higher fidelity prototypes. I focused on creating the web experience, since core bookmarking would just happen through a browser extension.

The homepage presents the user with a series of analytics related to the articles they logged. The user would be able to set goals for logging a certain amount of articles each month. This is intended for users to increase their reading if they want to be consuming more. Also, it’s a very basic form of gamification to drive up engagement.


The search bar - which is available on top of each screen - would allow the user to search for an article at any given point when using the application. Since this tool is meant to aid in retrieval, I wanted to ensure users had clear access to search — especially since search is one of the most common ways to retrieve content in apps.

Scrolling down, the user would be able to see articles that they have recently read in reverse chronological order. This order is consistent with the mental model of browser history, since Hearticle is essentially just an improved version of it.

The user can choose to sort alphabetically from A-Z (or in reverse) by the title of an article, as well as by author or publication by clicking on the heading once for alphabetical or twice for reverse.

The user can also choose to view different feeds based on what articles they have logged, including stars, or by categories. A category based on the source and section of a publication is automatically generated, but the user can also enter their own custom categories (like “Category A” in this example).

If the user mouses over an entry, they can choose to edit or delete the entry. If they click the edit button, they are taken to the following screen. The user can also choose to star an article to be saved to a separate list. I hid this functionality to maximize readability and focus on content, since they may not necessarily be needed in most cases.

Here, the user can edit any information and correct any mistakes that may be made when the browser extension automatically logs information. This also where they can add new categories to the article.

If the user clicks on any of the specific entries from the list view, they are taken to the detail page, where they can see all of the information that is recorded, including the full text from each article, as well as a calculated reading time (based on average reading rate and words per article). 


Working through the development of Hearticle was a tremendous learning experience, helping me understand basic design research practices, gather qualitative data, and apply these findings towards my visual design. This is the first piece of product design work that I did entirely driven by an attempt to understand the end-to-end design process rather than by a assignment or project.

If this was actually built, I would need to validate certain the way I’ve structured sorting and organization and other design decisions through A/B testing. Specifically, I would consider trying out different amounts of information being available on the main view.