Metro alarm — a UX case study
How I practice for design interviews with design challenges
Project Summary
It’s common practice for design candidates to receive design exercises during the interview process. I tested myself on a design challenge that I created myself and learned a lot in the process. I hope this case study can help you practice and prepare for your own design interviews.
The Design Challenge
“Have you ever tried to take a short nap on the train only to wake up and find yourself at the end of the line?
How can you help passengers wake up just before the train arrives at their station?”
This problem came from research I did on Product Hunt. I have a method that I use for coming up with design challenges which I detail below.
If you want to practice doing similar design challenges, I have created a collection of design challenges you can do yourself at uxchallenge.co!
Why I Worked On This Challenge
I wanted to see how I would do if I received such a design challenge as a whiteboard exercise during an interview.
It took me about 45 minutes from reading the challenge to doing sketches. It was extremely helpful to work with a problem solving framework to narrow down the focus of the design solution.
I also wanted to see what it would be like to do a finished design as a take-home exercise. In addition to brainstorming and sketches, another 12 hours were spent on user research, visual design and prototype creation.
Overall this project took way longer than I’d like! But I believe with practice my thinking process can be clearer and my execution can be faster.
Using Jobs To Be Done framework to solve a design challenge
I used the Jobs To Be Done framework to develop my design concept. The step-by-step process helped me break down the challenge into smaller problems that I could solve one at a time.
1. Specifying End User
“Passengers” were given as end users in the challenge. This is quite a broad group of people so I narrowed it down to a specific type of passenger who would ride the train: “Commuters who take the metro to and from work.”
2. Creating a Job Story
Keeping the end user in mind, I created a Job Story based on the Jobs To Be Done framework.
“When I take a nap on the train during my commute, I want to wake up when my stop is arriving, so I can get to work or go home on time.”
3. Creating a Quick Proto-Persona
I created a proto-persona that included demographic, goals and behaviors. This helped me start to envision the kind of problems that such a user would have.
This proto-persona was based on a lot of assumptions that required further research for validation, but it was a quick way to guide myself through the challenge.
To save time, I didn’t create a fancy layout and I skipped picking a user picture.
4. Listing and Rating Desired Outcomes
I listed and rated the users’ desired outcomes by how important they were and how well-satisfied they were with current solutions. This enabled me to prioritize and pinpoint exactly how my solution would solve the users’ problems better than the current solution.
First, I listed the desired outcomes that our proto-persona would like to have.
Then, I rated the importance of each outcome.
I assumed that the user would be using an existing solution like the out-of-the-box alarm on their phone, and rated how these outcomes would be satisfied by the alarm.
Then I used this formula to calculate the opportunity score of each desired outcome
Importance - current satisfaction = opportunity
I simplified the formulas from Lean Product Playbook’s Importance vs. Satisfaction matrix, the Gap Analysis and Jobs To Be Done opportunity score calculation into this formula.
This simplified formula is easier to remember and use when doing quick brainstorming.
Some desired outcomes had a low opportunity score while having a high importance score. These outcomes are already satisfied. I categorize these as baseline outcomes, meaning that users expect all solutions to achieve these basic results.
At this point I was able to see opportunities to outshine the out-of-the-box alarm as well as basic results I needed to provide for the users.
**Note that so far the desired outcomes, the importance and how well they’re satisfied are all assumptions. For a real world project, in-depth user interviews are required to validate these assumptions.
5. Brainstorming Design Solutions
The cool thing about the rated desired outcomes is that no matter what form the solution comes in, we know the kind of results the solution should achieve. We can brainstorm all sorts of products that can achieve these results.
A solution could be a personal butler who comes with the user on the train. What about an AI-powered seat that buzzes when it’s time for the user to get off?
I chose to design a mobile app (boring! I know) that syncs with the metro system’s schedule and reminds the user to get off before their station arrives.
6. Coming Up with Success Metrics
The list of desired outcomes I came up with came in handy again. Besides conventional digital product metrics like user engagement or reviews, I also wanted to measure the success of the app by how well it delivers the outcomes that the users are expecting.
Some metrics I wanted to measure included
- Number of successful wake up calls (alarm trigger coordinated with GPS location and metro schedule)
- Number of alarms set when the app detects that the user is in commute
- Number of dismisses when alarms are triggered
- Number of missed stops from user feedback
- Amount of time it takes from install to setting up an alarm
7. Storyboards
My storyboard tells the story of how the persona, Stacey, uses the app when she’s commuting for work from Montgomery station, San Francisco back to her home in Concord, CA.
8. User Flow
Here’s the key user flow I created based on the storyboards.
9. Sketches
The user flow I created in the previous step made sketching the screens a lot easier because I was clear about the main actions the user needs to take in each screen.
My goal with the sketches was to quickly jot down my thoughts knowing that I’ll probably make some more changes when I create more detailed wireframes.
Wait, hold up right here!
Have you noticed the lack of something in the case study so far?
Yes, you’re right — user research!
Normally during an interview you don’t have time for user research, but after 45 minutes of whiteboard exercise simulation, I decided to expand the project to more like a take-home exercise that would take around 8 hours to a week.
At this point, the lack of user research was the elephant in the room. So far the design solution was built on top of a few assumptions that hadn’t been validated yet.
In order to find out what I got wrong, I decided to run a quick user survey.
User Survey
I used Amazon Mechanical Turk to run a quick survey about the common activities people do when they’re commuting by train to and from work.
Mechanical Turk is a great way to run quantitative surveys if you want to get results fast. You do have to be careful though because your target users need to be Mechanical Turk workers for the survey to be valid.
Since it is very likely that a good portion of Mechanical Turk workers commute via public transit, this was my chosen survey channel that allowed me to quickly find out more about the users and their behaviors.
I sent out the survey with a link to Google Form and got 41 responses in an hour.
One surprising fact emerged:
People often miss their stops because they’re using their phones not because they’re sleeping.
The survey also helped me validate some of my assumptions. From the results I gathered, people do set alarms to remind themselves to get off on time.
My survey results gave me some clues on how I could improve the experience with tactile queues — vibration — for users who are sleeping. But more importantly it helped me consider adding visual queues for people who are using other apps on the phone.
Wireframes
Visual Design
Using Material Theme Editor
Since this is a new product, I used Material Theme Editor to quickly come up with the color the typography system. This saved a ton of time since Material Design plugin in Sketch helps you figure out a whole range of shades and font sizes to use in different situations.
I chose a shade of dark green to emit the calmness of the commute, and chose a shade of orange to represent the warmly lit home that awaits the commuter at the end of the day.
Night Version
In the evening, the app goes into night version where the user can focus on their location and how much rest time that’s left.
When the user is approaching their destination station, the rest time goes into a shade of red, and the notification will soon fire.
When it’s time to get off, the app fires off a notification and also vibrates, so if you’re sleeping or listening to a podcast you can feel the vibration, and if you’re still awake you can see the notification.
Day Version
The day version gives the user a clean and uncluttered map for their commute. There could be a lot of things on their mind and I don’t want to give them more things to worry about!
When the user’s work station is approaching, the rest time turns red and the notification will fire.
It’s time to go to work! I hope this notification gives the users a good mood to start their day off right.
If the user is reading a kindle book, or playing a mobile game, the notification will appear over those apps and remind them to get off in time so they’re not late!
When there’s a delay or alert from the metro system, the user sees it displayed in the app and can tap to find out more about the delay and how long it will last.
Prototype
This is an animated prototype made with InVision Studio that illustrates some of the motions that would be shown to the user when they’re commuting.
A quick note on coming up with the design challenges
I went to Product Hunt and selected 10 popular product categories. Examples include transportation, smart home or fintech.
In each product category, I selected the most upvoted products and studied their pitch to identify the product’s target customer and the problem space. I then checked the feedback and reviews to see if the proposed solution satisfied customers’ needs.
If the product had a clear target customer group and a well defined problem, I rephrased the problems into a design challenge.
Key Lessons
I learned a lot from testing myself with this design challenge:
Be fast and fluid
The 45-minute whiteboard simulation was really exciting as well as terrifying because I had to come up with something from a very short brief. I find that having the mentality of being fast and fluid with ideas and assumptions helped me conceptualize a solution quickly, knowing that I have to validate the assumptions later.
Validate assumptions
I was able to discover new and important usecases that I didn’t know about by running a quick survey. Other types of user research such as user testing of prototypes or interviews will reveal even more insights about the needs and experience of users.
Use a system for visual design
Use a design system such as Material Design or an existing brand style guide. Nothing eats up time like debating between one shade of green versus another.
Utilize ready-made Assets
Utilize ready-made wireframe kits or visual design kits that can help you jump start the execution part of the design process. Thousands of these resources are free on sketchappsources.com and they will save you tons of time.
Practice your prototyping skills
There are lots of prototyping and animation tools out there these days, maybe way too many! No matter what kind of powerful features they offer, digging into them still takes time. This project allowed me to finally understood how InVision Studio works, and I’ll be able to create a prototype much faster next time.
It will probably take longer than you planned
This project took way longer than I expected, especially during the research and visual design phases. The good news is that I know where I got stuck so I can be more aware of my pace and move through those steps faster next time.
Practice Makes Better
If you’d like to practice with the design challenges that I created, head on over to uxchallenge.co and get started!
