Overview Introduction Challenges Method Research Kickoff Meeting Literature Review Competitive Audit User Research Interviews Modeling Visual Continuum Matrix Personas Requirements Statements, Scenarios, and Requirements Frameworks Interaction Frameworks Visual Design Framework Refinement Takeaways

Heading

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Heading

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Heading

Timeto

Introduction

Timeto is a personal task management and productivity tool designed to help habitual procrastinators achieve their goals. This concept originated in the questioning of the relationship between productivity tools available in the market and the kinds of users who would benefit from using them the most, but often don’t: habitual procrastinators.

Timeto

Challenges

Design a system that that doesn’t overwhelm users
Give users the autonomy to track progress
Help users stay engaged while achieving long term goals

Timeto

Method

In the following sections you will find a walkthrough of each phase of the Goal-Directed Design process leading to the final prototype. In each phase (Research, Modeling, Requirements Definition, and Refinement), respective documentation is provided in order to demonstrate the insights, challenges, and design solutions developed by our design team. This process was performed as a class project being conducted as part of the requirements for IAD3000 (Interaction Design I) at Kennesaw State University, and supervised by Dr. Michael Lahey.

Timeto

Research

The Research phase of the Goal-Directed Design is focuses on gathering qualitative data and relevant information on the subject, domain, and potential users as it relates to the product. This phase had six major steps: Kickoff Meeting, Literature Review, Competitive Audit, Stakeholder Interviews, Subject Matter Expert (SME) Interview, and User Interviews.

As team leader, I decided that it would be best to work collaboratively on the Kickoff Meeting and Stakeholder Interviews, and then assign each team member a section of the research process. I also made myself responsible for the User Interviews section, for which I took turns moderating and facilitating alongside Spencer Gillam.

Normally during kickoff meetings, stakeholders would introduce the project idea to the design and development teams, and designers would have the opportunity to ask important questions regarding the prospect users, business competitors, and potential challenges.

For our class project, an official kickoff meeting never happened. Instead of real stakeholders, the design team brainstormed and collaborated during an affinity map session with the goal of generating the necessary problem statement and the collection of assumption statements, in order to move forward with the GDD process.

Kickoff Meeting

Kickoff Meeting's Affinity Mapping session.

Literature Review

The Literature Review give designers the opportunity to explore relevant literature related to the product to be developed and its domain. This step is important because the resulting material is used as the basis for better informed stakeholder and subject matter expert (SMEs) interviews. This section was assigned to Nigel Jordan, who researched the subjects of procrastination, motivation, productivity, and the psychology of goal setting and achievement.

In his research, Nigel found out that procrastination stems from anxiety and a degree of self-deception. In other words, procrastinators are aware of their actions and the consequences of those actions, but stir away from the effort that is necessary to change their behavior. As a result, they are left feeling anxious and demotivated.

Nigel also learned that when it comes to setting and achieving goals, it is important to consider not just the internal state of mind during the process of goal pursuit, but also the external visualization and projection of those goals into the extrapersonal space of the individual. These insights helped inform and guide the following design decisions:

Simplify important data by presenting it in graphic, highly visual forms. This would reduce friction during user’s interaction with the product and at every step of tasks’ life cycle.
Reduce user’s cognitive load by stowing sections of the application into collapsible UI components.

Competitive Audit

In the Competitive Audit phase, the design team have the chance to review the systems, interactions, and interfaces of competitive products already established in the same domain. This step gives designers an insight into the strengths and limitations of certain features, as well as trends and design patterns of comparing products on the market.

In our team, Juan Kinshasa and Amara Bush were responsible for performing a Competitive Audit of the productivity domain. They tested and compared five different digital products designed to help users access high levels of productivity and organization. Some of the products reviewed include Reminders (iOS), 1-3-5 List, Rescue Time, Notion, and Google Calendar.

Based on their research, Juan and Amara highlighted the following observations:

