Page Comparison

Background Research

Goals of this phase:

Basically, learn as much as we can on our own before we book other people’s time!

1. User needs: have an understanding of and document here

https://uwmidsun.atlassian.net/wiki/spaces/S/pages/edit-v2/2522480716?draftShareId=d7ab5cd5-3f50-431f-a348-79f0190ee4e3

• what

• the user is using the dashboard for

• issues/pain points with existing dashboards

• other user needs

Nice to do: Send this document over to

firmware (Avery) so that they can validate/add to it before we jump into user interviews.

I’m not sure how much of this we can do without user interviews, but I don’t want the interviews to just be each person dumping a list of 50 requirements/stuff they personally want on the dashboard over a video call.

2. Learn about Data Visualization, Dashboard Design: Learn about and collect resources on data visualization best practices

in https://uwmidsun.atlassian.net/wiki/spaces/S/pages/edit-v2/2522480716?draftShareId=d7ab5cd5-3f50-431f-a348-79f0190ee4e3 as well

• Consider scalability, responsiveness

• Dashboard will have an overwhelming amount of data

• Resources on general UX best practices is also good

How do we achieve this?

• Review Telemetry Server findings from FSGP2019 and identify takeaways that would be suitable for MS XIV

• Create a preliminary list of requirements/things that need to be on the dashboard, again refer to Telemetry Server they’re using the dashboard for.

• Telemetry Software is the latest thing for MS XIV

• Telemetry Server still has tons of info (but more MS XII)

  • There’s a table at the bottom (“Desktop Telemetry Client Requirements”) with a list of things they want for telemetry.

  • I’m not sure if this is up-to-date. Would be nice to ask if there’s a document that outlines the stuff they want on need for the dashboard more clearly, or if one could be created for us in writing.

  • “GUI” (graphical UI) means they want it displayed. We’ll need to sort through the table to figure out what they want displayed.

• Collect and review data visualization best practices

Finish research/ documentation: 1-2 weeks?

Wait for strategy to get back to us: ?

Exploratory interviews

Goal of this phase: validate and expand on Background Research

• Pain points with the FSGP 2019 telemetry dashboard

• What else

  needs to be on

  they need from the dashboard

• What

  we

  they don’t need

  on

  from the dashboard

• Non-issues/things we don’t need to worry about

• Other insights into the dashboard

How do we achieve this?

• From the Background Research, try to isolate 2-4 big themes that we want to ask about.

• Create a list of questions for each theme

  • Having a few themes helps organize your inquiries instead of having 50 random questions that are all over the place

  • Ensures that you cover all the general things you wanted to cover during the interview without going off track

• Recruit around three to five FSGP 2019 attendees → create a list of people to reach out to

• Speak with them (~30 min to 1 hour interviews)

  • Record Zoom sessions, go through them after to take notes or have a dedicated third person act as notetaker

• If people are unavailable, offer to share the Background Research doc with them that they can comment on/validate in their own time

2-3 weeks?

Planning

Goal of this phase: Understand pain points of users and

formalize the scope/goals of this project

• Compile and organize research findings

  • Affinity diagramming

  • etc

  • Isolate and agree on main pain points to prioritize

• Defining features/stuff we want to include

  • What screens/components we’ll need to design

  • etc

• Information Architecture mapping + grouping

  • User/screen flows

  • Sketching basic designs

  • etc

1 week?

Design

Goal of this phase: Actually designing the thing

• Visual Design Guidelines

  • Colours

  • Typography

• Low-fi mockups

  • Quick

  • Very basic look: just above sketching in terms of refinement

  • Allows us to pay more attention to layout/flows/logic

• Define Interactions

  • How the system and the user interact with each other

  • ie communicating state of the system

    • States can be things like “edit mode” vs “view mode”

    • Errors in the car vs errors in the telemetry itself

• High-fi mockups/prototypes

  • Final “look”

  • Prototypes are interactive, so users can click through them

Low-fi Mockups: 2-4 weeks?

Visual Design Guidelines: 2 weeks?

High-fi Mockups: 2-4 weeks?

User testing

Goal of this phase: Making sure our design works (is usable), that prospective users are happy with it, and improving our design (if we have time)

• Should we test low-fi mockups before moving on to high-fi?

2 weeks?

Design: potential iteration

• Depends on how long the other phases go

Handoff

• Final style mockups

• Documentation