Hearticle (Summer 2016 - Spring 2017)
Role: Primary Designer on Personal Project
Timeline: Summer 2016 - Spring 2017
Key Activities: User Interviews, External Research, Task Analysis, Wireframing
TL;DR: 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.
Hearticle is an application that tracks the articles a user reads for easy look up. I worked on this side project independently starting in June of 2015, conducting exploratory user research and a task analysis. In February of 2017, I focused on designing the application.
Users of the internet consume a large volume of content in a given day, and there’s no easy way to have all of these documented to refer back to something that you may not have thought important at the time. Other solutions such as history are nearly impossible to sort or filter through, especially if a user visits a large number of pages in a given day.
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.
- 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.
- An enormous amount of content exists on the web that isn’t every accessed or seen.
- 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.
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.
The nature of sharing articles will naturally increase the volume of articles that a given person is exposed to. It’s nearly impossible to scroll through a twitter or Facebook feed without running into an article that is interesting enough to at least open.
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. However, there is a nonzero possibility that many of these skimmers wish to return but are unable to locate an article they read. That is, because of a lack of context (resulting from a shallow skim vs in-depth reading) it is significantly more difficult to create a relevant search that can lead back to the original article.
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:
- Do you read a lot of articles on the internet?
- Do you keep track of articles that you read and like?
- 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:
- Note-taking services - services like Evernote have extensions to “Save to Evernote” and organize them inside different notebooks/folders
- 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.
- A Piece of Paper - one can write down article names
- 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
- 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
- Bookmarks - users can organize their bookmarks and keep articles there for reference
- 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)
- 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, so the user wouldn’t have to determine what is important or not
Easy to navigate - there would be a great volume of articles if everything is logged, so there needs to be some easy way to go through all of that data in a digestible format
Powerful organization - when dealing with a multitude of articles, there needs to be some level of labels, folders, or tagging that makes this easier digest. This would have to be automated since the logging is automated.
Search - someone will always have keywords for what they are searching for and an effective search would be the easiest way to find an article they are looking for.
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 - 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, or pretty much anything of value from your browsing history other than figuring out individual pages. As in, there should be history showing different threads of discovery.
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.
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.
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.