Products' systems had either an overwhelming amount of structure (affecting customization), or very limited structure (affecting user experience).
Consistently low emphasis on data visualization.
Key interactions demanded high effort from working memory.

Project Timeto's Competitive Audit documentation.

User Research Interviews

In Goal-Directed Design, we use the technique of ethnographic interviews to gather valuable qualitative data to help us better understand users and their goals. This technique combines immersive observation and directed interview, and the focus lies on accessing interviewees’ contexts in order to better understand their attitudes, beliefs, and values, as it relates to the product’s domain.

The user research process began by establishing the Persona Hypothesis, a combined set of assumptions about the potential users to be interviewed and likely behavior variables to be observed. Generally, the team decided to focus on the types of variables related to interviewees’ activities, attitudes, motivations, and skills.

Due to the ongoing Covid-19 pandemic, user observations were not feasible. However, we were able to conduct a total of five online interviews with college students that fit the profile or our Persona Hypothesis; all of them conducted via Microsoft Teams. The chosen participants ranged between Sophomore-Senior year in college and were all residents of the state of Georgia. In the interviews, I took turns moderating and facilitating with Spencer Gillam, while the rest of our design team attentively observed and took notes.

Project Timeto virtual User Research Interview conducted through MS Teams.

Project Timeto User Research Interview Affinity Map.

To draw meaningful conclusions from the data collected during interviews, the team collaborated in sessions of Affinity Mapping using notes and observations collected during interviews. We created categories that the interviewees’ statements, emotions, and actions could populate and then organized these noted inputs into clusters by looking for patterns, connections, and affinities. This process was repeated after each user interview, and for every new Affinity Map created, more output information and insight was obtained.

Once the design team had a deeper understanding of the potential users for our product, their goals, and their needs, it was time for the development of a tangible concept that reflected the qualitative data and insight we had acquired.

Timeto

Modeling

The resulting synthesis of the information and qualitative data gathered during research takes shape in the form of Personas in the Modeling phase of GDD. Personas represent the synthesized behavior patterns, motivations, attitudes, opinions, and mental models observed during user research.

Visual Continuum Matrix

Once Research concluded, we engaged in critical discussion and collaboration to synthesize our data and construct our models. This process was broken down into the following four steps:

We skipped the first step of the Modeling Phase, where interview subjects are grouped by role, simply because we only had one user role: procrastinators trying to organize and monitor their tasks. So all interviewees fit right into the profile of our single user role
We identified the behavioral variables observed during user interviews and analyzed during post-interview Affinity Mapping sessions. Then we checked for redundancy and traced back each variable to a validating signal in our data. Lastly, we assigned each listed variable one of two classes: single continuum variable (more/less), or multiple choice variable (this/that)
We mapped interview subjects to listed behaviors by assigning each one a number (1-5) and plotting them in our visual continuum matrix of behavior variables

Visual Continuum Matrix of behavioral variables. Green and Red lines indicate grouping patterns. Purple arrows indicate trends.

We identified significant behavior patterns by observing clusters of represented user subjects. In other words, numbers grouped together indicated a strong behavior pattern. Since we were observing the same interview subjects consistently clustering together into two groups, we realized we were likely dealing with two different Personas
We synthesized the characteristics of the key behavior continuum for each of the two identified Personas and then defined their goals. We also gave them names and a picture so as to humanize their represented personalities
We designated Persona types in a simple process of elimination. In other words, by having Amy as our Primary Persona (user target), we would be able to make Timeto reach its full potential as a product, while also satisfying most of Josh’s needs, our Secondary Persona
Lastly, we expanded the profile description of attributes and behaviors by pinpointing Amy and Josh’s end goals, life goals, and narrative. This step is important because it helps bring the Personas to life, which in turn helps the team empathize with users when making design decisions and prioritizing features

Personas

Through relevant abstraction, Personas serve as a tangible and guiding user model for which the product will be designed. A successful product accommodates a variety of users by being designed for specific types of individuals with specified wants and needs.

