PAUS.IT
Year: 2020 (11 Weeks)
Team Size: 4
Category: Phone Application
Overview:
Challenges:
Paus.It is the brainchild of 4 Designers who took a different direction to solve a problem than they had ever taken before.
Paus.It, in essence, is a productivity application that is designed to give the user more time by creating Pause's (lockdowns) in various distractions that appear around the user on a regular basis.
-
Helping conventional and unconventional students in a broad sense.
-
Generating conversation that allows us to understand what the user wants or is lacking from their life
-
Visualizing an application that can solve user issues without having an initial idea.
Meet the Team
Brianna Shepherd
Sydni King
Anthony Jones
Uchenna Uzuegbunam
As we completed this project the team would switch off between different roles, we never designated any specific titles as we completed the project. We all shared the responsibility of analyzing interview data, defining user requirements, generating personas based on research and interview data, and directing one another on the direction we wanted to take the project in.
My Role:
Team Lead, UX analyst, and Visual Designer
Vision Statment
"
We want to give students a way to 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.
"
Research
Understanding Our Problem
We actually started with some general questions and to the team and me, it did seem like users wanted to socialize and connect on their campus more. As we went through about 2 phases of questioning we found that students didn't have much to say about their social life besides that they were pretty content with their level of socialization. So what should we do? What were we missing?
Social Application Audit
We did two different audits. One for a social application and the other for productivity application
We did audits, ran interviews, learned we were moving in the wrong direction, and completed new audits that still ran alongside our questions, but gave us new light on the competition.
Productivity Audit
.jpg)
We ran in 14 in-person Interviews, our interviewees were generally non-traditional students who are working on a regular basis, commute to school, and a good portion do not have time for on-campus activities. We found that this population of a student who is generally very busy, but also really organized, so it wasn't about creating a new organizational system, but about giving them time to enjoy very simple things.
We asked our interviewee's general questions that were generally open-ended in an effort to keep them talking. We broke this questioning up over the course of 5 weeks and reviewed our information after each session.
We looked at User Behavior Patterns using various keywords that often popped up during our research
We went into the assignment expecting to learn the opposite of what we found in our users which was so interesting
Through our affinity mapping and sorting behavioral patterns besides learning out the interview pool was primary non-traditional students we also learned a lot of them were introverted, hard-working, single, and managed their time really well.
.jpg)
Non-Traditional Students
Traditional Students
We needed to make something that was outside of our original plans!
But we still really had no idea even at this point and we were working on truly understanding what it was out user wanted. We researched the majority of this project. Spent half of our timeframe gathering information about our users.
We found that our users were introverted students, with good time-management and organizational skills and actually no desire to interact with other students or participate in on-campus events. We did learn there was a flaw in the way our school was reporting events, but ultimately we were moving in a direction that pulled away from a socialization app.
Our users were no lonely, they were comfortable with their social systems and their only discomfort came with how little time they had.
Modeling
The personas are fictional representations of our ideal customer, a conglomeration of all the research shown above. Our primary persona embodies the majority of our research, while our secondary persona is the representation of the minority. The secondary persona has the possibility of using the application, but they are less likely to use it and not necessarily whom we are considering as we create the application.
Our Users
Jenny
is the primary persona that we created based on the primary issues that we found in our interviews.
Jenny did change a lot as the process changed. When we switched to a productivity application some of her goals changed as well, but everything else is relatively the same
For Jenny, it wasn't about managing her time or expressing herself artistically. Now Jenny needed headspace and break for her hectic schedule. She needed to disconnect and reevaluate
Thomas
Our secondary persona that represents our extroverts that care about their social life and socialization as well as being generally a traditional student.
Thomas's goals stayed relatively the same throughout the change since his goals weren't our primary focus he fit well still within the confines of what we needed for him to work with our application.
Framework
Developing our Framework (Wireframes, key paths, and prototypes) was our next step. We had to think what were the major functions that Jenny (primary persona) was going to use and how we could streamline that for her. What were her motivations for using the application and what were her steps through the application?
We generated the main functions of the application. This covered the development of what we thought might be possible features for the application, but nothing was set in stone.
Our "Lockdown" application had 3 major functions which were to schedule a lockdown, a timer for quick lockdown, and settings that allowed the user to customize what we assumed were maybe important features at the time.
Generating a Key Path for Jenny actually helped us develop possible screens before the user testing. Thomas's Key Path was more like our validation scenario in combination with the sort of third their functionality of the setting menu.
After developing the User's key paths we now had a sort of full wireframe to work with to develop the full application wireframe.
The full wireframe displays simplified screens of the keypaths of our users as well as a simple version of the settings menu.
All of this was subject to change once we began user testing and developed a low fidelity prototype
Usability Testing
Low Fidelity Prototype
We used a working digital low fidelity prototype to do our user testing. We had priority questions, task-based questions, and post-task questions to ask users as we did the testing.
We faced a couple of issues with finding users to test. We tried to contact the interviewees from previous interviews as they had spoken on wanting to see somewhat of a finished product, we received no response back.
New users had a general idea of what the application was about and how to go about using it. The biggest issue we ran into was users wanted to do tasks that were implemented into the application (before we began task-focused questions).
Once we began to work with users on task-centered questions they navigated without issue. We found users often wanted to change the color and integrate music into the application so that they could play,pause, and skip music while their phone was locked down.
Challenges
Users were largely attempting functions that we had not yet created or were not really intended for the testing.
Users could not see the difference or the individuality between us and our competitor.
Creating streamline navigation between the home screen and other functions
A list that allows users to view upcoming lockouts.
The auto-response function needed to be added.
Feedback
Refinement
The process started with creating another function tree. Still considering our key path we were essentially nailing down and confirming what already was happening with the application's production.
We made it so the timer served one purpose and the schedule would the heaviest load with being able to schedule an event and see what was upcoming.
Our settings now included auto-message, turning on notification, changing the color and changing time (military time, timezone, etc.)
Our refinement process was relatively simple. We added to what was already essentially working and working well. Updated colors inside the prototype, added more functions in the settings that matched branding guidelines and what made sense for a bit of what we added to the application after receiving user feedback.
High Fidelity Prototype
At this stage in the project, issues began to arise with COVID-19 and we had to halt on further usability testing. We were planning to run a couple of A/B tests to check on aesthetic changes in button color as well as changing the color from blue to green as our spot color.
We also planned to test the layout of the application on the calendar screens with more A/B testing.
Our only issues with implementation were that we were unable to add additional screens to implement a music function.
Closing Thoughts
When I first started this project since we were essentially starting with no concrete idea, we just wanted to help students in some capacity. This idea that essentially did no exist went through many stages to become the final product which I am quite proud of.
We began with so much research and very little ideas, nothing concrete and we were often chastised for it since we often times we were unable to explain our idea as it did not exist. We presented our findings, explained what we saw the largest issue and had to take multiple steps back to understand that we were still thinking to large.
We had done all the group work and all we need to do was bring it all together and I am truly happy with this final product.
