Project goal & sprint structure
Introducing WakeyUppy, the concept alarm clock app to motivate the bleary-eyed morning snoozer to spring eagerly out of bed. After the alarm sounds, if the user hits snooze they first need to swipe through preselected images that remind them of their motivations, targets, and goals, transforming early mornings into productive time and not a battle against the snooze button.
I followed the product design sprint methodology designed and advocated by Google Ventures in their book “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days”.
App user flow
Customer map & sprint target
To begin the design sprint I determined the long-term goal of the project:
For users to spend 1-2 hours productive morning time working towards projects or goals.
I wrote a list of sprint questions to determine what we could answer with the sprint, asked experts (in my case researching sleep patterns and what motivates people), created a flowchart showing how customer map and how they will interact with my product.
Lightning demos, notes and ideas
After picking a target for the sprint on Monday, on Tuesday I looked at existing solutions (lighting demos), and sketched out ideas and solutions for different stages in the app journey.
Choosing solutions & storyboard sketch for prototype
On Wednesday I chose the sketches of solutions I felt would work and created a storyboard plan for the prototype.
Sketch screens & InVision prototype
In order to prototype the alarm app I downloaded and learnt how to work with Sketch and InVision which came up in my research as a recommended toolset for prototyping.
The final day of the sprint involved interviewing users and watching them use the prototype – I interviewed five users and used the ‘Five Act Interview’ script by user testing expert Steve Krug.
“The best results come from testing no more than 5 users and running as many small tests as you can afford.”
– Jakob Nielsen
Following the interviews I created a new journey map to show the user context, user actions, emotions and thoughts, and insights and recommendations.
Review of design sprint
At the end of the sprint, I reviewed my goal, sprint questions and patterns that came up in the interviews, and worked how to follow up after the sprint.
This included implementing design changes following struggle points for the user, a plan to iterate, test and re-evaluate assumptions.
This also involved an evaluation of the inclusive/universal design aspects of the app and how to increase accessibility to enable further ease of access for users. As a designer, it’s essential to take the responsibility to design for functional limitation. If I were to continue the WakeyUppy project I would be sure to test the app with a wider spectrum of users/experts to see how it works for them and address any barriers in this early development stage to ensure it is usable by the widest range of situations without needing a separate design.
A further point that I would concentrate on if developing the app further would be to ensure that it can be responsive to the changing needs of the user.
“People’s lives aren’t static, so why are their user experiences?”
– Rohini Vibha
This could involve ensuring the app is flexible to suit changing needs of user and accounting for the inconsistencies of life without causing the user to be demotivated. This could include a setting to pause the alarm app ‘run of x days’ while on holiday or recovering from sickness.
While the goal of this project was to explore the sprint phase of developing the UX of an app and not develop a pixel perfect design, I did develop the beginnings of a visual design system for WakeyUppy.
I created a UI style guide and laid up the key screens used within the app. Traditional digital UI patterns of dark type on a light background are recognised to be easier to read and kinder on the eyes than dark UI. However I chose to maintain a contrast, but develop a dark UI due to the nature of the app and where users would be viewing it. As an alarm app, this would most likely be in the morning, having recently woken up. I wanted to ensure it wouldn’t be too harsh on sleepy eyes.
Having said that, this is something I would choose to A/B test with a light UI design at an early stage to ensure my assumptions are backed up, and to test if this would be a detriment to the accessibility of the app to a wider range of users.
I chose to keep the colour palette pretty muted, with all text to be an off white (not white as too harsh) to light blue dependent on text hierarchy, on a dark grey/blue background. The brand green colour would be used on primary buttons and text links consistently throughout the app so users recognise these as clickable items.
The Google typeface Roboto was chosen for its clean geometric shapes and friendly open curves. As it has a large range of cuts, headlines and body text can use the same typeface but bolder or lighter cuts for emphasis and hierarchy.