Our primary persona, Amy, is in need of a tool to help her stay on track with academic and personal tasks. At times, she feels overwhelmed by all of her responsibilities, which can lead her into procrastinating habits. Josh, our secondary persona, considers himself a "proficient procrastinator", as he has managed to master the art of procrastinating and still delivering down to a science. All he needs is a centralized point of operation for monitoring on the go.

Primary Persona

Name: Amy Rodriguez
Age: 22
Main Occupation: College Student
Interests: Hiking, binge-watching Netflix and keeping up with her social media

End Goals

Get better at accurately sizing their tasks in order to avoid stressful situations
Break big tasks into smaller ones to serve as motivational milestones
Keep track of their schedule with minimal effort
Personalize task management tools to cover their needs

Narrative

Amy is a third-year college student. She just moved into a new apartment off campus. Amy has a part-time job as a barista. She desires high academic achievement due to family expectations, since she is a first-generation student. She wishes she was as organized as she appears to be, but in reality, she struggles to juggle all of her responsibilities.

Secondary Persona

Name: Josh Medina
Age: 24
Main Occupation: College Student
Interests: Working out, playing soccer, hanging out with friends on Discord, and playing games

End Goals

Keep track of deadlines
Schedule the most efficient block of time to work on a task
Get notified about their previously set priorities
Strategize the management of tasks
Minimize time spent working on tasks to maximize their free time

Narrative

Josh is a fourth-year college student. He lives off-campus and commutes to school daily. Josh is currently interning at a company and hopes he will land a job at the end of the year. He is very confident in his abilities to navigate college life. He doesn't feel guilty about his procrastinating habits--in fact, he embraces them.

Timeto

Requirements

The Requirements phase of GDD is perhaps one of the most crucial steps in the design process. In this phase, designers translate their research and empirical observations into design solutions that satisfy user needs, while also maneuvering technical constraints and addressing business goals.

Creating Context Scenarios involved the use of narrative as a design tool to contextually describe the user’s interaction with the system of our product. These were done in the form of a short narrative story of a day in the life of the Persona, while describing, at high level, the actions and expectations that they have with the product.

Statements, Scenarios, and Requirements

The Requirements phase was broken down into the following steps:

As suggested by Alan Cooper, our team began the Requirements phase by creating our problem and vision statements for this project. These were formulated from user goals defined in the Modeling phase, and additional input received during user research interviews regarding frustrations and opinions on competing products. The problem statement involved revisiting and rethinking the same statement created during our Kickoff Meeting, except now basing the alterations on newly acquired information from our research. And the vision statement was created by inverting the problem statement (which prioritized business concerns) and focusing on stating detailed solutions to our users’ needs
Next, the team brainstormed with the goal of generating ideas of product features that could bring solutions to our Personas' challenges
Our team then shifted its attention back to our Personas to identify and list their expectations. These expectations would later serve as the foundation for our Context Scenario and final list of our product’s Design Requirements. Persona expectations encompassed data needs (objects and information represented in the product’s system), functional needs (operations and actions required of the product’s system, usually in the form of interface controls), and contextual needs (the relationships and dependencies between objects in the product’s system). Some of Amy and Josh’s expectations included keeping track of deadlines, nesting tasks within activities, and setting custom reminders

Design team brainstorm session. Feature ideas organized by level of importance.

Creating Context Scenarios involved the use of narrative as a design tool to contextually describe the user’s interaction with the system of our product. These were done in the form of a short narrative story of a day in the life of the Persona, while describing, at high level, the actions and expectations that they have with the product. By pretending that the interface was magic, our team created Amy’s Contextual Scenario by suggesting creative solutions to interactions. This approach encourages boundless thinking in problem-solving for goal-directed behavior
Finally, we identified and listed out system design requirements by deriving the primary persona’s needs from its context scenario. In doing so, we were left with a total of seven requirements for the Primary Persona, and seven general system requirements that would satisfy both Personas’ needs

