Paus.It — A Time Freeing App


User Experience

Project Timeline

Jan 2020 — Apr 2020

Team Size


Project Goal

Enhance students

college experience


Project Overview

This project focuses on reducing the cognitive load for college students by providing an app that gives students a way to disconnect from their phones and remind them to take time for themselves in order to complete the activities and tasks that they would find desirable. Our team uses the goal-directed design process to reach a design solution that best suits our users goals and needs. 

Goal-Directed Design (GDD) is a design process learned within our Interaction Design program. This process starts with a research phase to discover information to help inform the design such as current technologies and users goals before moving into modeling to define what our users look like and what their goals. This research allows designers to define requirements for the product in terms of what it aims to do to help solve the user goals before finally creating the framework which is the actual wireframe design and prototype of the product which can be tested and refined to better meet user goals and expectations.


This page details and explains our goal-directed process for a mobile application designed as a class project. This page summarizes the steps that we took from beginning to end to establish the groundwork for creating our time freeing application as it establishes expectations, information on the potential domain, and ultimately user goals. The focus of our application is on the concept of proving a solution to help our users disconnect from their distractions and remind them to take time for themselves in order to complete the activities and tasks that they would find desirable.


The process for this project starts broad with exploring what the purpose and challenges our application seeks to achieve before narrowing into more detailed research, interviews, and finally a clear definition as to what our users’ goals are. The purpose of these steps are to set our group up for success when designing our application focused on our users’ goals. 

Meet the Team

Throughout the different stages of this project, members shared and rotated roles and responsibilities. These roles included recording key points during interview sessions, analyzing the data recorded, constructing personas based on research, defining user requirements, and testing those requirements to see if they are truly being met. 

My specific roles on this project include:

  • Team Lead

  • Researcher (Facilitator)

  • UX Analyst

  • Visual Designer

  • Information Architect

Brianna Shepherd

Uchenna Uzuegbunam

Anthony Jones

Sydni King


Kickoff Meeting

As the first stage of GDD, a kickoff meeting is held to define project goals and schedule further stages in the GDD process. Because this is a project and we have no real clients, we determined the contents of our kickoff meeting amongst ourselves. We accomplished this through the aid of a kickoff meeting worksheet that allowed us to understand and imagine what ideas and concerns may come up during a real kickoff meeting.


Competitive Audit/Lit Review

Before conducting stakeholder interviews, our design team reviewed any literature pertaining to our app domain. Normally, as a team, we would collect this literature and use it as a basis for developing questions to ask stakeholders and SMEs. Because we have no real stakeholders for this project, our literature review is used to give a deeper perspective of the domain we are venturing into. Click here to view audit.


User Research

Interviews & Observation

  • Who: 12 participants

  • Where: Kennesaw State University


Once we established who our users might look like we were able to create a set of questions to help jumpstart our interviews. Although we established a set of questions, we did not strictly ask every question or ask them in a particular order. Rather we simply had a gently guided conversation with our participants allowing them to talk 

about specific while utilizing open-ended and closed-ended questions when needed.

In order to have an insightful interview we had one moderator who focused on having a conversation while there were two facilitators who made notes and asked the participant to clarify points or speak more deeply about comments that came up in the discussion. In total we interviewed 12 participants which will be used to establish our persona once mapped and synthesized to create an application according to their goals in context of their life.

Interview Results

After completing the interviews our team affinity mapped to create discussion from each team member's viewpoint. Each team member wrote down important thoughts and details observed in the interviews on sticky notes before coming together to group them by similarities. This allowed us to discover key factors established by commonalities found in our research. We each placed our sticky notes on the wall and discussed with each other what we noticed others had written and where it lined up with our own thoughts.

Our team began this project with the assumption that our apps intention would be to help students enjoy their campus life by allowing them to explore events and organizations that take place on campus. After affinity mapping it was clear that our team had to move away from our original assumption we had for our target users. 

The main groupings that emerged covered personality type, time management, work-life balance, pain points with stress, where the participants spent the majority of their time, what participants did when they were relaxing, and how participants would spend their time if they had more time on their hands. These commonalities discovered between the participants determine what the goals of the users are and define areas that our application will help the user achieve.



