Interactive Data-driven Dashboard @SPIN scooter

BACKGROUND
SPIN scooter company wants to maximize the work efficiency for data analyst who manages the scooter ridership and gig worker who redistribute/repair/recharge scooters in Pittsburgh area. SPIN provided us two personas, Mia - Data Analyst, and Kalen - Gig Worker, and asked us to create one single design artifact for both stakeholders to solve the problem
THE PROBLEM
Compared to in-person work, people feel less appreciated than expected when they work remotely. Besides, they also feel less emotionally touched by the appreciation messages sent by co-workers via pure text-based communications.
MY ROLE
I participated the whole end-to-end design process. More specifically,
  • I built current-future model using 2 personas
  • I proposed and prototyped “task generation” and "scooter scan" features
  • I heavily worked on design iteration 1 - color association problems
  • I created the design style guide
CONTEXT
Design Challenge @CMU
3 weeks
3 collaborators

SKILLS
Interaction Design
Data Dashboard
Concept Map
User Testing
How Might We
design a single artifact that is mobile friendly and visually simple to help Spin Data Analyst and Gig Worker to improve their work efficiency
OUR SOLUTION
An interactive data dashboard that allows data analyst and gig worker to better share data in a timely manner to improve their work efficiency
FIRST IMPRESSION
I started my design with confusions. By intuition, two very distinct stakeholders should have different designs to fit their needs, from a user-centered perspective
With the constraint of “single Design” in mind, I dived deep to understand the relationship between the two stakeholder.
RESEARCH
CURRENT-FUTURE MODEL
01 Finding
Two stakeholders work interdependently to make decisions during the work. However, they don’t have a way to share data in time
02 Finding
Data analyst wants to better manage scooters; Gig worker wants to plan his work of the day efficiently
To understand the stakeholders’ user-needs, we started by creating an affinity diagram using the two provided personas and categorized them from low to high priority. Then, we built current-future model to mapped out the overlapping needs.
IDEATION
We each brainstormed ideas and created hand-drawn low-fi sketches individually to reflect potential design directions.
DESIGN OPPORTUNITY
CONSTRUCT LAYOUT
01 Construct a clear user flow that guides user’s view
Guide user’s view since people typically read from top left to bottom right.
02 High priority elements should grab immediate attention on a layout
Most essential features placed at the center to grab user’s attention
03 Grid structure helps maintain a cohesive organization
Supplementary data are grouped together, allowing user to quickly refer and compare
During the ideation process, I gradually realized that I could find a way to satisfy both stakeholders. The given constraint “single design” did not prevent me from ideating solutions, though not optimal.
WIREFRAME
We converted key features into wireframes and created mid-fi prototype for user testing
USER TESTING & ITERATIONS
We conducted 3 rounds of user testings. For each round, we invited four people in a group testing. Below are the changes we made based on the testing results
01
Design Change
Change color orange to blue to prevent wrong association
02
Design Change
Highlight the most relevant data to reduce cognitive load
03
Design Change
Integrate AI to improve user freedom
STYLE GUIDE
Having a style guide keeps our design consistent and structured
FINAL DESIGN

01: Map Overview
"ALL" info at one glance
Displays the distribution of scooters. Once zoom in, each scooter will be marked with respective status, including good, in need of recharge/repair/redistribution, and those are deactivated.
02: Map Routes
Grab what is happening "NOW"
03: Task Manager
Assign/Pick up tasks effectively
04: Scooter Analysis
Tackle decision-making with simple statistics
Clearly displays the task progress by categories, including “repair”, “recharge” and “redistribute”.Dynamically update the popular rider time slots. These simple statistics assist both Mia and Karen on decision-making.

05: Scan for input
Diagnose and update status in a second
Through the QR code scanner, Karen gig worker can quickly diagnose the issue of the scooter and update its status. These diagnose and updates will be updated on data analyst Mia’s side simultaneously.
CONSTRAINT
Limited information led to “idealized” assumptions, and therefore potentially non-practical solutions
During the design process, we came up with many questions about our stakeholders, however, we didn’t have a chance to find the answers on our own. We were not accessible to real users and had limited information (only two personas). Therefore, we had to make lots of assumptions, and put ourselves in certain “idealized” situations. This made our design be potentially non-practical and non-feasible in real situations.
User test on non-real users led to potential bias
We were not able to do user test with real users, instead, we tested with our peers, which represent a group of people “similar to us”. This may lead to some bias since we have similar expertise knowledge, skills and perspectives.
REFLECTION
After the project is done, I tried to think about the meaning behind this challenge, especially WHY we were constrained to design one single artifact.
Here are my thoughts below:
  • From the development perspective, having the same design saves time and labor
  • From the design perspective, it can maximize the consistency across different products
  • From the internal-collaboration perspective, it can minimize the cost of getting used to/ being familiar with the products
What I learned
“Constraint” may not be “constraint”, but accelerator
“Single design for two distinct stakeholders” was a big constraint for me from my first impression. (However, once I get started, I realized that I could still find a way to solve the problem). However, putting myself into a hard place forced me to maximize my creativity and ideation skills, although the solution may not be the most ideal. And once the situation gets a little better/constraint gets a little loosen, I could hand over a good solution.  This can also apply to my work as well. For example, I tend to set an earlier deadline that pushes me really hard. Then the buffer time in between could really bonus my work.Besides, the constraint offers me benefits. For example, it saved me time by preventing me redesigning the layout, information hierachy and color system for a separate interface.