Primary Persona Requirements

Keep track of remaining time to deadlines
Set a time estimate for task completion
Add subtasks to existing tasks, creating an activity composed of a series of smaller tasks
Set custom reminders and notifications
Focused work mode with timer (countdown and breaks option)
Check important milestones and due dates in a calendar
Check progress and performance statistics

General Requirements

Onboarding experience
Task list with Timeto bars
Expanded task overview
New task setup
Calendar
Dashboard info overview
App settings

Timeto

Frameworks

In the Design Framework phase of GDD, we set up the structure of our product’s system interface through the organization of interactive behaviors, visual language, and functionality. This process began with the Interaction Framework and the creation of low fidelity wireframes, followed by the Visual Design Framework and the establishment of a visual style and identity.

Key Path Scenario diagram describing the Primary Persona's most used path: creating a new task in Timeto.

Interaction Frameworks

The Interaction Frameworks phase was broken down into the following steps:

First, our team defined the form factor of our product (mobile phone), its posture (ephemeral, short duration), and input method (touchscreen)
We then defined the functional and data elements our app would need to work properly. This step is closely related to the list of general requirements created in the previous phase
We determined functional groups and hierarchy by following principles of information architecture
We sketched out the interaction framework by creating low fidelity wireframes. This step was done in Miro using the built-in library of basic shapes and icons
We constructed the Key Path Scenario, which is the path the Primary Persona will go through the most while using the product. In Amy's case, her most used path was creating a new task starting from the home screen
Finally, we checked the framework design using Validation Scenarios, which are simply the less frequently used paths and/or the paths used by the Secondary Persona that don’t interfere with the Primary Persona’s experience

Project Timeto wireframes depicting the Key Path Scenario (red arrows) and the Validation Scenarios (blue arrows).

Visual Design Framework

The Visual Design Frameworks phase is all about creating a visual style and identity for the product. This process was broken down into the following steps:

First, our team created a list of Experience Attributes, which are descriptive words used to define, at high level, the tone, voice, and brand promise of our product
Being in charge of the Visual Design, I then began the process of Visual Language Studies by researching and developing a brand identity through a translation of our Experience Attributes into brand and UI elements such as colors, typeface, and icons.

Timeto brand guidelines

Project Timeto prototype components in Figma.

I started to create mockups of our User Interface by applying the elements from the newly created brand style guide to our screen archetype. I also followed a variety of design recommendations from Material.io
After a couple of iterations our Visual Design Framework was complete. For the last step, the team worked together to create a design system in Figma so we could begin prototyping

Timeto

Takeaways

Timeto was my first experience in Interaction Design where I took on a product design project comprehensively. It was also my first experience leading a design team. Reflecting back on all phases of Goal- Directed Design, I can confidently say that I have experienced a process that is truly user-centered.

It was very interesting to observe how our team kept tracing design decisions back to behavior patterns observed at the very beginning during user research interviews, and how this dynamic helped spark productive team discussions. In this design process I learned about the importance of research to the design practice. Learning about the domain, the competition, and most importantly, the user, are invaluable steps in product design.

If given the chance to rethink my approach to this project, I would have chosen to reserve additional time to work on the Refinement phase, given that the team was new to Figma’s features such as Smart Animate and Auto Layout. I would also have chosen to dedicate more time and resources to the usability testing of our prototype. Overall, I have learned more about product design in these few months than ever before, and I certainly feel more prepared for future projects.

Timeto

Heading

Heading

Heading

Introduction

Challenges

Method

Research

Kickoff Meeting

Literature Review

Competitive Audit

User Research Interviews

Modeling

Visual Continuum Matrix

Personas

Primary Persona

Secondary Persona

Requirements

Statements, Scenarios, and Requirements

Primary Persona Requirements

General Requirements

Frameworks

Interaction Frameworks

Visual Design Framework

Refinement

Home

Task Overview

Stats

Calendar

Timer

Settings

Takeaways