Because we are designing for users, it is important that we can understand and visualize the important aspects of their relationships with what they want, with their social and physical environments, and with the products we hope to design. We have found that using our research to create descriptive models of our users, what we call personas, serves as an extremely powerful tool when designing toward user needs.


Personas provide us with a precise way of thinking and communicating about how groups of users behave, how they think, what they want to accomplish, and why. Personas are not real people, but they are assembled from the behaviors and motivations of the many actual users we encounter in our research.

There are two main types of personas:

  • Primary — The primary persona is chosen out of several models designed for the same scenario. It will be most suitable to serve its purpose and can be adopted by the majority of users.

  • Secondary — The requirements of the secondary persona can be fully met by the primary persona’s scope with some modifications.

Our design team began constructing our personas by analyzing the commonalities identified from our research. Based on those commonalities we discovered that our users goals were to have more personal time, more time for hobbies and interests, control the distractions in their life, and ultimately feel relaxed.


Meet the Personas



The sequence of events created during this stage is intended to understand the purpose of each persona – rather than paying attention to general user tasks, the design is focused on behavioral specifics of each scenario. The connection between all of the models in the project is set up in this phase. This establishes a completely goal-driven process with enhanced productivity since true priorities are better understood.


The objectives of this stage will direct the analysis and breakdown of our apps functions. This is accomplished through the construction of a contextualized scenario. Eventually, this leads to the requirements definition setting technological, business and consumer needs at equilibrium. 


Although our team had a sense of who our target users and what their goals are, we still lacked a clear product mandate, which left room for confusion. By creating problem and vision statements, we helped build consensus among the team before moving forward in the design process.

Problem Statement

Non-traditional students need a way to manage their time more effectively, in order to have time for themselves and their respective interests.

Vision Statement

Our app will help users manage their time which allows them to explore new opportunities, express themselves artistically, and relax without the frustrations they currently experience.

Context Scenarios

Next, our team used the descriptions of our personas, as well as data from the research phase, to identify what our personas will need in order to use our app.

After mapping out the personas expectations, we used those ideas to develop a context scenario. Context scenarios are usually narratives that tell a story describing one or more tasks in a specific environmental situation. 




Primary Scenario

While on her way to class, Jenny receives an email from her university. She is stressed because her professor sent an important email about an upcoming assignment that is due but she didn’t read the email until a week after it was sent. Jenny has to find time to complete her missed assignment with no distractions. 


Jenny frequently checks her course site to see if there are any new notifications about her course work. The course site has a calendar so that Jenny can see upcoming events and assignments. While looking at her course calendar, Jenny received a Twitter notification from her friend that she has known since high school. She pulls out her phone to check her Twitter. Jenny laughs at the content her friend sent her. After checking the notification, she explores topics that interest her. Jenny has lost track of time and checks her phone to see how much time she spent using social media. She opens the app and selects the schedule icon from her home screen. She then selects her preferred downtime and time interval for the day. Jenny has now scheduled future downtime from her phone to enjoy doing activities that matter to her.


Jenny realizes she does not need distractions and does need to focus on schoolwork during those grace periods. After leaving class, Jenny pulls out her phone and opens the app. From the home screen, she sets the timer 8 hour, cutting off all notifications and distractions before she begins her shift.




Secondary Scenario

Thomas is a social butterfly, always on the phone with his mother, always on twitter sending out general tweets on his locations, and promoting products for the various brands he represents. Thomas prefers to interact with others in person as a way to build his brand and network. He finds this troubling because of the amount of time he spends on his phone. 


Thomas is driving to a networking event in the city. Thomas is excited to meet new people so he arrives early. To pass the time he pulls out his phone and checks his social media accounts. Thomas has lost track of the time and is now late to the networking event. Thomas is frustrated. As he walks into the event, he pulls out his phone to use the app. From the home screen Thomas selects the timer. He then selects the duration of his preferred downtime and starts the timer. Thomas is relieved that he can now focus on networking during the event without being tempted to explore his social accounts on his phone.


Design Requirements

After analyzing our context scenario we were able to extract the personas needs. 

We decided to create a function tree to show the different features that will be needed in order for our persona to accomplish their goals while using the app. 

Our team decided that the primary functions of the app will revolve around the user having the ability to lock themselves out of their phone for the set amount of time.



Design Framework


