Designing Oro
TOOLS
Figma
Illustrator
Photoshop
InVision
ROLES
UI Design
Research
Writing
User Interviews
TEAM
Ridge Liggin (Team Lead)
Stephanie Epeagba
Erica Hester
TIMELINE
Feb - Apr 2020
(8 weeks)
Project Overview
ORO is a productivity app designed to accurately follow the Pomodoro Technique which is a time management method developed by Francesco Cirillo. The method consists of creating an Activity Inventory, a To-Do Today list, and tracking Records to optimize time spent working. The app idea was pitched to the class by our team leader Ridge Liggin.
This app was designed for our Interaction Design course, where we were taught the Goal-Directed Design method which focuses on users goals.
Goals
1. Design three main pages following Pomodoro technique.
2. Create onboarding process that walks the user through Pomodoro technique.
3. Keep the user engaged through motivating factors in the app.
4. Design a calendar that allows users to stay organized.
5. Allow customization to make the app feel personalized.
Our Approach: Goal Directed Design
Goal-Directed Design is a process created by Alan Cooper to aid designers in solving their problems with a process that focuses on user goals. The process is split into six phases: research, modeling, requirements, framework, refinement, and support. During the Research phase, our team completed a literature review, competitive audit, Subject Matter Expert interviews, and user interviews, so that we could best undertand the scope of our app. We then used our findings to move on to the Modeling phase, where we drew up our personas and their expectations. After this, we moved on to requirements, which we begin to consider what our personas expect from our app. We created a context scenario for our primary persona and used this to create a list of items we knew the app would need to satisfy their goals. Finally, we moved onto the Framework phase, where we began wireframing by walking through the key path scenario and supplementing this with validation scenarios. From here, were were able to develop our high-fidelity prototype.
Kickoff Meeting
At the start of our project, we met to cement the idea and develop a general plan for us to follow moving forward. We chose to brainstorm some ideas for research materials and potential users we could interview.
We also spent this time figuring out our problem and vision statement, as well as coming up with a persona hypothesis that we could use when finding interviewees for later in the process.
Research
Literature Review
Our team leader, Ridge, conducted the literature review for our team. This consisted of reviewing several scholarly documents on student motivation and productivity, and a book that details the Pomodoro Technique.
The literature review was important for us to brainstorm how we could implement different elements we derived from understanding the process, and was helpful in helping us develop questions for our SME and user interviews.
SME Interviews
We interviewed three Subject Matter Experts (or SMEs) to find out more information about the domain of our app. They offered valuable insight on different aspects of productivity and motivation. We asked them questions about their expertise in motivation and productivity, which helped to formulate the questions we would ask our users later. Additionally, all SMEs were professors which helped us to understand a different perspective on students’ productivity.
User Interviews
Before we could begin to conduct user interviews, we had to come up with a persona hypothesis. A persona hypothesis is an assumption of likely behavioral patterns that researchers make about a user to aid in the process of selecting individuals for user interviews.
We interviewed a total of four potential users, each with a different method of staying productive and organized. Each interview lasted a little over an hour, in which we asked the users questions about their daily lives, their current systems for staying productive, motivations, stressors, points of frustration, etc. Though we asked each participant from the same pool of questions, we tried to leave these questions as open-ended as possible so that we had the ability to ask relevant questions as they arose.
I interviewed two of the four participants and my teammate Stephanie interviewed the other two, though the whole team was present for each interview. After each interview we utilized the process of affinity mapping to find distinctive characteristics of each of our interviewees. We found out that each participant was heavily motivated by anxiety, and felt that a lot of what pushed their productivity was that they felt they had to do certain things, while hobbies or other personal projects had to be put on the back burner. Three out of four participants said they struggle with deadlines and often find themselves waiting until just before the deadline to turn things in. This was all information that helped us to create our personas in the modeling phase.
We gathered all of our data and research up to this point, and put it together in our research report. You can find the research report by clicking on the button below.
Research ReportModeling
Persona Creation
Using all of the information we gathered from the Research phase, we were able to draw up our primary and secondary personas. To create our personas, we followed these steps:
1. Group participants by role
2. Identify behavioral variables
3. Map participants to behavior variables
4. Identify significant behavior patterns
5. Synthesize characteristics and define goals
6. Check for completeness and redundancy
7. Designate persona types
8. Expand description of attributes and behaviors
You can view the full page versions of our personas by clicking on each of the profiles below. On the full page, you'll find more about them like their persona narratives, more of their goals, and more about their attitudes and frustrations.
Context Scenario
Once our personas were finished and we had appropriate representatives for our users, we moved on to writing the context scenario. A context scenario is how we can expect our persona to use the app on a typical day in the context of their lives. I wrote the context scenario for Katie, and to do this, I had to imagine Katie’s life based off of the characteristics we assigned her from our research. I then used the app as an answer to her frustrations. You can see the full context scenario by clicking on the button below.
View Context ScenarioRequirements
After completing the context scenario, we were able to understand what Katie would need to accomplish her goals. When putting the app in the context of Katie’s life, we could understand the requirements it would need to have. We pulled a list of 36 requirements, but here are some of the key ones we identified.
1. Check a calendar to see what’s due each day
2. Have an activity inventory or list of all the things to do
3. Move task from activity inventory to to-do today list
4. Add tasks to activity inventory with the due date and priority
5. See the remaining time left before a deadline
6. Select a task based on priority directly from to-do today list
7. Set 5 minute break timer
8. Set a 25 minute pomodoro/timer to work on a selected task
9. Keep brief record of distractions during each session
10. Check tasks off of a to-do today list
11. File documented interruptions
12. Organize tasks into specific categories based on user input
13. Track progress during the use of the app over time
14. Onboarding should be offered but not forced
15. Offer Katie profile creation and customization
16. Display visual analytics on records page
Framework
Key Path Scenario
Once our team established the requirements that our app would need, we moved on to wireframing. We started with developing our Key Path scenario, which is the most traveled path through our app. We used InVision Sketch for this part of the process, which was able to mimic pen and paper so we could erase and move things easily, but we were still able to collaborate.
Validation Scenarios/Full Wireframe
We completed most of the framework, by walking through the other possible paths our users could take. We used our requirements list to make sure we weren’t missing anything and developed the layout for a profile page, achievements, the calendar, etc.
This was a major help in the prototyping stage, where we had something to base our designs off of. We revisited this wireframe frequently throughout the prototyping process, to test out new design ideas and see what pages we could add or take away.
Prototype
Finally, once we had the screens mapped out and we knew what we were doing, we moved on to the prototyping stage of Framework. To create the prototype for our, we used Figma, a prototyping software that allowed us to collaborate online. Ridge took charge of creating unique interactions for our app, while we all worked together to design different features.
Three Main Pages
These pages are the Activity Inventory, To-Do Today and Records pages . These are the main pages that the user will use to record activities that need to be done, move them to the To-Do Today and begin their session, and where the distractions they record during their session will appear, as well as analytics.
Onboarding
Since this is a process that all users will not be familiar with, we offered them the option to see how the process works, and what each step entails. We included our pedagogical agent here, a friendly piece of paper designed by Ridge to help motivate the user with helpful suggestions.
Motivators
We wanted to include positive motivators in the app, since our primary persona is largely influenced by positivity and external motivation. Here you can see the screen the users will see when they complete all of their activities for the day, and the achievements tab that allows the user to view goals that will help them stay on track.
Calendar
The calendar is not explicitly a part of the Pomodoro Technique, but from user interviews, we found that visualizing due dates and schedules was necessary for users to stay on track. This was designed to look similar to a real calendar, but allows all of the calendar entries to be in a section below the calendar, so the information isn’t crowded.
Timer
The timer is one of the most important features of the app, as it is what the users will need to time their sessions and breaks. This is also where the user records their distractions, by pulling out the tab on the lower right. We also included a “focus mode” that allows the user to save battery while the timer is going and removes any distractions from the screen.
Profile & Customization
The profile is where our users can access the features that are directly related to their personalized experience.
Customization was one of the requirements we established early on. Not only was this something we saw in most apps we reviewed, but it was also inspired by our users desire to customize their physical planners and calendars.
Takeaways
I feel really fortunate to work with the team I had for this project, since they took it very seriously and were willing to work long hours for this idea to come to fruition. Considering we had to finish this project off during COVID-19 when schedules were crazy and motivation was low, we still came through and I am proud of us for that.
Of course, there is always room for improvement and I think we could have made a stronger product if we had done a few things differently. For instance, there were some issues that we came across when designing the app that could have been answered by asking the users in our preliminary interviews. I think that if we had a chance to do it all over again, I would try to ask deeper questions to the interviewees and focus more on the reasons behind their behaviors and not just what they did.
