Case study: A Simple Todo App
I was recently fortunate to be able to participate in an intensive product design course which was generously offered by Jasmine Friedl and Tanner Christensen. Through the course, I and the other participants received extensive feedback from the course facilitators and other designers, and I have applied that feedback to this case study of a prototype todo app.
Todo apps are widely used, but different users use the apps differently depending on their particular needs. In order to identify the problems faced by users of todo apps, I conducted research to develop an understanding of the market and users’ needs.
You can see the prototype here or the all the slides.
Problem statement
Social media and other easily accessible online distractions make it hard for us to stay focused on our tasks and make it difficult for us to do our work efficiently.
Also, constantly switching between tasks may give us the false feeling that we are being productive when we are, in fact, not. It’s more important for us to prioritize tasks and work on those that are most important, rather than focusing on deleting small items from our todo list just for the sake of appearances.
The goal of this app is to help us become more aware of how we spend time in the process of doing those tasks and how productive that time is. It can help set some constraints on social media to reduce distraction and track the time we spend working on the todo items. When we have a better sense of the estimated time we’ll need to spend on our tasks, along with the validated time spent on the items for reference or personal/team reviews, we are able to manage our daily routines more efficiently.
User interview & Survey
Since I am still exploring what the issues are at this phase, I was hoping to use interviews to learn more about todo app users who either work full-time or as freelancers. I chose these categories because these users are most likely to work in an environment that demands efficient time allocation and in which a todo app could be most beneficial. My interview questions are available here.
Besides doing these qualitative interviews to get to know the users, I also wanted to conduct some quantitative research in an attempt to identify patterns in problem solving among users. I sent out a survey to which 24 people responded.
From my interviews and survey, I was able to extract themes among users and identify where I think the core problem lies. The collected data helped me to form a user persona whose traits align with the audience I am aiming for, and I referred to this persona through my product design process.
I identified the following common themes among the users interviewed and surveyed:
Theme:
- They appreciate easy set up (getting the app up and running quickly).
- They want to be able to add tasks to their todo lists simply and quickly.
- They are heavily distracted by social media.
- They tend to lose track of time.
From the interview/survey results and the themes I extracted from them, I was able to develop a list of potential solution based on users’ needs:
- Set some constraints on social media, apps, and online distractions.
(My research indicates that users are heavily distracted in this area.) - Manage time on tasks, then validate time spent.
(My research shows that users often lose track of their time and delay work.) - Generate a report showing where we spend our time on tasks.
(Users want to know better how their time is spent and how to improve their efficiency.) - Make it easy for users to manage todo lists, track time and set constraints in one place.
(Users typically depend on different tools to help organize tasks and track time.) - Add the ability to prioritize tasks via deadline.
(Users wish to prioritize todos mainly based on deadlines.) - Add the ability to easily add tasks and to search todo lists.
(Users want be able to easily find todo items.) - Reduce distractions from mobile by allowing device settings to be synced from desktop.
(Users want to have data sync cross platform.)
It’s very tempting to include many functions in our quest to help users, but all those functions might not lead us toward the target we’re aiming for. The MoSCow method helps to set the path of product planning and trim down the scope we need for a minimum viable product(MVP). The point is to get the product out for real-world testing so we can have feedback and continue iterating the product.
High-Level User Journey & Apps Actions
From the potential solutions to user problems developed from my research, I was able to construct a high-level user journey and the apps actions in sections. I planned two user journeys to make sure the flows follow how we usually approach our tasks.
With social media and other easily accessible online distractions, it’s more difficult than ever for us to stay focused through the course of doing our tasks. In order to handle tasks more efficiently, we must learn to manage digital distractions. This app helps us when we don’t want to engage with these distractions and maintain boundaries at work. The app also provides reporting that will make us more aware of how we spend our time and more informed about how productive we are. As a result, we are able to more efficiently manage our tasks.
Concept testing
Concept testing helps me verify if the flow and idea can be understood by users. I translated my two flows into two simple sketches labeled Concept v1 and v2 below. I produced the flows with pen and paper, rather than jump too quickly to wireframes, so that I would be pushed to consider carefully how I would place the elements in the layout and how they would connect logically. Early concept testing with pen and paper is valuable because it allows me to identify what works and what does not and to make sure that what I am creating is based on user needs.
In my testing, I started by giving users a few tasks to see if they were able to accomplish them. Below is what I found.
During the process, users were able to complete tasks assigned to them, such as create a todo and start a stopwatch. They also indicated that the app function doesn’t look cluttered with too many extra options. I’ve tried to avoid giving the user too many options so that the app does not overwhelm them and hinder their actions.
At this early stage, the following problems were encountered:
- I made a mistake by not including one major user concern in the “Block” apps section (later Focus mode for Do not Disturb). Users have a fear of missing urgent messages, so a total block function might be intrusive.
- Users feel confused of the icon used in the focus mode because according to them, it looks like it would kick on location services on the device.
- Through testing, I noticed that users were asking if the “start” stopwatch button in task detail would automatically start the timer. This flow worked, but it might be better to add another button on the timer page to actually “start” the stopwatch so that users won’t be confused.
Wireframes
At this stage, I translated the sketches to Sketch. While I was making the wireframes, I reconsidered some interaction elements at the bottom navigation. For example, I considered if I should have the add button in the bottom nav, why the menu is on the top left, why the search icon sits on the top right, etc.
I then decided to stop my work and go back to the problem statement and user research findings. Revisiting my research put me back on the right track regarding the elements and interactions, and I was able to make decisions about them confidently.
Add a todo will be the primary task on the todo screen, but not for the other two functions (Focus, Report). I decided to keep the task within the todo instead of moving it to the bottom bar; when the todo list gets long, it’s a quick and easy for users to access it, as well.
The search should still be kept to the top right, as it is not the primary action in the todo screen. It works for a quick search, and it functions as a sub-action compared with the “Add” a todo.
Finally, account should be placed in the bottom bar, as it is also a high-level navigation that contains profile and settings. It should not sit on the top right alone.
Style guide
Our target audience is users who find it difficult to concentrate on digital tasks at hand due to online distractions. Below is the theme created for users with that goal in mind.
The style is content-driven, with relevant content displayed with a minimalistic approach that allows users to focus. The style avoids complicated usage of colours, helping to reduce clutter, give room to breathe, and reduce noise and distractions.
Since this is a todo app, my goal is to help users to feel calm and productive when starting to deal with tasks. I researched the effects colours have on people and discovered that blue provides tranquility and vibrance, and that orange inspires activity and productivity.
I based my font size on 16px where users will read most, such as the todos. Smaller text is used for secondary info that users read infrequently. I tested the content on my device to tweak the font-size and ensure readability.
UI exploration & iteration
User testing
For user testing, I selected users who were involved in the previous user testing, and I also included some new users. The age range of the users was from 25 to 45. They are currently working full-time or doing freelancing work.
After incorporating user feedback, I was able to make another revision to my slides.
Users were able to perform assigned tasks such as quickly adding todos and switching dates in the calendar. They were able to able to understand the time stamp next to a todo and associate it with the stopwatch.
Users appreciated the convenience of categorization settings, and they have the flexibility to selectively switch on Do Not Disturb in a batch without worrying about missing any important messages.
Users also have access to a report that provides the percentage of work and break time so they know where they spend their time and if they are being productive or not.
It’s important to note that all the users had a problem in the stopwatch section because it didn’t provide the affordance for them to perform certain functions. For example:
In No. 1, the users didn’t know when to tap the Calendar located on the top left, which will lead to the menu section and access a flow connected back to the main menu. These two are what confuse users the most. They had to click to see what that function provides. The users also don’t know where the reset button is.
Through this user feedback, I was able to correct my visual elements and tune the hierarchy due to the unnecessary date shown in V1 on the top left corner. In V2, users are able to navigate smoothly through this process.
Quotes from usability testing:
“…I like it when I see my report and get a better sense of how my time was spent.”
“Simple, I am not overwhelmed by other options. Focus mode helps me quickly switch on the Do Not Disturb when I don’t want games to bother me…”
What I Learned, and What I Could Have Done Better:
I perhaps could have benefitted from starting from a desktop app, because my target users are those who deal with digital tasks on these devices. Perhaps starting from a desktop app would give users a better sense of how the app would work for them.
Also, if users want to keep doing the same task the next day, the current app doesn’t track the total time spent a project; in an attempt to break down the todos into small pieces, the app treats each todo as an individual daily task. But with some tasks falling into the same project, it might be valuable to offer a function that allows users to see how much time is spent in total on a project.
Product design is a team effort. Every team member, anyone in the company, is able to give feedback, and feedback is crucial in helping us spot aspects of the product we might not have considered. It’s very important to share our work early. I have, in the past, been reluctant to share my work in its early stages before I was entirely confident with it, but now I realize how valuable it is to share. The process helps me correct mistakes before I move in the wrong direction and waste time. It also keeps me from getting too attached to my own design and makes me willing to accept good design feedback as I iterate.
Finally, I learn that there is no right or wrong in our design solution, and there is no perfect way to achieve a design solution. The only way to reach a design goal and perfect our product is through iteration and incorporation of user feedback. Iteration makes my design get better and better, and each iteration keeps me focused on the problem I want to solve. Input from design critique makes me look at the problem from different directions and helps shape a better product.
Special thanks to those who came to help me in testing, interviews, and participating in this case study. So rad! :)
