RANDOM Case Study

An iOS mobile running application that spices up running routines by giving runners customizable, random running routes. 

Random Cover.png

RANDOM High-Fi Prototype + Voice Interaction Demo Video


Project Summary

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


Design Process

For our design process for RANDOM, we used these design methodologies:

  • Needfinding

  • POVs + HMW Ideation Sessions

  • Experience Prototypes

  • Concept Video Creation

  • Lo-fi Paper Prototyping

  • Pilot Usability Testing

  • Med-fi Prototyping

  • Heuristic Evaluation

  • Hi-fi Prototyping

  • 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.


Needfinding Interviews

For this stage, we interviewed 3 people from our personal network and Stanford community:

  1. Victoria, a symbolic systems student at Stanford, approached her to do an interview in the Psychology lounge

  2. Christina, our team member's aunt who lives near Stanford, known to use an Amazon Echo

  3. Thomas, a Stanford technology specialist, tech gadget enthusiast


Interview Questions

  • 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?


Interview Results

  • Victoria

    • 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

  • Christina

    • 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

  • Thomas

    • 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

empthay map.png

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


Initial POV:

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

  • fitness trainer

  • 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

  • diabetic son

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

povs and experience prototypes.png
povs and experience prototypes.jpg
povs and experience prototypes (1).jpg

Experience Prototypes


HMW Ideation Session

povs and experience prototypes (2).jpg
povs and experience prototypes (3).jpg
povs and experience prototypes (4).jpg
povs and experience prototypes (5).jpg
povs and experience prototypes (6).jpg
povs and experience prototypes (7).jpg
povs and experience prototypes (8).jpg

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.


Concept Video


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

Concept Video.jpg

RANDOM Concept Video


Lo-fi Paper Prototyping

RANDOM_Assignment 5 Slides (10).jpg
RANDOM_Assignment 5 Slides (11).jpg

Interface Selection:

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.

RANDOM_Assignment 5 Slides (12).jpg

Lo-fi Paper Prototype Structure

low fi proto structure.png

3 Prototype Tasks:

  1. Surprise Runs

  2. Bookmark Locations

  3. Real Time Stats

RANDOM_Assignment 5 Slides (3).jpg
RANDOM_Assignment 5 Slides (4).jpg
RANDOM_Assignment 5 Slides (5).jpg
RANDOM_Assignment 5 Slides (6).jpg
RANDOM_Assignment 5 Slides (7).jpg
RANDOM_Assignment 5 Slides (8).jpg

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.

RANDOM_Assignment 5 Slides (14).jpg
RANDOM_Assignment 5 Slides (15).jpg
RANDOM_Assignment 5 Slides (16).jpg
RANDOM_Assignment 5 Slides (17).jpg
RANDOM_Assignment 5 Slides (18).jpg
RANDOM_Assignment 5 Slides (19).jpg

Med-fi Prototyping

Medium-fi Prototyping.jpg
Medium-fi Prototyping (1).jpg
Medium-fi Prototyping (2).jpg
Medium-fi Prototyping (2).jpg

3 Design Changes:

Medium-fi Prototyping (3).jpg


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.

Medium-fi Prototyping (4).jpg


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.

Medium-fi Prototyping (5).jpg
Medium-fi Prototyping (6).jpg


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.

Medium-fi Prototyping (7).jpg
Medium-fi Prototyping (8).jpg
Medium-fi Prototyping (9).jpg
Medium-fi Prototyping (11).jpg
Medium-fi Prototyping (10).jpg
Medium-fi Prototyping (12).jpg
Medium-fi Prototyping (13).jpg
Medium-fi Prototyping (14).jpg
Medium-fi Prototyping (15).jpg
Medium-fi Prototyping (16).jpg
Medium-fi Prototyping (17).jpg
Medium-fi Prototyping (18).jpg

Prototyping Tools:

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.


Heuristic Evaluation

Evaluation Method:

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:

Severity Ratings

  • 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.

Fix: okay

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”

Fix: label

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

High-fi Midway Milestone.jpg
High-fi Midway Milestone (1).jpg
High-fi Midway Milestone (2).jpg

Hi-fi Prototyping

High-fi Midway Milestone (3).jpg
High-fi Midway Milestone (4).jpg
High-fi Midway Milestone (5).jpg
High-fi Midway Milestone (6).jpg
High-fi Midway Milestone (7).jpg
High-fi Midway Milestone (8).jpg

RANDOM Hi-fi Prototype Demo Video


RANDOM High-fi Prototype + Voice Interaction Demo Video


Final Presentation Poster