TurboLift

Goal

The project was to first and foremost create a manageable system which would allow the users to not only track and interact with the daily rides and transactions, but also to not miss urgent issues. Second is to create a system that will guide you to take the proper steps at the right time, allow the different teams and to collaborate, and to keep all information in one system.

Research

Business Requirements

Before the project begins, I delved into making sure that we're building the right product for the right audience. As the Product Designer, there are different directions you can take the product, so it's important to make sure you're going in the right direction. This begins with questioning all hypotheses. What does success look like? What data should we use to track it? Is this the best product to get us there? Specifically, how can thoughtful design get us there.

User Research

It all begins with understanding the user's world and their needs. This requires discovering their current workflow and environment, their pain points and expectations. Based on this, I create user personas so that we can have a clear model of who we're building the product for, how they use it, what features they need, and key tasks they need to accomplish.

Competitive Analysis

Competitive research is key to benchmark best practices and find opportunities to differentiate ourselves. The taxi management systems out there just did not seem to cut it. There was feature overload, poor UX, and ultimately did not guide the user towards their key tasks and target goals.

Insights

I learned how the users use the system and also the issues that arise. This guided me towards choosing the right features, requirements, and flows. I discovered that there are different use cases, and also depending on when in the cycle they were using the system.

Solution

The user journey depending on if they're accomplishing a daily, weekly or monthly task, would vary. Based on that, specific user stories allowed me to create experiences that would provide them with only what they needed for the task, and no more.

Ideation

I started creating the architecture and flows and low-fi concepts for primary use cases, and some important edge cases that do come up. After testing out the concepts, I turned them into high definition.

Requirements

I used the agile method by starting with addressing the main issues. Then iteratively we can test and add or remove features. Addressing the main problems and risks first assure that we're not heading in the wrong direction.

The Experience

Dashboard

The dashboard is meant to show what each user requires at that moment, and not more. If its not an important item, can be pulled up with reports. The point is to have a focus on their task on hand.

Onboarding

• After log in, there is an on-boarding introduction, as well as a walk through to understand the fundamentals.
• This can always be accessed through the side panel.

Search

I discovered through research that Search is the main way the users will interact with the program. Whether it's looking for a particular rider, vehicle, or transaction, the use case usually begins with search.

Requirements

• So it was important to make search front and center
• With the ability to filter by section
• And a more detailed search page, with further filters, if necessary

Ride

Requirements

We're tracking every part of the ride, including:

• Current location, and the entire ride history; the rider and driver; and pick up times, duration of ride, and distance
• You can also log an issue or emergency

Fleet

Requirements

• Monitor which vehicles are in operation, currently in use, and out of service
• Allow for collaboration between cross functional teams
• Allow for overriding of general settings

Riders

Requirements

• The main information should be visible at all time, in a left bar.
• All information should be broken down into modules, only visible when necessary.
• Action tasks should be easily available.

‍

Development

A design system is fully fleshed out, which allows for scalable designs. It also allows design and dev to be on the same page and use reusable pieces. I document as I work and summarize at the end of each stage, for future reference and internal stakeholder review and a separate documentation for handoff to development.

Impact & Outcome

With iterative design, we constantly look at metrics to see what to adjust. Based on that, we can continue our conversations with the customers to further understand the reasoning and thought behind their actions to continue to improve on the product.