Uber: Setting the conversation level with your driver

Designed & integrated a heavily desired feature to allow riders select a preferred mode of communication with their driver.

Add a Feature

Overview: Developed & integrated a new feature for an existing app based on a peer's proposed idea. 

  • The app: Uber
  • The feature: Let riders "control the conversation level" with the driver
  • Deliverables: High-fidelity prototype that reflects best path forward based on research, iteration, and testing
  • Platform: iOS
  • Duration: 4 Days
  • *All visual designs were based off of Uber Design Guide before the 2018 rebrand

Uber: Setting the conversation level with your

The Client

Uber sat as the “most valuable US start-up, by a long shot” with a current valuation of $68 billion when they had operated in 83 countries in about 674 cities (2018).

At the time, the app featured 11 different types of rideshares where the services ranged from carpooling with strangers to ordering your own private luxury cars and even having the ability to order a wheelchair-accessible ride, and much more. 

It's quite apparent that Uber has been working towards a more inclusive design when it comes to having a broader reach for more users. Fortunately from my research, I had found a seamless integration for the proposed feature that was not only in high demand, but also ended up being highly valuable for riders with social disabilities.

Probably would use
How would you feel if you could control the conversation level with your driver?
No way

We've all been there.

Maybe you just got off your 11 hour flight from London to LA and all you want is a pillow and a bed.

Maybe you’re headed to an important pitch and you need that extra 30 minutes to prepare.

Maybe you're just not in the mood to talk.

I decided to directly access users with guerilla research tactics by approaching various Facebook groups related to digital-, nomadic-, entrepreneurship-, travel-related topics. From there, I kept pulling the thread on active comments that were spilling in directly on the thread itself or by private messages. 

Affinity Diagram #1
Affinity Diagram #1

Situational Mood vs. Social Accordance

Affinity Diagram #1

  • showed concern for the driver and the discomfort (regarding the rating system) the feature would cause them
  • their openness to having a conversation was heavily dependent on the situation & their mood
  • reflected extroverted qualities, but the desire for the feature was present
Persona #1
Persona #1

Persona #1

I initially assumed that there were "types" of users: extroverted vs. introverted. I quickly realize that this type of user wasn't separated into categories but rather the context and what mood they were in. 

Here, we came up with Jin who was the ideal persona that represented an "average" majority of users.

Affinity Diagram #2
Affinity Diagram #2

Mental & Emotional Wellbeing vs. Social Accordance

Affinity Diagram #2

The two affinity diagrams were separated because of the last couple interviews where respondents had mentioned social disabilities where I conducted an interview with an individual who placed on the autism spectrum with Asperger's Syndrome.

Asperger's Syndrome is a developmental disorder where the individual has "significant difficulties in social interaction and nonverbal communication". In normal day to day life, behaviors related to autism can typically go unseen to a layperson.

In other words, day-to-day interactions that "average" people may think are easy and natural are actual hurdles & pain points for others with these social disabilities.
Persona #2
Persona #2

Persona #2

"…the people in the high functioning end of the autistic spectrum don't have any kind of support out there, even if it's as frequent as 11 for every 1000 Europeans, and 1 every 60 Americans. We don't have the option of saying "hey, I suffer social anxiety, please don't talk to me because I rather keep to myself." Mimicking and faking social traits it's exhausting and we have to do that every day to look neurotypical." 

Receiving these insights took me by complete surprise and made me realize that this feature was no longer just a desired function of the app for some but it was a necessary feature for others.

Inclusivity & Wellness

Although this individual didn’t represent the large majority, she did represent a certain population where this certain feature would make a huge difference as how they lived their daily lives and how they enjoyed using the app.

I returned to the users who were against the implementation of the feature and had asked what their thoughts were if the feature were implemented in support of users with social disabilities. And all of them were in favor of the feature if it meant helping out others who weren't mentally or emotionally adept at handling day-to-day social interactions. I had also asked how they felt about using the feature themselves and, surprisingly, all of them reported that it made them feel more comfortable in using it themselves as well. 

Highlighting the reason for the integration of the feature, addressing a minority group that would immensely benefit from the feature, proved to be pivotal in its communication to the public. 

Socially-challenged individuals need a way to feel comfortable & at ease in their rideshares because social interactions give them stress & anxiety and affect their overall wellbeing.

Problem Statement

Selected screen to implement feature
Selected screen to implement feature

Where do we introduce the feature?

The ride selection screen was the chosen screen to implement this feature as it seemed the most intuitive and least intrusive. 

The previous screen is targeted to search for the locations while the next screen sends your request. 

This screen also allows for any other preferences to be made such as a scheduled pickup time (excluding Express Pool & Pool rides) and checking your payment details. 

I specifically chose the UberX preference since 1) selecting Express Pool & Pool rides are inherently shared rides with all kinds of riders and 2) UberX also allows to set a preferred pick up time which would allow for us to see how well the feature would integrate given more use cases.

Ideation & Testing
Sketch Testing #1
Sketch Testing #1

Interaction Importance