Design Framework defines the overall structure of the users’ experience. This includes the underlying organizing principles and the arrangement of functional elements on the screen, work flows, interactive behaviors and the visual and form languages used to express information, functionality, and brand identity.

Our team began this stage by individually sketching each screen as we though it might look based on our prior studies. We then brought our ideas together as a way to generate discussion about our apps functionality. 


Key Path Scenario

After sketching the interaction framework, our team constructed a key path scenario. This scenario describes how the persona interacts with the product. The key path also depicts the primary pathway through the interface that the persona would take. We started by drawing out the key path for our primary and secondary personas.



Our primary persona just wants to make time for herself so she can do the things she enjoys doing in her life without being distracted by her phone. But because she is so busy and pressed for time, her key path consists of opening the app and scheduling downtime for a future date. 


Our secondary persona takes a different path. Since he is an active person and always looking for ways to meet new people. His key path would consist of opening the app and setting an immediate timer for the preferred amount of time he chooses to set. 



Prototyping is an extremely valuable step in the design process. Keeping the user at the center of the process required our team to test our designs on real users. We used prototypes to identify any usability issues or design flaws before it’s too late. 


After working through the functionality of the app, our team made a low-fidelity prototype to test with users. We decided to begin with a low-fidelity prototype because they are great for rapidly testing a design that is still broad. As you can see from the images below, the design of the the interface is very plain, there are not colors, and the elements are not visually appealing. This very boring version of our app is a vital piece in the design process. The primary interactions at this stage consist of the home screen where the user sets an immediate downtime, the scheduling screen where the user schedules future downtime, and the settings screen where the user adjusts how the app behaves. As we move into user testing, our target participants will inform the refinements of the design.


Usability Testing


Usability testing is a way to see how easy to use something is by testing it with real users. Users are asked to complete tasks, while being observed, to see where they encounter problems and experience confusion. Feedback is then collected from the user and then analyzed as the design moves toward the refinement stage.


  1. Observe participants while he or she completes a specific task

  2. Interview participants based on the list of interview questions


  • Low-Fi prototypes limited user interactions

  • Users focused on visual aspects of prototype

  • Recruiting the right participants

  • Some participants had limited time using prototype

User Tasks

Our team came up with 15 questions to potentially ask during the testing session. These questions were split up by priority, task, post-task, and maybe questions. Participants were given potential tasks to complete while using the app prototype. Here are a list of tasks that were created for user testing:

  • Set pause timer

  • Schedule downtime

  • Customize the app color

  • Change the timezone



  • Participants were able to complete tasks without any trouble

  • Participants felt welcomed and enjoyed the app concept

  • Participants informed aspects of the design that were irrelevant


  • Participants are not informed of upcoming downtime

  • Participants do not have a way to respond to contacts while in downtime

  • Participants want to be notified of scheduled downtime



The aim of this phase is to create a mature and detailed design specification to the goal of its persona. The process here is similar to that in the previous stage, only with greater focus on improvement, refinement and making the task-oriented structure and function more consistent relative to each other. 

After conducting usability sessions, our team sat down to reconfigure the functionality of our app. We decided to update the functions of our app based on the feedback given during user testing. Previously we knew that our app would have the ability to lock users out of their phone for the selected time frame. We had a general idea about the features that would make up our app but after testing those ideas with users, we had a better sense of what to build upon and what to get rid of. 




After reconfiguring the functions of our app, I sat down and began to create a high-fidelity prototype in Figma before going forward with more usability sessions.

High-fidelity prototypes are a more detailed and realistic version of what the final product will look and operate like. High-fidelity prototypes tend to include all the visual components, interactive elements, and content that will be featured on the final product. 



After I updated the prototype our team ran more usability sessions to ensure that our design met the needs of our users. 

These sessions were more focused on the look and feel of the app so we ran A/B Testing to determine which designs participants enjoyed more and why. Below is are examples of the designs tested during A/B Testing.

Original Design


Variation 1


Variation 2


Users felt that 'Variation 1' was the most appealing design. Our original design featured a red button for emergency calls when in lockdown mode. Although the red button is the norm when dealing with phone calls, users enjoyed the green button more because it made them feel happier and more refreshed as opposed to the red button. Users did not acknowledge 'Variation 2' due to the lack of color.

Final Product