During my internship at Lyft, some of my tasks, projects, and duties revolved around designing for and creating new features for tools. These tools included tools used for driver support teams and a tool for configuring regions and market areas. It was a mixture of my design and engineering talents for unique use cases.
For these projects, I was the lead designer and front-end engineer.
Lyft Driver Support UI
I assisted with maintaining and adding features to a dashboard tool used by support teams for the management of drivers and their related processes. This often required designing and coding user interface features and elements.
Lyft Region Configuration Tools
Lyft has an interesting hacking culture. Where on Fridays, engineers are encouraged to work on a unique "fix-it" project. On "Fix-it" Fridays, engineers team up with designers to make something that could make Lyft better. I often provided design and front-end support on these projects.
One major "Fix-it Friday" project that had a heavy impact was the Region Configuration tool, initially built end-to-end by a single engineer. RegionCfg v1 was a graphical user interface for data entity relationships of cities and markets. This tool meant that Lyft could update and create records of cities and markets more efficiently through a system that didn't require engineering skills, such as command line database manipulation.
Although this tool brought the advantage of a GUI that could be used to create, edit, and conduct a variety of region specific operations, V1 wasn't an easily useable solution nor were its operations understandable. RegionCfg V1 was essentially an engineering specific complex tool. This meant an unsatisfactory user experience due to high learnability, ambiguous UI elements, and action pairings. V1 was essentially a visual database representation, similar to an Entity Relationship Diagram of regions, rather than the more sophisticated tool it needed to become.
I was assigned the front-end development and design of a better Region Configuration user experience. This experience would include and consider a variety of users, such as non-technically focused Lyft team members as well as engineers. At the same time, considering that the end tool may exist in a to-be-determined environment.
Make this tool easy to use and understandable.
1. Easy to use
We wanted a tool that users can easily use -- comprehend all possible actions in the system and evaluate their results. A system not biased towards more technically proficient users.
We wanted a tool where all users can understand the system, its states, and relevant information.
After running over basic spec requirements with my PM, I went through a human-centered design process:
Ethnographic Research (contextual inquiry + observational study) > Problem framing > Ideation > Sketching > Engineering
My ethnographic research included observing users of v1, ranging in various levels of technical proficiency from engineers to non-technical persons. I would observe by recording and writing as these users used the system to carry out various goals, such as launching in a city or updating pricing on a region. My findings from these observations found that users had suffered from a gulf of evaluation and execution, where users could not tell if they correctly performed the operations required of their goals and could not identify if they succeeded in their goals. This was evident through length of time to complete tasks and repeated unsuccessful trials. I also conducted contextual inquiries to get a sense of what each user valued, the types of operations that they'd need, and a picture of the miscommunications and issues of the systems.
Following my research, I assessed my findings and was able to do problem framing, where I could identify various factors and cases, further identifying ui issues and other specifics that needed to be addressed. The problem scope was framed around the use cases of creating/editing/reviewing regions, their relevant data and configurations, as well as the case of handling multiple regions. The key usability and user interface aspects where I identified problems were meaningful representations of data, multiple views of regions and contexts, interactivity, information hierarchy and filtering, readability, language / copy, cognitive load, and problems of information consumption (constant scrolling).
On the ideation level, I started with a dissection of the existing flow of interactions to get a sense of how the flow could be improved and what features needed to be addressed. From there, I got into sketching and thumbnailing of interface concepts and features. After this sketching and ideation phase, I consulted and reviewed with my team (backend support and pm) to assess feasibility and other feedback items. Once given the ok, development began.
On the engineering end, it was a question of what apis, tools, scalability concerns, and implementations may be needed given our environment. The best scenario was to build atop our existing infrastructure, without adding too much complexity. For ui elements, I decided to follow this concerns with the use of the Angular UI bootstrap, along with custom css to meet my design vision.
Around the time of this project, setting up and launching in new regions took a fair amount of time and Lyft was in under 20 cities. In the span of a year since the completion of this project, Lyft has reached over 65 cities across the US, some with simultaneous launches.