Tuktuk Dashboard

TLDR;

Prototyped and designed a full dashboard through Figma — check it out ↗
Got to experience being the only designer among a team of engineers, technical product manager and co-founders in UT Austin’s startup environment

Lessons Learned

I would make sure I had more open communication with the engineers. This would've helped us understand each other's responsibilities better.
Create a cohesive design system beforehand.
Do more competitor research for both my benefit and the front-end development team’s knowledge.

Highlights

✨ Worked to create an administrative dashboard that allowed for them to track KPIs and manage functions for their ride share startup.
‍
✨ Completed our project within the 10-week period before our accelerator’s official Demo Day for potential investors.

What is Tuktuk?

Tuktuk is a student-led ride share startup based out of Austin, Texas.
‍
Carpools operate using the hub-to-hub model, each hub being a popular hotspot within the city. Tuktuk's services cover Austin's most popular student travel routes for those at the University of Texas at Austin.

The Problem

Students at UT always need a ride– meaning Tuktuk needed to focus on providing for multiple users at time and understanding user activity that might limit them from functioning for a larger user base.
‍
I was asked to create a cohesive digital space where the Tuktuk team could:
‍
• Add and schedule rides in one place
• View all rides (so-called “God view”)
• View metrics to improve operations

Our Solution

An admin dashboard to input rides, view past rides, and understand information to increase user engagement.

Seems simple enough, right? I thought so too, but the more I talked to our main users (the co-founders) I realized a lot goes into making a dashboard properly functional. Let’s take a look at some findings:

The process of building a dashboard can be split into three steps:

1. Understanding the need of the user
Establishing needs includes making a list of non-negotiable needs that would make the dashboard most beneficial for the user

2. Deciding on end goals

To decide on end goals, we determined specific components that were technically feasible for our timeframe but could also maximize impact

PAUSE - Our First Pain Point!!

How do we show multiple ongoing rides at a time in an understandable way?

3. User flow
Finally, the user flow: it was deconstructed into a preliminary text flow, chart flow for engineers, then screen flow for the team as a whole

Step 1 I started with a text flow based on the end goals to help show how each component was nested.

Step 2I then used FigJam to route a chart flow, where each shape corresponded to the user's task flow and system related actions

Step 3Since dashboards have a drill down of information, the user flow resembles an inverted triangle (surface level to specifics).

This is what I used to get into sketches for our final Figma file.

But first...

Seeing what’s out there is important. Dashboards are very methodical, so I realized there’s no need to reinvent the wheel if there’s solutions out there that have it down to a science. I needed more insight into what current solutions looked like, so I conducted research into Uber's Uber for Business dashboard as well as their other open source dashboards.

Sketches consistently accompanied research. Dribbble and Medium played a big role in collecting resources.

[Click to Expand]

Ideation

Finally, I got to our initial sketches. These moved along meeting by meeting, constantly getting validation with our co-founders.

Meeting 1 —

After this meeting we started working on some added components that were overlooked the first time around. We needed:

• An option to delete rides
• Uploading a CSV file to add rides in bulk
• Indication of active/inactive rides
• Revising an ‘Add rides’ flow

Drumroll, please...

After 10 weeks of hard work, we finally brought together a final prototype that was used by engineers to construct a functioning administrative dashboard!

Take a look here: Figma Prototype

The Calendar Page
‍
Here’s where admin would view all rides (past, present, future) to understand what their week looked like. It functioned close to any calendar’s UI, but mentioned key notes about the rides — Start and End points, Driver, Time/Date.

Remember that pain point?
‍
To accommodate for showing multiple rides in a way that is understandable, I created a single calendar bounding box to guide the user to a new page with all possible rides in that time frame.

Each card expands to show further information about the ride, much like a single ride bounding box would on the Calendar page.

Add Rides
Adding rides can be done both through a CSV file upload or manual input of information much like the cofounders wanted. The admin would input start-end hubs, date/time through a calendar modal, and assign a driver.