Sticking to pen & paper first is always my preference. This way, I have the freedom to explore multiple options (even if they're silly) and also test & iterate through many different solutions.

Test #1: Should the preference have its own section or be similar to the pick-up time selection button?


  • 5/5 preferred the small button and not the entire section
  • having its own section felt like it was just as important as selecting which type of ride (users expressed otherwise)
  • less intrusive & more comfortable

Sketch Testing #2
Sketch Testing #2

Importance of Language

I wanted to keep close to the branding of the existing app and an essential part of a company's brand is their language. I felt conflicted between "conversation" and "chattiness" since both invoke different feelings even though they may seem synonymous with one another, which turned out true as I would dive deeper into user's perception of each word and the feelings it would invoke.

Test #2: Language usage & users' feelings towards tone of voice


  • 4/5 felt "conversation" was more appropriate for Uber's tone of voice
  • "Chattiness" felt too immature for Uber's brand 
  • "Chattiness" invoked a feeling of annoyance with its negative connotation (usually associated with someone being "too chatty")

Sketch Testing #3
Sketch Testing #3

Modes of Conversational Preferences

Deciding how many buttons to express the levels of conversation proved to be more important than what I had initially assumed. The amount of buttons & the type of words used played a big hand in how comfortable the users felt using the feature.

Test #3: Is there a difference & preference for having 2 vs. 3 buttons?

Test #4: Language choice between "quiet type" and "quiet mood" 


  • the concern for the driver was the most important apparent in this testing; they were most concerned of how a selection would affect how the driver would feel & behave based on their selection
  • 5/5 preferred "quiet mood" as it implied a temporary status instead of a permanent characteristic
  • 3/5 preferred just 2 buttons as the third felt intrusive to the driver forcing them to have a conversation they might not want to have

Low-fidelity wireframe
Low-fidelity wireframe

Interaction Placement

I almost always create wireframes in Sketch and make them interactive with InVision invoking a more "real" feeling when users test the prototype. 

Test: Did the location of the button make a difference in the existing user flow of the app? How so?


  • 5/5 preferred to have the button located on the left side of the screen
  • felt more "natural" since most users read the screen left to right
  • thought this feature would be used more than the pickup time feature

Uber: Setting the conversation level with your

UI Design

I strictly adhered to the 2018 Uber design guidelines as the project was executed before the 2018 rebranding. I kept consistent with the color, font and wording all the way down to the icon size and spacing & padding used throughout the app.

Feature Button Design

Creating the buttons and adhering to the style was the most challenging in terms of visual design. I wanted to keep aligned with the company and make the buttons seamless so I searched for some Uber designs and constructed the buttons you see to the left. 

I also left the default option to "Open" as that was the natural state of rides are these days: you're open to conversation based on the vibe of the driver and the ride.


You can also see some copy I had written in keeping aligned with Uber's tone of voice used throughout the app. Uber had also utilized explanations when describing each type of ride.

Uber: Setting the conversation level with your

Request Button

Keeping consistent was key as I did not want to break the existing interface when it came to ordering a UberX and selecting a desired pickup time. 

Again, I specifically chose this user flow as it illustrated how the request button would change in more complex user flows. 

Final Prototype

*It's important to keep in mind that the user flow for the prototype was created in the point of view of persona #2 (selecting a "Quiet" conversation level and then a scheduled pickup time from her work).

Further Explorations

Button Interface

Currently, the button automatically converts to one single bar when the rider requests a pickup time, making it impossible to cancel or edit the pickup option. You have to either cancel the ride and restart the entire process or request the ride and go into your profile to cancel it and then restart a new request process.

Many of the users were confused at this option as they wondered if they can go back and change the preferred conversation level, but I decided to follow the current user flow and relay back to the product team to revisit this interface (if I were a part of the real product team). 

Moving the conversation level to the user profile section

Another option that arose through the project was the option of moving the conversation level selection to the profile page where it could be defaulted to one state or the other.

As I had considered this option, I wanted to avoid making the conversation selection a static item for majority of the users out there who would also like to quickly opt for a quiet mood depending on their context. 

I would have been interested in A/B testing out the two placements or seeing how much usage the feature was getting and properly allocate its placement based on gathered data.

PR campaign in social disability awareness & support

I thought this could be an excellent win-win for all parties involved: users with social disabilities, "average" users and Uber as a company. Through research, the majority of "average" users felt a sense of relief and newly found support for the feature when more awareness was created concerning those with social disabilities. I also thought Uber could do with a positive PR campaign in helping them with their brand image & reputation due to past controversies & blunders.


Given the short timeframe, there was a lot more I wished I could have done. 


I would have loved to do more testing with the language. The wording is the most pivotal tool when it comes to communicating with the users throughout the interaction of the app and I would have loved the opportunity to further refine the proper wording to further invite the usage of the feature since many users were concerned with how it would affect the driver. I think it would have made users feel more safe when using the feature knowing it would not have any negative effects on other parties. 

Staying user-centered

The most important thing I learned throughout this implementation of the feature was the crucial role of usability testings. User-centered design really has to do with what the user’s actually want and not what you assume that they would want. I found incredibly powerful information from the feedback that either confirmed my assumptions or redirected my doubts to ideas that were more powerful in achieving the objective of the app. I found that listening to their feedback as well as digging into their explanations proved to be the most fruitful of actions that could be taken through designing something that is of real functional use for the public.