RANDOM Case Study
An iOS mobile running application that spices up running routines by giving runners customizable, random running routes.
RANDOM High-Fi Prototype + Voice Interaction Demo Video
Problem Domain: Health & Fitness
Running the same routes can get boring and sap a runner’s motivation to exercise, leading them to quit. Random is an app made to address this problem. Users run randomly generated routes intended to spice up their exercise life, bookmark cool locations they pass for future runs and reference, and get real-time stats on their workout so they can focus on becoming the runner they want to be.
Timeline: 3 months, Sep. 2018 - Dec. 2018
Role & Team: Student UI/UI Designer, Team of 4
Tools: Figma, Adobe XD, Adobe Photoshop, iMovie
Methodologies: paper prototypes, digital prototypes, ideation sessions, user interviews, usability testing
Final Product: hi-fi running app, downloadable from the iOS App Store
For our design process for RANDOM, we used these design methodologies:
POVs + HMW Ideation Sessions
Concept Video Creation
Lo-fi Paper Prototyping
Pilot Usability Testing
Hi-fi + Voice UI Demo Video Creation
Final Pitch and Poster Board Presentation
For this student project, different sections of the course had different themes. Our section had the theme of 'Voice Interaction'. All teams in the class had to develop a product that incorporated voice interaction of some sort. Focusing on this, we started to interview individuals on their experience with voice interaction technology in their daily lives.
For this stage, we interviewed 3 people from our personal network and Stanford community:
Victoria, a symbolic systems student at Stanford, approached her to do an interview in the Psychology lounge
Christina, our team member's aunt who lives near Stanford, known to use an Amazon Echo
Thomas, a Stanford technology specialist, tech gadget enthusiast
What kind of technology do you have that talk to you?
How many times during a day do you interact with voice technology?
Can you walk me through an example of when you used voice technology?
What kind of activities do you do while you’re using voice technology?
Do you pay for technology that talks to you?
Tell us an interesting story about a time when you were talking with technology.
How do you feel conversing with technology?
What would you like voice technology to do for you/help you out with?
My mom leaves Alexa on to deter burglars
I wish there were more personalization options
When required to perform more complicated tasks, I don’t not use voice interaction
Set timer/ask weather at least once a day
I try using it for getting recipes while cooking..
Sometimes Alexa just starts talking..
Doing something unrelated...and Alexa starts talking!
I don’t talk anything sensitive when around Alexa
It is frustrating sometimes
Alexa does not understand context
My wife is freaked out by these devices
They are limited in functionalities
Would love to get help from an assistant while taxiing on a runway
Voice interaction as an accessibility feature in cluster printers
Learning languages using voice interaction would be cool!
Empathy Map made from Interview Results
Insights and Needs Analysis:
"I like to use Alexa while cooking to get recipes. But most of the times she does not understand my request.”
Insight: It is a hassle for her to read/lookup the recipe while cooking and she wants someone to give it to her
Need: She needs a way to get the right recipe step by step on command while cooking
“My mom uses Alexa at home to play noises so burglars will think someone is in the house because our house was broken into.”
Insight: Her mom feels more safe leaving the house empty if there is something making noise to deter thieves
Need: Her mom needs a way for the house to make noises while she isn’t at home
“My wife likes the male voice, while I like the female voice. If we can put some ‘human-touch’ into the voice technology, my wife will be more acceptable of the technology.”
Insight: Thomas’s wife thinks voice interaction technology does not sound human enough
Need: There is a strong need to humanize voice interaction technology by personalizing/adding different preferences
“What do think about using a voice interaction system for learning different things?”
“Languages! Practicing and learning new languages every day.”
Insight: He wants to learn new languages
Need: He needs a language partner to practice speaking with
“There are too many emails and notifications for how to use it. I just ignore them. I don’t have time to read them.”
Insight: She doesn’t feel like she has the time resources to learn how to use her voice technology
Need: She needs an easy, quick way to understand how to fully use her voice technology
Needfinding Summary Points:
People like to use voice interaction services while cooking,
but current products don’t have satisfactory performance
Using voice interaction services/products to help learning (for languages) could be helpful
There is a strong need to humanize voice interaction systems
Voice interaction systems could be used for unconventional uses like security
Problem Domain: Health & Fitness
We met Victoria, a Stanford student.
We were amazed to realize she uses Alexa daily to track little things like the weather and timers for sleep and laundry.
It would be game-changing if we could help Victoria keep track of more significant parts of her life such as her health.
Additional Needfinding Interview Results:
Scott, met at a Stanford shopping center
He thought it would be beneficial for him to have a way of keeping track of his workouts stats and measure improvement over time
Marco, met at a Stanford shopping center
Marco thinks talking to voice assistants in public is weird and does not like when people do it
Josh, personal trainer at Training Space Palto Alto:
He said clients will pay around $3000 but then not show up. Ultimately, he says people have time to work out, they just need to prioritize it.
Jackie, met at a Stanford shopping center:
Jackie’s younger son in his early teenage years is type I diabetic. When she cooks for the family, she makes sure that the meal has minimum carbs.
Revised POV 1: Josh
a 24-year-old bodybuilder
owner of several fitness companies
Amazed to realize he had a personal trainer to help him.
Game-changing if we could help people design and follow lifestyle habits that work best for them.
Revised POV 2: Jackie
40 year old mother of 2
Amazed to realize that she does not keep track of her son’s eating and working out schedules despite his condition.
Game-changing if we could help monitor and correct people’s health.
How-Might-We Ideation Sessions
HMW Ideation Session
Experience Prototype Summary + Chosen Prototype: Exercise Surprise
First, people like the idea of spicing up their exercise life.
Secondly, knowing what’s in your fridge can be a pain when you’re not with your fridge.
Overall, we felt that ‘Grocer-Ease’ and ‘Friend Therapy’ would present significant obstacles moving forward.
‘Exercise Surprise’ was well-liked, viable, and focused on an issue we really wanted to address.
Value Proposition, Problem and Solution:
Value Proposition: Random runs you’ll never get tired of
Problem: Running the same old routes can get boring and sap a runner’s motivation to exercise, leading them to quit.
Solution: Run randomly generated routes to spice up your exercise life. Bookmark cool locations you pass for future reference, throw some body-building workouts in to spice up your run, and connect with other runners out and about.
Tasks and User Usability Complexity Levels
Simple: Go for a fun run
Run on new and exciting paths
See interesting sights and landmarks along the way
Program random workouts to do along the way
Moderate: Connect with other runners
Run alongside others trying out new routes in your area
Moderate-Complex: Get real time updates on your workout
Check your current stats (pace, time, distance, elevation, etc.)
Get recommendations for how to improve your performance and build your perfect workout
Complex: Mark cool places to check out after your run
Save landmarks, businesses, and places that you pass along the route for future reference
Get directions to saved locations for later enjoyment
Task Storyboards and Scenes
RANDOM Concept Video
Lo-fi Paper Prototyping
For this app, we considered two interfaces which we thought were most suited for a running fitness app. We considered the Apple Watch interface and the Apple iPhone interface for these reasons.
We thought the Apple Watch would have these pros and cons:
Very mobile and easy to wear during exercise
Is wireless so people can move more freely, no wires for headphones
Can have Bluetooth capability to wireless headphones to give voice directions/interaction
People need to have an Apple watch, not everyone has one or wants one
They would also need to buy Bluetooth headphones to use voice user interaction
Small screen is hard to display a lot of needed information like maps, full directions etc.
We thought the Apple iPhone (or general smartphone model) would have these pros and cons:
Everyone has a smartphone, do not need to buy a smartwatch to participate with the app
Not everyone can afford/has Bluetooth earphones, so being able to use wire headphones includes more people
Larger screen size gives people greater amounts of information + depth of information
Heavier object to run with
After debating between the two, we decided to go with the Apple iPhone interface because of the accessibility that it provides people given that most people in the US have this interface already. Additionally, it is compatible with both wireless and wired headphones, and provides more visual information to the user.
Lo-fi Paper Prototype Structure
3 Prototype Tasks:
Real Time Stats
Pilot Usability Testing
Lo-fi Prototyping Experimentation (Testing) with 3 Users:
For our lo-fi prototype usability tests we met with 3 users to gain user insights and critiques. During these experimental test, our group members assumed different roles:
CPU: this person changes the graphical UI as it would work in real life. Does not speak at all
Facilitator: facilitates the experiment, debriefs the user initially at the beginning, encourages the user to ‘think out loud’, and answers essential questions
Note Taker: takes notes about the whole meeting, especially of what the user reactions/interactions are with the prototype
Picture Taker: takes photos of the user and team throughout the user testing experiment
These 3 users were all runners, and 1 was a Division 1 college athlete.
3 Design Changes:
From feedback we received, we realized that after entering the miles and destination for a run, users would expect to immediately start running. Because of this we rearranged the home page to kick off the run immediately, with a small link beneath the RUN button for users to further customize their workout. There was also confusion during our user testing about what to input in the destination text box, so we changed the destination to be button options for “round trip” and “one-way.” If a user selects one-way, a text box will then appear beneath the button for a user to enter their final destination.
Since we modified our home page to allow users to immediately get to running, we decided to make the run customization page an optional link for users to click on, as opposed to a required part of setting up a run. This change came from feedback in user testing, where we noticed that most users opted out of customizing their workouts, selected “no” for every option, and just wanted to start running. In our new, optional customization page, we also change altitude to hills since users were confused what to input for altitude. We also made an aesthetic decision to arrange the exercises into a box that users could click on, as opposed to a long list of exercises for them to check “yes” or “no” to.
There was a lot of confusion surrounding our saved locations feature in user testing and during section presentations. We ultimately discovered that users would rather see past runs that featured a save location and go on that run again (or a new one) to revisit the place. We therefore changed our original design, which simply opened Google Maps to lead people back to a saved location, to our new design which will show the past run histories of each saved location, as well as popular routes that feature that location. In the past run histories, we decided to include the date, stats, and map as users expressed the desire to reminisce about past runs and also have the ability to run again.
We used Figma to create our medium-fi prototype. It was great using Figma because it was full of features that allowed us to make iPhone screens easily. There were tons of features to make quasi-buttons and professional looking screens. The tool also allowed all four of us to work together in real-time which was nice.
The only real issue we had with Figma was figuring out how to create icons.
Limitations of Medi-fi Prototype
For our current medium-fi prototype, limitations are that we cannot use this in a real scenario because it only simulates one case. Features in the hamburger menu do not work currently, with exception to ‘Bookmarked’. The ‘Customization Workout’ screen also does not allow to select ‘Yes’ or ‘No’.
Additionally, we have not yet implemented voice-interaction in this current prototype, but will do so in the next iteration. For example, the user currently cannot bookmark a location because that is a voice-interactive feature. Also, we have multiple runs saved under our ‘Bookmarked Locations’, but only the run dated Oct. 15th is implemented. Other than those features and full-functionality, this medium-fi prototype should support a general use case from start to finish.
For this stage of evaluation, we had 3 outside members of our class go through Jakob Nielsen's 10 general principles for interaction design, and evaluate our med-fi interface. Nielson’s 10 heuristics for interaction design are:
H1: Visibility of System Status
Keep users informed about what is going on
H2: Match Between System & Real World
Speak the users’ language
Follow real world conventions
H3: User Control & Freedom
“Exits” for mistaken choices, undo, redo
Don’t force down fixed paths
H4: Consistency & Standards
H5: Error Prevention
When you click on the parking spot for $2/hr, it automatically directs you toward it. It’s unclear whether you’ve already paid for this parking spot by clicking it. The app should confirm that you haven’t paid yet, to protect users from making unwanted purchases.
H6: Recognition Rather Than Recall
Make objects, actions, options, & directions visible or easily retrievable
Total # button - I have no way of knowing what that represented.
H7: Flexibility & Efficiency of Use
Accelerators for experts (e.g., gestures, kb shortcuts)
Allow users to tailor frequent actions (e.g., macros)
H8: Aesthetic & Minimalist Design
No irrelevant information in dialogues
H9: Help Users Recognize, Diagnose, & Recover from Errors
Error messages in plain language
Precisely indicate the problem
Constructively suggest a solution
H10: Help & Documentation
Easy to search
Focused on the user’s task
List concrete steps to carry out
Not too large
For each violation, or interaction issue, the evaluators would rank the severity of the issue from 0-4 with these severity rankings:
0 - don’t agree that this is a usability problem
1 - cosmetic problem
2 - minor usability problem
3 - major usability problem; important to fix
4 - usability catastrophe; imperative to fix
Afterwards, after each evaluator completed their own evaluation, other evaluators would also rank the severity of the violations they did not note down. This gave us a breadth of perspectives to see whether issues were common across evaluators or just singular instances. Evaluators were also able to disagree on heuristic violations. The decision was then ultimately our groups to decide what to do. With all issues or violations, our project group then provided solutions to those issues. If we disagreed that a violation needed to be solved, then we would argue why. These cases were often cases where inordinate amounts time and coding resources were needed to implement the feature or solve the issue.
With these evaluations, we were able to better improve our interface for our hi-fi prototype and demo.
Full Heuristic Evaluation of RANDOM:
RAN·DOM is an app that aims to increase user motivation for running by enabling them to create fun, random routes and connect to other runners.
Task 1: Go for a Run
1. S9: Guide users through a conversation so they are not easily lost / Severity 2 /
Found by A, B The interaction for changing a route doesn’t ask the user if the new route found is acceptable, or if they would like the app to generate another route. They would not know to ask for a different route to begin with. Fix: When the user begins the voice interaction give them prompts, such as asking whether the new route is acceptable.
Fix: Add voice to ask if new route is okay
2. S17: Allow users to exit from errors or a mistaken conversation / Severity 3 /
Found by B If the user wanted to change their mind about selecting between going home or to a new location, there is no way for the user to change their mind. The user can also not keep selecting a new random route like in the UI. Fix: Make the voice interface be able to ask the user if they want to choose a different random route. Also let the interface accept changes in the flow.
Fix: Make setting up a route voice enabled, can change settings with voice while configuring.
3. S12: Confirm input intelligently / Severity 2 / Found by B
What if the user initially was on their way back home but hit the blocked road. The voice interaction would then just give them a new route but would it be to get back home? There is currently no confirmation that the new route takes the user home. Fix: Make the voice interaction feedback say “New route home found.”
Oppose: Since we will be using a 3rd party API (Google Maps / MapKit) rerouting will be automatic and is beyond the scope of this class. We cannot alter how they do it.
4. H8: Aesthetic and minimalist design / Severity 1 / Found by B
The hamburger is in an awkward position and is also very easy to miss. Fix: Make the hamburger on the left and bigger.
Oppose: Android apps have hamburger on the right and we’ve made the hamburger the standard size of other apps.
5. H3: User control and freedom / Severity 1 / Found by B
There is no way to access the hamburger menu (Profile, Stats, etc.) from any other page but the homescreen. Fix: Make a Home icon for all of the pages or make the hamburger permanent.
Oppose: Once a user starts running, we intended them not to change any setting or click anything in the hamburger menu. Let them focus on the run only.
6. H10: Help and documentation / Severity 2 / Found by B
There is confusion between what is meant by “Meet runners”, “Hills”, and “Intervals” in the Custom Run screen. Fix: Have small descriptions of each customization next to the selector.
Fix: Add a “?” icon to define what each means
7. H2: Match between system and the real world / Severity 2 / Found by B
“New Route” is ambiguous. It is confusing on what the new route actually does before you click on it. Fix: Switch “New Route” to “Generate New Random Route.”
Fix: Call it “generate a new route” or “regenerate route”
8. H1: Visibility of system status / Severity 2 / Found by B, C
The progress bar on the actual run screen does not let a user quantify how far they have left to go. Fix: The progress bar should show the number of miles/kilometers left as well.
Fix: Add miles to go on other side of progress (also can ask with voice)
9. H4: Consistency and standards / Severity 2 / Found by B
When users finish the run, they are shown their stats but this is not the case when a user ends the run early. Fix: Have stats show even if the user ends the run early.
Fix: Show stats for runners who quit
10. H8: Aesthetic and minimalist design / Severity 1 / Found by B, C
Having a “Full Map” button is essentially the same as zooming out. It is an extra button with the same functionality. When looking at a bookmarked places, the section of the map showing the place is too small (there’s a huge area in the map shown that is super far from the bookmarked location). Fix: Make the initial map zoomable with a small button that lets the user focus back in on themself.
Fix: Rename “full map” and “resume” to “overview” and “recenter”
11. H1: Visibility of System Status / Severity 3 / Found by A
When I click on Miles (and Destination for One Way), I don’t see how many miles the run is for or what the destination is. This is an issue because I don’t know what information is has been inputted for my run. Fix: Populate the fields, at least with some dummy data for testing purposes.
Fix: we’ll populate with real data in hi-fi
12. H5: Error Prevention / Severity 1 / Found by A
A QWERTY keyboard pops up when I press Miles instead of a numeric keyboard, which makes me think that I can type in a word instead of numbers. This is confusing because I’m not sure what format the input should be, or if I can only put whole numbers. The same goes for the Destination field--there’s no indication of how it should be formatted. Fix: The fields should have ghost text that indicates the correct format of the input.
Fix: Use correct keyboard
13. H6: Recognition Rather Than Recall / Severity 3 / Found by A
CS 147 Autumn 2018: Assignment 9 (Heuristic Evaluation Group Template) Instructor: James Landay
The Destination field makes the user type something from scratch. This can be an issue because sometimes the user doesn’t remember the destination they want to go to. Fix: Present a dropdown list of previous of suggested destinations from which the user can pick out a destination.
Fix: We’ll use suggestions to give when users start typing
14. H4: Consistency and Standards / Severity 4 / Found by A, B, C
The Customize Run option is small compared to the Run button. This can be confusing because the user doesn’t necessarily know the difference between the functions of Run vs. Customize Run. Users might end up not noticing Customize Run because it’s overshadowed by Run. Fix: Customize Run can be displayed above Run so the user knows they should customize before pressing Run.
Oppose: This is intentional with a different rational (came up from our low-fi prototype) from our user testing.
15. H4: Consistency and Standards / Severity 1 / Found by A
The up arrow on the Route Preview doesn’t line up with the route for one of the routes, although it does for the other. The two are inconsistent and can confuse the user regarding the direction they’re supposed to go. Fix: Align the up arrow to the red route displayed.
Fix: We’ll fix this
16. H2: Match between system and the real world / Severity 1 / Found by A
The route displayed for the One Way option is the same as for the Roundtrip option, even though the two are fundamentally different. This can make the user think that the routes would be the same even though they really shouldn’t be. Fix: Ensure the destination for the One Way option is not the user’s current location (otherwise it would be a roundtrip).
Fix: We’ll show real routes people
17. H4: Consistency and Standards / Severity 2 / Found by A
The map doesn’t indicate where the destination is located. This doesn’t align with what the user expects based on previous knowledge from using apps like Google Maps. It can be confusing because the user can’t view on the map where they’re running to. Fix: Add a marker to the map indicating where the destination is.
Fix: Do this
18. H7: Flexibility and Efficiency of Use / Severity 3 / Found by A
Clicking on Full Map on the run page seems to pause the run, because there’s a Resume button at the bottom. This is an issue because users may not want to pause their run while they’re viewing the full map. Fix: Replace Resume with Back.
Fix: We did this earlier
19. H3: User control and freedom / Severity 2 / Found by A
There’s no option to go back once the run has been completed. The user might want to view information from run the that’s not just the summary stats. Fix: Put a Back button on the screen so the user can go back to the running part.
Oppose: When you reach destination, you can’t go back (like Google Maps)
20. H2: Match between system and the real world / Severity 2 / Found by C
When looking at the slides, I saw that you have a “Customize Your Run” screen. I think the defaults should be set to no since it seems like it might be more common for runners to not want any of those features during their run. Fix: Switch the default values to “No.”
Fix: Do this
21. H2: Match between the system and the real world / Severity 2 / Found by C
Is “meet other runners” a vital part of the app idea? I wonder how much need there is for that button. I’m biased because I know I wouldn’t want to meet someone while running because I wouldn’t want to have to stop and talk to someone, but maybe other people are different. Fix: Do more user testing and figure out if this functionality is wanted.
Fix: Our users liked this option, it’s a feature we want to offer
22. H6: Recognition and Recall / Severity 2 / Found by C
It’d be nice to have a mile count on the Route Preview screen before you press “Start Run.” I think it’s nice to know how many miles you just signed up for and see that on screen before pressing go. Fix: Add a text field that shows how many miles you’re about to run when you’re on the route preview screen.
Fix: Show mileage
23. H7 - Flexibility and Efficiency of Use / Severity 1 / Found by C
When rating a run, is it necessary to have a “skip” button? Or could you just have the “done” button, which acts as a skip if the user doesn’t press any stars to rate the run. Fix: Remove the skip button and allow user to skip rating by pressing “done” without assigning a rating.
Fix: Do this
Task 2: Real Time Updates
24. S9: Guide users through a conversation so they are not easily lost / Severity 4 /
Found by A, B The voice interface is not helping the user. The user asks for stats and is then just given a list. There is no hint as to what the user can ask or how the flow of conversation can continue. There’s no indication that the user can say “request progress information” after the initial stats are given. Fix: For each response, prompt the user with things they can ask.
Fix: We’ll add voice
25. S10: Use responses as a way to help users discover what is possible / Severity 3 /
Found by A, B, C The responses the voice interface gives do not help the user discover what is possible or what they can ask. Saying “give me my stats” doesn’t seem that natural, especially when running. This can be an issue if the user is out of breath while running and doesn’t want to say too much.
Fix: Allow the user to ask for specific stats as well have options instead of the voice interface just allowing for one way communication. Or to simplify things, let the user just say “stats.”
Fix: Can ask just “stats,” start with just stats and then add other possible commands
26. S1: Give agent persona through language, sounds and other styles / Severity 3 /
Found by B The agent does not seem like a person because it just lists off information. Fix: Instead of listing information have the voice interface add words like “good job!” and also not list information.
Fix: Make more conversational
27. H4: Consistency and standards / Severity 2 / Found by B There is inconsistency with “Hills”, “Elevation”, and “Altitude”. Fix: Decide on which one to use and stick with it. I would recommend specifying what is happening as well for example “Changes in Elevation”.
Fix: Get rid of hills and show final altitude gained in stats
28. H3: User control and freedom / Severity 3 / Found by B
In the PowerPoint there was talk about recommendations and ways to improve but this is not shown anywhere. Fix: There should have at least been a button or text somewhere hinting at this idea in the medium-fi prototype.
Oppose: We decided to get rid of this since this isn’t part of our main tasks
29. H8: Aesthetic and minimalist design / Severity 2 / Found by B
What is most important while the user is running? It is stats but the stats button is small and the same size as “Full Map” and “End Run”. Fix: Make the “Stats” button larger so that users are more inclined to click on it.
Oppose: Stats is primarily accessed through voice, so we’ll keep the button small. Also map is most important
30. H7: Flexibility and Efficiency of Use / Severity 2 / Found by A, C
The user has to click on a Stats page to view things like calories burned. The user may not want to go through this trouble while running because it involves looking down at the screen and finding this button. Fix: Display the stats at the bottom of the running page so they can be easily viewed.
Fix: Can ask with voice
31. S6: Use spoken language characteristics / Severity 2 / Found by A
Saying “Your current speed is... You have... You have...” should sound more natural. This could be problematic if the user expects the voice assistant more conversational and less like a computer. Fix: Combine into one sentence, or add some filler words to make it more conversational.
Fix: Make responses more natural
32. S9: Guide users through a conversation so they are not easily lost / Severity 3 /
Found by A The app says “Let me know if you need anything else,” which may leave the user lost as to what things they can say next. This may lead them to say something that’s invalid.
Fix: Provide a more specific message, or at least a recommendation on what they could say next.
Fix: Don’t remember, but we’ll take this out
33. H2: Match between system and the real world / Severity 2 / Found by A
The data for minutes remaining and miles to go should have more detail, meaning that seconds and fractions of miles should be displayed. The user is probably expecting this based on previous use with stopwatches and apps like Google Maps. This could be a problem when there is less than a minute or one mile left, and it’s unclear whether 1 or 0 would be displayed. Fix: Display the data more granularly.
Fix: Show fractions of miles but just estimation of time left
34. S8: Adapt agent style to who the user is, how they speak, and how they are feeling
/ Severity 2 / Found by A The voice assistant needs to be motivating the user when giving responses. Right now the responses seem barebones and canned. This could be a problem if the user gets demotivated. Fix: Add some motivational phrases to the speech responses.
Fix: add motivation
35. H1: Visibility of System Status / Severity 3 / Found by C
On the screen in the slides where you’ve started running and Random is telling you where to go, it was confusing that there was a “Turn Right 25ft” in big font and backed in red, and then a smaller grey box with “Go straight 25ft.” It seemed strange to have both. Fix: Only include one of those, so you know that when an instruction is listed, it’s talking about what to do next.
Fix: Use how google maps shows instructions
Task 3: Bookmark Locations
36. S4: Start and stop conversations / Severity 3 / Found by A, B
The voice interaction has no starting point. Will it just list out every hotspot while running? There doesn’t seem to be a way for the user to initiate the interaction. This is a problem because the user doesn’t know what to expect as a response when they ask for a location to be bookmarked. They don’t necessarily know how to phrase the input either. Fix: Add a flow that is user-initiated. Have an option for the user to allow the voice interface to speak key locations on routes.
Fix: Add tool tips when you open the app the first, for the first run also show users what they can do
Assumption: our user has gone through the opening tutorial and knows all the voice commands
37. S9: Guide users through a conversation so they are not easily lost / Severity 4 /
Found by A, B The user cannot ask anything. There is no conversation because they just say yes or no. The response is really short if the user says yes to bookmarking something, and it doesn’t leave any room for follow-up interactions. This could be an issue if the user wants to continue the conversation with another command.
Fix: Ask the user if they would like to bookmark another location or do something else. Have users be able to ask the voice interface questions about the location or share it with a friend.
Fix: Make more conversational
38. H3: User control and freedom / Severity 2 / Found by B
There is no way to access bookmarks besides on the homescreen, nor can the user actually bookmark a location during a run. Fix: Make the bookmarks icon be clickable and set the current location as well as show the other bookmarked locations. Have a bookmarks icon in the header of other pages.
Oppose: Bookmark is by voice
39. H10: Help and documentation / Severity 2 / Found by B, C
The past runs and popular runs for bookmarked location are a little confusing. Do these runs contain that specific bookmarked spot? Fix: Have a help page, info session on the first login, or add descriptors under each run.
Fix: Add “?” info icon
40. H4: Consistency and standards / Severity 2 / Found by B
When looking at a past run in a bookmarked location, only some stats are shown. This is inconsistent with the actual stats page for a run the user is presented after they finish a run. Fix: Have all of the stats be displayed in some form (pop-up or listed).
Fix: Make it the same stats summary
41. H1: Visibility of System Status / Severity 2 / Found by A
The task description states that users can bookmark locations on the map, but there’s no option to do so in the prototype or see that a specific location is able to be bookmarked. This can be a problem because the user won’t know how to add a bookmark or if only certain locations can be bookmarked. Fix: Add a voice button the user can press to initiate the voice interaction or a bookmark button.
Fix: This is by voice
42. H2: Match between system and the real world / Severity 1 / Found by A
It’s unclear what Popular Runs means. Popular to whom? The user might confuse whether those runs are popular to the user or to all users of the app. Fix: Add some clarifying text so users know what the term means
Fix: Could rename “top rated runs”
43. H2: Match between system and the real world / Severity 1 / Found by A
It’s unclear whether I can click on the Google Maps button and be led to the address for my bookmark. The user might be confused while that icon is there if they cannot view it in the Google Maps app. Fix: Add a label that states you can view the bookmark in Google Maps.
Fix: Yes can click, make obvious
44. H9: Help users recognize, diagnose, and recover from errors / Severity 3 / Found by A
What if the user makes a mistake and bookmarks a location by accident? This could be an issue because then the user will have unwanted bookmarks that may be irrelevant. Fix: Add an option (including voice interaction) to delete a bookmark in addition to adding.
Fix: Let users delete bookmarks from bookmark page
45. H2: Match between system and the real world / Severity 1 / Found by C
When you click on a bookmarked place, I wonder why it’s necessary to have a list of past runs there too. Fix: Remove the list of past runs and focus on the bookmarked locations functionality.
Oppose: the point is to take to past runs
46. H4: Consistency and Standards / Severity 1 / Found by C
When I clicked on the bookmarked place, Oracle Arena, I was confused why it showed a map that didn’t show the Oracle. Fix: When showing bookmarked places, make sure to include a map of the place.
Oppose: cannot implement in time
47. H8: Aesthetic and minimalist design / Severity 1 / Found by B
The app does not look like a sleek, iOS native app. Fix: Maybe use UI Kits or templates to help with actual UI for buttons, layouts, charts, etc.
48. H8: Aesthetic and minimalist design / Severity 1 / Found by C
I like that under the Name on the hamburger menu you mention how many miles the user has run, but maybe it might be confusing without saying “Miles run” or something along those lines? I’m thinking of clicking on someone else’s profile and seeing “200 miles” and possibly being confused if that means how far away from me they are, instead of how many miles they’ve run. Fix: Make the field say “ _ miles run”
49. H2: Match between system and the real world / Severity 1 / Found by C
I think it’d be nice on the hamburger menu to have a “History” button so I could look at all the runs I’ve completed. It could be cool to have some data visualization there too, that could show how your average speed or miles/run has increased throughout your time using the app. Fix: Add a history button to the hamburger menu.
Fix: Add history tab
50. H8: Aesthetic and minimalist design / Severity 1 / Found by C
Is it necessary to have a “Profile” button on the hamburger menu if you also have the profile picture and name that could act as a link to a profile page? Fix: Remove the profile button and allow user to click on name/profile picture to access the profile page.
Oppose: need profile