When I started at Uber in 2016, I was two and a half years into my career as a product designer. I had a background in graphic design and made the conscious choice to join Uber to see if I could cut it as a real product designer at a top-tier tech company.

At twenty five, I was hungry, ambitious, and ready to grind. But the scale hit me fast. What used to be two stakeholders on a project was now twenty, all with opinions, priorities, and timelines.

Back then, I treated design reviews like a checklist, just another step to get sign-off and ship. That mindset was a trap. I made all the classic mistakes: showing too many directions at once, talking through pixel level details that did not matter, and walking out with more confusion than clarity.

It took a few hard lessons to realize reviews were not just for approval. They are where influence, trust, and alignment are built.

Almost a decade later, I am one of two Principal Designers at Uber and the first woman in the role. I have gone from aligning stakeholders on features to leading two app wide redesigns that shape how millions of people around the world move every day.

All this to say, I have done a lot of reviews. Over time, I have learned that they are one of the best opportunities to grow as a designer. You get to test your storytelling, defend your thinking, and learn how leaders make decisions.

What follows are the steps I have refined over the years to make reviews productive and, dare I say, enjoyable.

Step 1: Identify the purpose of the review

There is no one-size-fits-all template for a review, but most reviews fall into one of three categories: alignment, evaluation, or sign-off. Each serves a distinct purpose in moving the work forward.

Alignment:

• Phase: Problem Definition
• Purpose: Review the Product Requirement Document and maybe concept sketches
• Outcome: Alignment of whether the problem & opportunity being discussed is or isn’t worth solving

Evaluation:

• Phase: Beginning and middle of Design Iteration
• Purpose: Review 2–3 design proposals for solving the problem
• Outcome: Clear directional feedback based on business and experiential concerns. Teams should know how to move forward

Sign-off:

• Phase: End of Design Solution BEFORE engineering handoff
• Purpose: Review what the team recommends shipping and the priority of each change. Make sure all the loose ends are tied up and everyone is on the same page and in agreement
• Outcome: Approval that leads to engineer handoff or blocking feedback that requires revisions and another sign-off review

Early in my career, I completely missed this distinction. I once spent days perfecting a deck for a sign-off review on a feature I had been sprinting on, only to find out the project had never been aligned at the problem definition level with cross-functional leadership. It was painful, but it taught me an important lesson: if the type of review is not clear from the start, you are setting yourself up for misalignment later.

At Uber, reviews are where cross-functional directors provide guidance and have the final say on what meets the quality bar for each app. They usually happen alongside smaller touch points such as design crits, working sessions, and core team jams that build context and confidence before you get to the room with the decision makers. Here’s what a typical medium to large project looks like:

Step 2: Know your audience

Once you know the purpose of your review, the next step is to understand who is in the room. Most reviews last thirty minutes to an hour, so it is important to make that time count.

Executives
Your CPO, CTO, and VP of Design will each view your work through a different lens. One might focus on business impact, another on technical feasibility, another on user experience. Keep it high-level and tie your work back to broader company priorities.

Cross-functional directors
When you are in a review with directors and org leaders, focus on the problem space and how your design addresses it, not the pixel-level details.

Core team
Product managers, data scientists, engineers, and researchers. These are your people. They care about the details. The closer someone is to being responsible for execution, the deeper they will want to go with you. That is what jam sessions and team meetings are for.

Great designers know which calls to make on their own and which ones to bring into the room. I still stack the appendix with extra slides and context for questions I know will come up but don’t belong in the main flow of the story. It takes practice and confidence to get that balance right, but when you do, your reviews feel tighter and everyone in the room feels it.

Pro tips:

• Aim for your presentation to take up half the meeting and leave the rest for discussion.
• If it is context-heavy, send a pre-read twenty-four hours in advance.

Step 3: Align on expected outcomes

Before every review, I started asking myself two simple questions: “What do I need to align on to move forward?” and “What do I actually need this group’s input on?” It sounds small, but those questions completely changed how I prepare. They are now the foundation of every deck I build.

Timeline, Goals, and Nongoals
Start with overview slides to establish what needs alignment and what doesn’t. These will evolve as the project matures.

Previous Decisions and Past Reviews
If there have been earlier rounds of feedback, briefly summarize what was decided. This saves valuable time and keeps you from rehashing old conversations.

For example, in the driver app redesign, we aligned on moving the app’s primary navigation from a hamburger menu to bottom tabs. That quick reminder at the start of each review helped keep discussions focused on what was still open, like what belonged on the home screen.

Recap, aka Getting Alignment in Writing
When you wrap up, end with a recap slide. Reframe your meeting goals as questions.

Example:
“Align on user and business problems” → “Do we align on the user and business problems?”

I like to add thumbs up and thumbs down icons inline to make it clear where decisions were made and what still needs work.

This framing compliments the usual project context, such as the problem, the opportunity, and the success metrics, and helps keep discussions focused. It also sets the stage for your next steps and, hopefully 🤞, saves you from too many tangential conversations.

Step 4: Curate your work

Do not show everything
I see this all the time in evaluation reviews. People either show everything and expect others to choose for them, or they show one direction and call it final. Neither approach works. Your job as the designer is to present strong, distinct options and guide the room toward the right one.

Honestly, three solid directions are plenty. Any more than five, and you are just making it harder for everyone to give clear feedback.

Place iterations on a spectrum
I like to show a range from practical to blue sky, with my preferred concept in the middle. There is always some negotiation on scope, and showing the extremes helps your recommendation feel balanced. If you only show the practical option, I guarantee it will get scoped down.

Start with decision criteria then the designs
No design perfectly solves everything. Defining decision criteria helps your audience share an understanding of what matters most to the business and the user and how each design measures up.

Example:
1. Convenience 2. Awareness 3. Repeatable 4. Localization

Have a recommendation and make it clear
At scale, designers are hired to be the voice of the user, but we also have to balance business and technical realities. Make your recommendation visible so your opinion shines through whether you are in the room or not. Make it fun and make it you. I often drop in my memoji with a thumbs up or down, sometimes even a drop of sweat, to signal my stance.

Step 5: Guide the conversation

This step can be tricky. In reviews, people naturally want to contribute, and that is a good thing. When people start talking, it means you sparked something worth discussing. The goal is not to shut down side conversations but to guide them in a way that keeps the discussion productive and inclusive.

Start by returning to your goal slide after presenting the work. Comment in real time on the deck to capture what you are hearing. It helps people feel seen, and those notes will be valuable later when you are iterating.

If the conversation starts to drift, you can steer it back while keeping the energy positive:

• “I really appreciate the discussion here, but this might be bigger than today’s focus. Should we spend the rest of our time on this, or table it for a follow up?”
• “I am hearing a lot of different opinions, which is great. It tells me this area matters. Let’s capture it and plan a deeper dive so we can keep momentum today.”
• “That is great input. Before we move on, I would love to hear what [another leader or supporter] thinks.”

Guiding a review is as much about tone as it is about structure. You want to make everyone feel included while still maintaining focus. Not all feedback needs to be resolved in the room. Some conversations deserve more time and reflection. Reviews are about alignment, not always closure.

At the end of the day, your job is to hear the room, understand their perspectives, and clarify their goals for the work. If they align with yours, great. If not, take what you heard, replay it, and refine your recommendation. Sometimes that means pushing on the direction you still believe is best and bringing it back stronger.

The goal is not to make every decision final. It is to create a shared understanding of where things stand so that you can move forward with confidence.

Close the loop
The best reviews do not end when the meeting does. They continue through clear next steps and thoughtful follow up. Summarizing decisions and open questions keeps everyone aligned and accountable. Following through turns clarity into action and ensures the work keeps moving.

It took many successful and not-so-successful reviews to get here. Each one taught me something about clarity, collaboration, and confidence. Those lessons now shape how I mentor designers and guide teams through this process. The people I work with know this format well because it helps us make faster decisions and have more fun doing it.

If you have made it this far, I hope you feel more confident stepping into your next review. They might always feel a little intimidating, but that is also what makes them powerful. They are where alignment happens, where good ideas get stronger, and where great designers grow.

How to Stop the Stakeholder Swirl was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Uber platform currently powers more than 7 billion trips every year. When we launched Uber Navigation, the world’s first navigation system designed for ridesharing, in 2017, the platform was handling 4 billion trips annually.

After 5 years of growing demands, not only in app use but also in terms of ever-evolving products and features, Uber Navigation was ripe for an overhaul. Notably:

• As we continued to ship new trip and navigation features, cracks were starting to show in the product’s design framework. Over the course of a few years, we had shipped numerous feature improvements to the driver experience, but with relatively few accompanying top-level UX framework changes. At the velocity we were shipping, we quickly reached a local UX maximum. To support future product development, we had to tear down our framework and restart with a clean slate.
• Uber’s brand and design system had gone through multiple reskins and visual language updates; we wanted the navigation surfaces to reflect a polished, professional feel consistent with the Uber ecosystem.

So in 2022, a group of designers gathered at Uber’s New York City office to rethink Uber Navigation.

This story walks through our process of redesigning Uber Navigation using rapid prototyping and data-driven design.

A focus on efficiency and safety

With these issues in mind, we set out to design and build the next generation of turn-by-turn navigation for ridesharing.

Because drivers use our navigation system as a platform to work and earn money, making it different from other mapping systems, we selected efficiency and safety as key design principles. We wanted to provide drivers with the most glanceable view of maneuver instructions to be able to parse as quickly and easily as possible. We believed that would lead to more-efficient trips with improved pickup and dropoff information and fewer missed maneuvers.

Easier guidance to follow

One of the first changes that may catch your eye is the fresh coat of paint. Not only does the new design feature a color refresh, but the guidance chrome and map include typography updates that result in larger and more legible text and arrows.

Stress no more on the highway: we’ve brought greater emphasis to highway exits and complicated lane guidance by visualizing lane maneuvers in a clear manner. The system also highlights highway exits more prominently with special decoration.

Stronger contrast on the map

On the map, we’ve updated the route line to black: increasing the color contrast from our previous implementation by 123%, making the route line have a stronger contrast on the base map and making it extremely visible at just a glance.

The route line is annotated with different symbols that visualize stop signs, traffic lights, and even traffic incidents that are updated in real time.

New detailed data

Finally, we’ve brought substantial amounts of new detail to the map to help with driving or delivering. Enhanced building footprints, building numbers, and areas of interest like hospitals, beaches, and parking lots have all been added to the map as part of this update.

With all the new features being rolled out, let’s take a step back to examine the journey of getting here.

Challenges with designing maps

In general, designing for maps presents a few challenges compared to designing for standard user interfaces.

1. Geospatial (map) data is highly dynamic and is going to differ depending on your location. The street geometry, the local language, the road classes, and the land usage is going to vary. No 2 places on a map are the same. The UI of a map screen is going to differ in every scenario, as opposed to a typical UI screen that may contain the same predictable layout with minor changes every time.
2. Timing and motion also play a significant factor in the navigation experience. The navigation screen is almost never static or still; it is constantly moving and reacting to the driver’s position and heading. The maneuver timing, audio instructions, and map camera animations all need to work together to deliver a seamless driving experience.

With these 2 unique challenges in mind, we had to think outside the box to develop and use creative tooling in order to properly design for navigation. Our standard ways of working and design tooling weren’t going to cut it for this project.

Getting Familiar

At Uber, one of the design principles we follow is to become experts in the space we’re designing in. This means putting ourselves into the shoes of our users and going as deep into the domain as possible. We knew we had to get knowledgeable about not only how navigation systems work in general, but the ins and outs of our own existing Uber navigation.

To do this, we spent a handful of days driving throughout the busy and hectic streets of one of our top markets (New York City) with not just Uber Navigation, but with other navigation providers — all at the same time. This process was very valuable to us, as we were able to meticulously inspect and discover the different intricacies of each provider. We were able to see how each navigation provider reacted and performed with the same inputs and constraints. This process enabled us to uncover the key themes and values of our design process.

Tooling for a data-driven iterative design process

Once we had a solid amount of knowledge from our driving experiences, we got to work with our design tools and began sketching out, discussing, and debating ideas that aligned with our principles of efficiency and safety. However, these rounds of iteration and design differed from our previous and other design projects.

We incorporated some special tooling into our workflow that ended up being vital to our product’s success. We integrated data-driven designing into our process by building custom web tooling that enabled us to rapidly plug in real data to our mocks. For many of you who have been following along with Uber Design engineering, this is similar to what we presented at Figma Config in 2021.

Above is a preview of an interactive design tool that lets us stress test the new guidance chrome with real maneuver data. This tool lets us step through all the different maneuvers on a route, letting us view and tweak the sizing and typography elements within the chrome.

Not only did this let us stress test the designs automatically, but it also helped us understand the technical structure of the data that would be flowing through the chrome. This was also helpful because it brought us closer to our engineering partners, as we were able to communicate more effectively with them and speak their same language when discussing implementation details.

We also created a similar tool to verify our lane guidance icons:

Bringing it all together with a live prototype

Vehicle navigation is one product where seeing the full picture matters. Similar to our exercise of driving around with the existing navigation systems, we wanted a way to truly put ourselves in the shoes of the users who would be using the new designs on the physical road.

We already had the skills to build isolated prototypes with real data to test our designs, but why stop there? Why not bring the entire proposed experience to life with a fully functioning navigation prototype? While this goal sounded daunting, we knew it was necessary in order to truly validate our designs in real world conditions. Testing behind a computer screen in an indoor office was not going to cut it.

We opted to build a web-based application that featured our new designs. A mobile web prototype was perfect because we were able to still access necessary device sensors like GPS, while also being able to iterate and ship updates faster than we would with mobile code. We would still also have an easy way to distribute the prototype with a shareable link.

Whenever we’d make progress on a design, we’d prototype out the feature, and then hit the road to test it. The prototype plugged into all the mapping services and systems that the normal Uber app uses, so we were able to verify our designs with true mapping data, just like any other GPS system.

Although recreating an entire front-end for navigation added a few extra weeks to the project, the prototype served as a crucial tool in helping us discover and correct design errors that we normally wouldn’t have found until engineers started the development process. The few extra weeks invested into this prototype ended up saving us a multitude of weeks of both design and engineering resources down the line.

Validating with real users

After building the prototype, we came to a pleasant realization: if we could drive around and test our new designs, why couldn’t real drivers do the same?

As such, once we were confident that our designs were mature enough, we began organizing driving user research sessions with real drivers on the Uber platform.

Watching the research participants use the prototype and give us feedback early on in the process was an immense benefit to us; normally, for a product this complex, we would have to wait until an MVP is built by engineers in order to start getting insights and feedback from users. These early hands-on research sessions delivered vital insights and uncovered potential risks that we were able to quickly patch up.

Getting everyone onboard

As many who work in large organizations can relate to, designing and building the product isn’t the impressive task: it’s obtaining buy-in and alignment from your internal stakeholders and partner teams. By nature, organizations will tend to lean conservatively with product changes, because introducing new updates can lead to increased risk and potentially negative business metrics. Due to this, we embarked on an internal roadshow across the company presenting our changes to partners including sister product teams, design systems, user research, and even Uber’s Chief Product Officer.

In addition to standard slide deck presentations, we employed some creative tactics to demonstrate the delta and improvements between the old and new design. Internally, there were some concerns that the new guidance chrome felt bigger, and was thus covering additional map surface, and that some drivers may not be comfortable with the reduced map real estate. In order to prove the size changes were minimal, we created an interactive size comparison tool on an internal website.

Enabling employees to tinker with the old and new designs side by side on this internal website helped quell and alleviate concerns.

Design is never finished

Even after rolling out the updates to the public, we know the design is never finished. Expect Uber Navigation to continue to evolve in the near future as we continue to push what’s possible in defining how maps can be used most efficiently in making the A->B possible.

With this project, we were able to overcome the challenges of designing for digital maps by using data-driven design and rapid prototyping to deliver a refreshed and quality product experience.

Are you a talented product designer or design engineer interested in working on the next generation of mobility experiences? Take a look at our Careers page or interact with us on Twitter (@DesigningUber).

Thank you to the team involved: Dylan Babbs, Yuki Asakura, Vincent van der Muelen, Daier Yuan, Oliver Lukman, and Franklyn Graham.

Designing the latest generation of Uber Navigation: maps built for ridesharing was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-authored with Jaime Walke

In 2010, my job title was Content Strategist. At the time, I worked with information architects, interaction designers, graphic designers, web designers, illustrators, animators, and a slew of other talented folks to create digital experiences.

At Uber, we called ourselves Product Writers. Until now, UX Writers.

Now, it’s my pleasure to introduce our team as Content Designers. Let me tell you why.

A recent history of Product Design

The rise of companies like Facebook and Google signaled a new tech boom based on lightning-fast data speeds and handheld devices. In the lean startup culture that arose, designers in tech learned to combine traditionally separate skills into one role in pursuit of rapid iteration.

Enter the latest era of Product Design based on a set of T-shaped skills (thanks, IDEO). The “T” is in reference to a designer’s depth of expertise coupled with their versatility to drive design work, collaborate with others, and get 👏 it 👏 done 👏.

In time, the industry developed an alphabet soup to describe combinations of design skills. And in understanding these skills — and the gaps within them — writers found their way into the design process.

At first, a writer’s skills helped make sense of large websites, untangle complex navigation, and optimize web content to be found and comprehended. These websites gave way to niche apps that fueled increasingly complex use cases often extending beyond the screen for larger, more global audiences.

In turn, that required faster, more efficient development. It required localization and internationalization. Accessibility. Regulatory compliance. And, of course, a high quality bar not only regarding the clarity of such experiences but also how they feel.

Today, writers at companies like Uber work as design owners. They make decisions about experiences using their strengths, but are also invested in collaborating with others that have complementary skills. In other words, a T-shaped designer. A content designer.

What unites designers of all flavors?

UX Writers don’t just write, but that title leads people to think so.

For product designers, visual design is just one facet of their “T.” Similarly, UX writing is just one aspect of content design. Instead, core to “design” is a nuanced understanding of a problem followed by solutions rooted in deep empathy of your user.

In journalism, that’s what editors do — they are the ultimate advocate of an audience, whether to help them understand a sentence or find specific topics. But wait! That’s similar to what architects do — designing spaces suitable to the needs of its users. That’s why editorial and architectural skills are an essential part of the UX toolkit.

So, what does this mean? A Content Designer is parallel to a Product Designer but with complementary skills rooted in things like storytelling, writing/editing, and information architecture. And what unites designers of all types is advocacy of your users and a desire to solve customer needs, together.

Shaping the future of design at Uber

Once you view design as a matrix of related skills, you’re able to grow and adapt your skills to the needs at hand. That’s why there is no one-size-fits-all career path for product design.

A common starting point for junior content designers is to focus on their UX writing and copyediting skills. We diversify as we grow, picking up other design skills like usability research or wireframing. Along the way, we always work in lockstep with product managers, engineers, and data scientists to create clear, simple experiences that feel just right.

In fact, the most senior content designers on our team have the opportunity to work as design leads and design managers — Uber has several content designers in these roles at the time of this writing. And for me? My title is now Content Design Manager. I’m humbled to be serving as an advocate and mentor not only to other content designers, but also to product designers on our team that seek to improve their own content design skills.

Content Designer is a name that helps our co-workers understand our role, but who knows when an even better term will come along? If it does, we’ll welcome it. A core principle in tech is evolving with the needs of your users. This principle already drives how we design, and now it’s driving how we define ourselves.

What drives you? Share your story in the responses and let’s chat! 🤘

—

Interested in Content Design at Uber? Don’t be shy — apply online!

What’s in a name? Introducing Content Design at Uber was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Uber’s Base design system offers a set of map marker components that are used extensively across our products, displayed any time we feature a map to the user. We’ve recently come across the need to showcase additional context on the map markers and settled on adding badges — an existing Base component — to achieve that.

The challenge was that both the map markers and the badges had multiple variations. Markers can be customized by size, needle length, icon slots and layout behavior, while the badges can have multiple sizes, label, and icon styles. The final set of badge-supporting map markers is a combination of all these options, a total of 256 new components.

The common approach is for a designer to manually create these new components, which is not only inefficient but very error prone due to the repetitiveness and volume of work required to create all variants and individually test them under multiple scenarios.

I decided to take a programmatic approach.

Why did we add badges to the markers?

Badge UI is generally used to showcase an update or an offer of some kind. In this case, the badge is supplementing the marker.

The design specification for these badges offers four different sizes:

Since Uber operates in markets where the default language is written from right to left, the badges also support bidirectionality.

What is the most efficient process to construct the new components?

Once we completed the design specification for the badges, the next step was to “productionize” the components within our Figma workflow. This process entails creating the Figma component for each customization, writing documentation, and then publishing the components to the organization library.

Adding the badges to the map markers would nearly quintuple (5x) the number of map marker components within Base, as we were essentially adding four new badge variations for each existing marker.

For example, the new map marker component naming convention would go from:

• Map marker / Medium / Icon leading + trailing / Fixed / Needle off

to:

• Map marker / Medium / Icon leading + trailing / Fixed / Needle off / Badge none
• Map marker / Medium / Icon leading + trailing / Fixed / Needle off / Badge x small
• Map marker / Medium / Icon leading + trailing / Fixed / Needle off / Badge small icon
• Map marker / Medium / Icon leading + trailing / Fixed / Needle off / Badge medium icon
• Map marker / Medium / Icon leading + trailing / Fixed / Needle off / Badge medium text

Base already contains 68 map markers, so repeating this process 68 times would be quite the tedious task.

To complicate matters even more:

• each badge was to be positioned in a different relative position on the marker’s top right corner, depending on both the size of the badge and marker.
• only certain badges were eligible to be placed on each marker. This eligibility depended on the size of both the badge and marker.

Accounting for these constraints, a total of 256 new badge-supporting map markers would be created. Seeing the large number of permutations that I would have to build, I knew this would be a daunting manual process with lots of repetitive mouse movements.

Constructing these new components by hand would be a significant time investment that would most certainly lead to human error due to the pixel precision required of repetitively positioning each badge on a marker hundreds of times.

This type of monotonous task was a perfect candidate for replacing with automation with the Figma Plugin API.

Automation via the Figma Plugin API

The Figma Plugin API enables one to programmatically interact with the Figma document with nearly a 1:1 feature parity compared to normally interacting with the traditional UI. One can traverse the document as a node tree, create and modify objects, configure the viewport settings, access shared styles, and much more with the plugin. For those familiar with the web’s DOM (Document Object Model) API, the Figma Plugin API is very similar.

Uber has an extensive internal Figma ecosystem of plugins and tooling to augment the design process. Getting started with creating a new Figma plugin at Uber is relatively low-effort, as scaffolding is available to help with the initial plugin creation, testing, building, and publishing processes.

You can learn more about Uber’s Figma plugin ecosystem on the Figma blog.

Configuring the Figma API to construct the new components

I began to write the step-by-step process of the map marker construction algorithm to be implemented in Figma.

Since each badge and marker contained specific sizing and positioning logic, I created a configuration object in code to hold this logic. This object contained badge positioning and pairing eligibility information.

The Figma API plugin code would conduct the follow tasks:

1. Query all eligible map marker components to append badges to. Only certain map marker badges were qualified to contain badges.
2. Loop through queried markers and look up eligible badge pairings.
3. If the marker had an eligible badge pairing:
4. Look up placement position info for marker + badge combination.
5. Using some auto layout trickery, append the badge to the marker in the correct relative position. This step was the most time-intensive, as I had to replicate and encode many Figma auto layout rules into the object programmatically. At this point the new map marker badge component were created.
6. Neatly place the newly constructed map marker badge component in the main Base component document.
7. Repeat for all remaining markers until the process is complete.

Executing the script was simple at this point. In the plugin’s UI window, a button click kicked off the script execution. All I had to do was click Build Markers, and the plugin would work its magic.

With just a single click, I was able to take a set of markers and badges and automatically bind them together to create hundreds of new Figma objects programmatically.

Creating the script was definitely an iterative process to nail every step of the component construction. However, the beauty of scripting in this situation is that I could dynamically undo and repeat the process repetitively until the output was exactly as I desired. There was no need to manually step back or reset the document by spamming the undo button. The entire workflow could be executed or completely reversed at once.

Testing markers at scale

At this point, the new map marker badge components were constructed, but the process was not quite complete. I needed a methodology to test these markers at scale to root out any potential positioning or sizing issues that may have appeared as a side effect of the script. Having a scalable testing framework available would also be important in the event the root components were ever changed in the future.

I wanted to test for two criteria:

UI test 1: badge positioning

The badge’s relative offset positioning depended on both marker and badge size. For example, some badges would be -3px offset, while some badges would be -5px offset.

In order to test this, I decided to automatically generate guides placed in the desired position of each badge using the plugin API. With these guides in place, I could perform an eyeball test to ensure each badge was positioned properly. Both a horizontal and vertical guide would be placed on every single new marker.

UI test 2: text length

The next test I implemented was to ensure proper badge positioning based off marker and badge text lengths. The length of both the marker and badge could differ on each custom instance of the component, depending on its usage.

To implement this test, I created two input fields within my plugin UI so that I could specify custom strings. This way, any text that I would enter into the inputs would propagate down into all the map marker components. This would let me ensure the badges stayed fixed in the correct position, no matter the length of the marker or badge text.

Wrapping up

As design systems grow and mature, the complexity of the components increases with it. This additional complexity opens up room for human error due to the repetitiveness and volume of work required to generate all variants — even without errors, such a manual process is highly inefficient. And with a design system that is being used at scale, even small errors can get compounded and deteriorate the user experience. By incorporating automation into the design system workflow, we can create a high quality set of well-tested, production-ready components.

By automating the construction of the markers, I was able to avoid human-error and efficiently generate the full set of variants. Programmatically testing the components allowed me to thoroughly validate them under multiple scenarios and be confident of their quality.

Give the finished components a try in the public Figma Base Gallery.

Thanks to my colleagues Cady Wachsman, Vietanh Nguyen, Anton Chang, Christian Rauh, and Joshua Lee for the help throughout this process.

How I programmatically built 256 new design system components in Figma was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

What cash trips in Mexico taught me about designing for international markets at Uber

As a product designer at Uber working on the Money team in Amsterdam, it’s my job to help come up with design solutions for Uber products across the globe. Designing globally presents a lot of challenges that don’t come up if you are creating products for a more limited market. We constantly see how cultural context, infrastructure, and on-the-ground realities matter to good design.

The problem

My team recently dealt with a good example of these challenges. On its face, the question was a simple one: How could we better collect the service fees for use of the Uber platform on trips in which the passenger connected to the driver paid in cash rather than through digital payment?

To better understand the problem we were facing, first a little background on digital vs cash payments:

In ridesharing industry, riders often pay digitally to ridesharing companies which then pay drivers. But in countries like Mexico, it is common that riders pay the driver directly in cash, then the driver pays the ridesharing companies.

Things get complicated

Let’s zoom in on how this challenge impacts one driver. When a driver has a positive balance in her Uber account because she’s received payment for digital trips, Uber can just deduct the service fee from her account. When she has $0, however, withdrawing from her Uber account would result in a negative balance.

Now, let’s zoom out to see how this problem grows with the number of cash trips. For drivers with a high volume of cash trips, it could be a struggle to maintain a positive balance. We needed a way for drivers to securely and easily transfer the cash service fees to Uber.

When we started working on this problem, the previous solution wasn’t scalable. When a driver had a negative balance, Uber would send an email with a URL linked to an invoice and instruction on how to make a payment. The driver would then be solely responsible for carrying out a deposit, at which point Uber would receive notification that payment had been completed.

This was a manual experience, with a lot of heavy lifting asked of both the drivers and our Operations team, who were manually managing the emails. It was also opaque, as we had no way of knowing what was going on between sending a driver an email and eventually being notified of the payment.

All of these notifications were being handled via email — there was no related product experience in the app. This was a problem particularly because there was no guarantee that drivers would check their email accounts regularly, or read through all messages thoroughly.

Part I: On the ground

We started with the basics: doing research on the ground in Mexico, to find out exactly what wasn’t working.

Together with one other designer and our product manager and UX researcher, I traveled to Mexico City and Guadalajara, where we spent two weeks working with drivers to get a better example of where the current experience was falling short.

It soon became clear that one way we were falling short was in not effectively disseminating information. There was an overall lack of awareness about how handling service fees worked when it came to cash payments. We needed a better way to communicate.

From our research, we knew we needed to accomplish three things:

1. We needed to design a system that provided drivers with more control and flexibility on when, where, and how much they paid.
2. We needed to be able to guide drivers through the payment process and provide feedback on the status of their payment.
3. We needed to provide more accessible and thorough information to experience drivers about cash trips.

It became clear that handling more of the payment process inside the app would play a crucial role in streamlining the process and making things easier for the driver. In short, we needed to create an in-app collection framework that would satisfy these three needs.

Part II: Bringing it in

During our research, we sat down with volunteer drivers to get their thoughts and feedback on some of our ideas. In many of the sessions, drivers would interact with a prototype we’d made in Figma. We’d pull over the car, load the prototypes onto a test Android device and ask the driver to pretend it was their phone. Some would even put the test phone in the phone holder of their car like it was theirs — a great way to put the driver in the mindset of it being their phone and their experience.

In the prototype, drivers first confirmed how much they wanted to pay at any given time. Then a code would be generated that they could use to make the payment at a convenience store. Once they’d made the payment, they could confirm their payment in the app, and they would see a “pending” screen to communicate processing time.

After interacting with the flow for the first time, drivers would often tap through the screens briskly without taking time to read, internalize, or completely understand what was happening at each step.

Drivers would then get to the end of the flow (the “pending” screen) and assume their payment was processing, even though they had never actually gone to a convenience store and paid:

In some cases, drivers mentioned they would call support immediately upon hitting the pending screen, to find out why it was still processing, even though, a) we communicated on the screen that it could take up to 48 hours and b) they hadn’t paid at all!

Part III: Refinements

We returned home to Amsterdam and began refining the experience. We experimented with step-by-step instructions, pre-flow information, flexibility around starting payment again, help and support, and contextual help during first experiences.

The main issue we saw during our testing in Mexico was that some drivers would get to the end of the prototype flow without actually paying. To account for this, we did two things to help drivers and give them flexibility if they had accidentally gotten to the end of the flow without paying: we enabled them to start over, cancel the transaction, and we allowed them to view their code from the “pending” screen, so that they could subsequently go to a convenience store and make the corresponding payment:

What we learned

In addition to the satisfaction of coming up with a workable solution to the problem, this project offered some valuable lessons in design:

Design for people, not for users

As designers, when we think of “users”, too often we picture someone interacting with our product exactly as we would wish them to, understanding all of our expectations and taking for granted the same things we do.But this idealized user does not exist, because those interacting with our product are people, and in real life — as we saw with drivers speeding through our in-app payment — people are unpredictable, and we need to design with that unpredictability in mind.

As long as it’s clear, it’s okay to be complex

We often conflate clarity with simplicity. We shouldn’t. They are two different things, and while simplicity is often preferable to complexity, sometimes a degree of complexity is necessary when you are dealing with a more complicated problem.

Ignoring complexity in favor of forced simplicity doesn’t help anybody. Instead of trying to ignore complexity, try to deal with it as clearly as possible.

We did this when we offered to let drivers view their payment code or start over from the pending screen, in case they hadn’t actually made their payment yet. Ignoring this problem would have been simpler, but it wouldn’t have led to a better solution.

Localization ≠ translation

A big lesson that was reinforced for us with this project was the importance of localization. This was a product that would eventually be released in multiple markets, including Mexico, Brazil, India, and Japan. During the design process, we’d been writing the copy ourselves in English, thinking that we could leave translation towards the end and do it just before testing.But localization — even when only considering the linguistic aspects — is more than just translation. Culture and usage may alter the intended meaning radically, or render it entirely nonsensical. And this is very difficult for a non-native speaker and cultural outsider to fully mitigate without inside help.

What’s needed instead is “transcreation”: adapting a message from one language to another while maintaining as much as possible consistency of intent, style, tone, and context.

This is best done early, often, and with local help. Who better to ask to serve as your guide around a town than someone who has spent their whole life there? The same is true of language.

Looking ahead

Working on this project has been a rewarding experience. As we move forward and expand this product into other markets, helping other teams adapt it to their own needs, we continue to look for opportunities to improve the experience. This project has been a good reminder for me that our “users” are people; that there are worse things than a little complexity; and that assumptions are to be questioned, not relied upon. Keeping these in mind can only make for better design.

Want more?

I made a video about my learnings from this project, watch below:

About the author:

Femke is a product designer at Uber working within Uber Eats on restaurant tooling. Previously she’d worked on the driver experience focusing on money and payments across the world. You can often find Femke creating videos on YouTube, hiking around Ontario or mentoring on Superpeer.

You can follow her design journey on Twitter, sign up for her newsletter or connect with her at fem@uber.com.

Femke wants to especially thank the Cash Engineering Team and:
Amrita Banerjee— Product Manager
Misha Frolov — Product Designer
Jelle Prins–Design Manager
Ginger Kimler — Content Strategist
Laszlo Laufer — User Researcher
Nick Jones — Data Scientist
Kate Lynch — Product Operations Manager
Adam Weigand– Product Marketing Manager

As well as Thijs Niks, Ebi Atawodi, Albert Malikov and Joost van der Ree

Do you love a good design challenge and working to make better things for people? We’re hiring at Uber! Check out our job openings.

Designing For A Cash Experience was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s be honest, managing can feel like you are constantly undulating between surviving and thriving. Whether you’re at the beginning stages of management or a seasoned leader of many teams, sometimes you have perfect vision for a year, and other times like you can’t see past tomorrow. Career development is one area of management that remains an elusive responsibility to many. It’s often neglected when there are other competing priorities. Yet most managers don’t realize career development is what pulled your talent through the front door, and lack of it is often the reason they retreat out the back door.

The career conversations I had with my first manager happened roughly once a quarter and involved filling out some sort of document that asked me broad questions about my career:

• What are your strengths and weaknesses?
• What are your 1 year, 2 year, 5 year goals?
• Where do you want to grow in your skill sets?
• How will you get there?

I never liked this format. It felt like I had to boil down my life and professional career into a 45 min conversation and somehow this document was going to help me reach 5-year goals. It felt difficult to be sincere and vulnerable. (It also made me wonder if I could truthfully answer these questions considering how my manager might perceive me.) I felt career conversations should be layered — there were so many aspects to peel away before figuring out what to do next, let alone the next 5 years. I needed a manager that was willing to be a nonjudgemental witness to my self-discovery in addition to opening the right doors. What I wanted was a vulnerability coach.

Vulnerability as the gateway

I first discovered vulnerability in 2010 during grad school. While attending Pratt Design Management program, a classmate of mine introduced me to The Gifts of Imperfection by Brene Brown. The book changed my life — it set me on a different path both personally and professionally. Written by renowned TedX speaker and shame researcher Brene Brown, it promotes the importance of authenticity: what it means to face your fears, be brave in your own skin, and see the power of vulnerability as a driver of tremendous growth and creativity.

Admittedly, fear was one of the main drivers that led me to Uber after almost nine years at Google Maps. When I came to Uber in 2015, I made it a mission to tackle my own vulnerability. As much as I cherished my experiences at Google Maps, I felt like I had grown complacent. I fit into my own place so well that no one pushed me to change or grow. At Uber, I was determined to tackle the fears that were blocking me from becoming a better leader. I also did a TEDx talk about my fear of public speaking in Chicago. It wasn’t easy to be this brave and share my vulnerabilities — I hoped to find inspiration from my struggles rather than hide from them.

After the talk, I committed to incorporate more vulnerability into my day-to-day life. I began asking myself, “How can I practice being vulnerable today?” on a regular basis.

Start with your values

One exercise I learned at grad school was about defining my top 3 values. This helped me access what I believed in and discover who I was at my core.

• Authenticity. Honesty in one’s self and others
• Knowledge. Information is the currency in which I learn and grow. Learning something new in people, products, and myself is what I love to do.
• Love. This has evolved for me.It used to be about relationships, but at some point I realized I was avoiding the word love. It was a hard word for me to use because I didn’t grow up with a family that talked about their emotions and love for each other. It was implied but never spoken. So for me, love is about empathy, respect, and generosity towards others.

While I use these values to decide important decisions in my life, I knew that walking up to someone and asking them what their top 3 values are can make people feel exposed or completely lost. As a manager, I wanted to try to become the career coach for my reports that I never had myself by figuring out how to build trust so that people can open up to their vulnerable selves. Here are some techniques I have used.

Vulnerability in a group setting

So, how to get others to open up? An ice breaker game, of course. The “School of Life: 100 questions — Work Edition” fit that purpose perfectly. I bought this box in Amsterdam during a work trip and was intrigued by the deep questions it asked. I thought of it as a perfect ice breaker for my team during our weekly Design Crits where we casually review each other’s work. Prior to this box of career cards, I had made make-shift versions where I wrote out 21 questions on separate post-it notes and folded them into a small box for each person to answer. They ranged from questions like, “If I were CEO, I would…” or “if I had made all the money I needed in life, I would be doing…” They were questions I would ask my team at Google in 10 min standups every Monday. We talked and dreamed about our careers instead of discussing projects. It was our favorite moment of the week.

At Uber, I was able to leverage the same vulnerability exercise with an official ice breaker game that allowed our team to be open, funny, heart-breaking, and inquisitive about each other (and oftentimes about our parents). To me, it was an important muscle in finding new connections beyond work, building empathy and trust, and being free to inhabit our true selves at that moment.

A Foundation of Trust

The school of life and top 3 values exercise led to the first Career Conversation series I would host in one-on-ones with direct reports. Combined, these activities proved my thesis that vulnerability was the foundation in which our career development conversation can grow. My monthly 1-hour career convos series usually looked like this for the first 4 months:

This toolkit has helped me more effectively tailor every individual’s day-to-day work around their core career paths and motivations. I drew inspiration for my own career path by watching my team self-reflect and apply these exercises. The most important takeaway for me during these sessions was to put on my design hat to find patterns in these disparate stories that were often never spoken aloud. When you put a spotlight on an individual’s narrative, you invariably help them prototype their life and make a plan. My goal was to make career conversations simple and something to chip away over time, together. I encourage you to try this toolkit with your team. In pursuing your team’s path for self-discovery and a thriving career, I hope that this toolkit will also help you find yours.

Download the toolkit

Join Uber Eats Design & Research Team

What do I want to do with my c̶a̶r̶e̶e̶r̶ life? was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

I got the opportunity to work on various teams, conduct research internationally and work with brilliant cross functional teams. I started as a researcher on a team called India Growth which focused on building our business specifically for the India market. I later moved to the Rider Access team which aimed to make Uber more accessible to riders in emerging markets via modes other than the rider app. In September 2018, I moved to Uber’s office in San Francisco as a researcher for Uber Eats , focusing on the trip experience for delivery people. And now I lead research across all verticals for delivery people on Uber Eats globally. I had the opportunity to conduct research in countries like India, the United States, Brazil, Singapore, Costa Rica, Ukraine, Mexico, Spain, France and the U.K. I worked with exceptionally smart people in different functions across product management, data science, design, engineering, product marketing, and on-the-ground operations, to name just a few.

As I sit and reflect on my 3.5 years at Uber, I feel grateful and amazed by how much I’ve learned and grown in this role. Today, I want to share ten important lessons I’ve learned while working as a UX researcher for the company. My hope is that my learnings can be applied to your own work, and that you’ll share your thoughts and experiences too. I’d love to start a dialogue that could contribute meaningfully to the growing field of UX research!

1. Think Globally

This may seem like an obvious one, but my belief in this has increasingly strengthened with each project. Addressing cultural and regional differences is incredibly important. After having worked at a global company like Uber — whose app is used by people across hundreds of cities, cultures, and backgrounds — one becomes very cognizant of the fact that one solution doesn’t fit all. For example, what works for a driver in the U.S. might not work for a driver in India. There are considerable differences, and accounting for those differences right from the very beginning makes for a better product experience.

One of my favorite examples of this lives within the earnings tracker of the Driver app. This feature shows drivers a running tally of their daily earnings. As we conducted research across markets, we found that, while drivers in the U.S. loved the feature, many drivers in Saudi Arabia felt it might bring bad luck and due to safety reasons, drivers in Sao Paulo preferred to not have this feature at all. Thanks to our research, we decided to launch this feature with a toggle to activate or deactivate visibility. This seemingly minor tweak helped improve the earnings experience for thousands of drivers.

Understanding cultural nuances is critical. One can start by working with local operations teams and data science teams to find out how markets vary in different aspects and then plan research to cover all critically different and strategic markets. If you don’t have those resources, even referring to some literature on how cultures and geographies differ can help in figuring out strategic markets for research.

2. Assess and prioritize

Try to ensure that the research you are doing is worth the effort and brings sizable product and business impact. Given that UX research is still a relatively young field, not everyone understands it well. This means your cross-functional partners might not always understand how to best use UX research or what questions to ask of researchers. Therefore, it becomes even more crucial to assess whether the research questions you are pursuing are the most valuable and impactful for the team and users.

Educate your stakeholders as to the kinds of questions UX research can best answer and also to its limitations. Ask them what they expect from this research and help them evaluate if those are the right questions to ask. Assess if they are being too narrow in focus or too broad in scope. Assess whether UX research is even the best way to answer certain questions or if they might be better answered by other means. Consider whether you need to spin off a new project for these questions, or if they can be answered by reviewing the existing literature. And finally, ask the team to articulate the impact of not doing the research — this makes them think about research more deeply and helps when prioritizing projects.

3. Get out there

Nothing, absolutely nothing, can replace getting into the user’s context (i.e interviewing/observing them in their natural environment or the real environment where they will use a product). Throughout my time at Uber, I have done research in-lab, remotely, and in the user’s context. Without a doubt, what stood out to me was the experience of learning from users in context. There are so many nuanced details one misses when interviewing users out of context or testing products where they are not intended to be used. One of the ways we do research in context with delivery people is by riding along with them when they deliver food. This helps us learn how they are interacting with the app in a real-world setting in real-life conditions.

For customers, we conduct in-home interviews to better understand their lives and context. While visiting Uber Eats users, we try to understand what every day eating looks like for them. They generously share their homes with us — most importantly, their refrigerators and kitchens! — and then we observe as they order food and we all enjoy a great meal together.

4. Get creative with your methods

In my early months at Uber, I would often hear the phrase ‘creative research methods’ and, at first, I wasn’t quite sure what that was supposed to mean. I soon found, however, that it encompassed a wide variety of techniques that involved improvisation and flexibility, lateral thinking, and a can-do spirit. My favorite example of this happened on a research trip to India when my team was trying to figure out how to get 14 cross-functional members (from design, research, product, operations, marketing) from San Francisco — none of whom knew the country, culture or local languages other than English very well — to understand the experience of motorbike delivery people in New Delhi and Hyderabad.

After a lot of brainstorming, we decided to conduct ride-alongs in a somewhat unusual way. We split the contingent into three groups, each of which rode in a car that followed a bilingual researcher who sat behind a delivery person on a motorbike. Each team was composed of:

1 delivery person

+ 1 researcher (as pillion rider)

+ 1 carload of observers (4–5 per car)

= 1 solid example of “creative research methods” at work

The motorbike and car were connected to each other via video call or voice call. It was a brand-new way of doing ride-alongs!

The researcher would regularly report to the team in the car (read: provide live translations from Hindi to English) what they saw or heard from the delivery person while on a motorbike. From the car, the team could observe what was happening and ask the delivery person questions via the researcher. When the delivery person went to pick up food from a restaurant or to drop off food for a customer, the team could observe the entire experience. Needless to say, the delivery people we recruited for this study signed up voluntarily and were compensated for their participation in our study.

Coming up with this method took time. We needed to capture the trip experience of delivery people in certain specific situations and we needed to see how they behaved in that context. We knew that no traditional method would fit the situation and that we needed to get creative.

Now, in many situations traditional methods will work just fine, but it’s worth considering if there is something that you can add to this traditional method to capture some more interesting data points that will make your insights stronger or uncover nuances that might otherwise be missed. In situations where traditional methods don’t work, push yourself to think about how to function within constraints and how you would put together an entirely new method. However, remember to be mindful of and vocal about the pros/cons and potential constraints/biases of any new method.

5. Bring stakeholders into the field

“I hear and I forget. I see and I remember. I do and I understand”. — Confucius

When I think back to my research projects, I find a clear difference in the level of agency and motivation that stakeholders had when they’d experienced or seen a user problem first hand versus when they’d just read about it in a slide deck. By taking cross-functional team members (product managers, engineers, designers, data scientists, etc.) into the field, not only do we help generate empathy for users, we also build deeper appreciation for and better understanding of the methods and processes researchers use. My team and I always end up coming back from the field inspired to collaborate and make changes together.

Before taking everyone out to the field, make sure to give them some preparation. Trainings before field trips help stakeholders understand what to expect. These trainings can include instructions on how to prepare for research sessions as well as guidance on how to take notes, photos, and videos during sessions, tips on moderating sessions, and how to make the most of your research post-field trip. This makes team members feel more confident and better prepared to handle field days.

6. Experiment with new methods of sharing insights

Most research reports end in traditional slide decks/documents, but there is value in exploring other ways of sharing insights. While slide decks offer a consolidated view of all findings, they are also time-consuming to put together, and some situations could benefit from more real-time share-outs.

For the global beta of the Uber Driver app, we conducted a three-week-long research sprint in six cities globally. This was a large effort affecting about 3 million drivers across the world and the majority of the product development team was based in San Francisco. We did not want this beta research to be like a traditional research project where researchers conduct studies in a remote market with a small team, then communicate findings back to the larger team in a couple of weeks. We wanted the team to feel closer to the users in all possible aspects. We believed that would create more empathy, provide more agency and hence make the team more invested in the findings and prompt quick action. To enable this, we experimented with posting bite-sized unsynthesized pieces of data (which we later called “atomic evidence”) right after a research session on a G+ group. This was an internal G+ group that included all cross-functional tech and operations teams that were involved in the development and launch of the beta app. Through this, stakeholders were able to see feedback from a driver in Bangalore or Jakarta, for example, not days later, but minutes or hours after we did a ride-along.

We were surprised to see that our research went viral within the company! Stakeholders were highly engaged and quickly started workstreams right on G+. This prompt response in turn motivated researchers to surface more meaningful stories. The drivers who we were conducting the research with, were able to learn about the progress through the researchers and could even see some of the changes made to the beta app during our study. We were eventually able to see quick impact along with a positive sentiment from app users and internal stakeholders alike. We attributed a large part of the success of this research project to this novel method of sharing-out.

7. Collaborate cross-functionally

You can’t and won’t be able to do everything. You will be an expert at certain research skills and there will be others on the team who have mastered complementary skills. Collaborate with them. There is so much wealth that one ends up uncovering when working with cross-functional partners like data scientists, marketing researchers, and product marketing managers.

Capitalize on these different functions and skill sets. For example, when you see an unusual, unique or important user behavior in the field, ask a data scientist to see if this is a common behavior based on log data. Try to map your learnings with what the customer support team notices in support tickets. Try to work with cross-regional teams to see how user behavior is similar or different in different regions.

8. Expect the unexpected

There will always be surprises in the field. Keep calm and continue researching. Before each of my field research trips, I make long and extensive checklists. I make sure that all the participating cross-functional teammates and external vendors (if involved) are on the same page, and ensure that all equipment is charged the night before. But despite all this planning, when I am in the field, countless things can go wrong — mobile networks fail and you can’t contact stakeholders, your note-taker calls in sick, traffic delays your interview by 30 minutes, your voice recorder runs out of batteries., the list goes on and on.

These situations can happen to anyone. The key is to keep calm, be patient, and be flexible. Forgive yourself quickly and try to make use of the available resources in that moment. I like to build in buffer-time between sessions and use that time to figure out a plan B if needed. Always account for traffic unpredictability, have a list of back-up participants that can be contacted in case of dropouts, and have most of your research resources (interview guides, artifacts) available offline or on paper. And most importantly, know that there is only so much you can control, so take things in stride.

9. Reflect, recover…and then act

Research can be overwhelming. Participants are opening up their lives to you, and even when it is uplifting, it can be emotionally draining to learn about people’s lives, about their hopes, fears and dreams. Take time to soak it all in; take time to reflect on it.

Don’t cram too much in one day — I try to give myself enough time between sessions to debrief with others and to think on what I’ve learned. At the same time, know that when you are getting to know someone’s personal stories — how they live, how they earn money, how they take care of their families — this disclosure comes with a responsibility. Take stewardship of what you learn. Be protective of and accountable to your users’ wants and needs. Be their voice. Be loud and persistent. That is what makes our lives as researchers enriching and fulfilling.

10. Never “I”, always “we”

This is something I first learned from my professor at design school (Department of Design, IIT Guwahati) and it’s been constantly reinforced over my last three and a half years at Uber. Whenever describing research, I never use the word “I”. There are so many people who contribute directly or indirectly to a project, and I find it almost arrogant to talk about any project using “I” even if I am leading it.

It takes a village to get a research project done. Product managers and designers help decide most important research questions. Data scientists help pull data to build hypotheses around research questions. Research operations experts help recruit participants. Cross-functional teams join as notetakers and observers. On-ground operations teams help set up local logistics…these are just a few of the many people who get involved. I make it a point to acknowledge their efforts and contributions. Every project is “our” project. A simple change in pronoun more accurately reflects all the work behind-the-scenes, and provides a more inclusive and encouraging sentiment for everyone on the team.

Over the last three and a half years at Uber, I find myself incredibly lucky to have had a job that’s enabled me to be a part of so many lives across the globe. I am grateful to our users for sharing their lives and their stories, and am humbled and inspired by the opportunity to impact those lives and those stories in a meaningful way. This has been a truly rewarding journey. As Uber moves into new products and verticals and further matures as a company, I am excited to see what new opportunities arise for research and curious to explore how our tactics and methods will change.

So: that’s my story. What’s yours? Whether you’re a research vet, a newbie, or just the bearer of a curious mind, I’d love to hear your story! Feel free to comment here or email me at minal.jain@uber.com

Ten things I’ve learned as a UX researcher at Uber was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Being pulled in multiple directions is a familiar feeling for all working parents. Parenting is a full-time job in itself, and many of us simultaneously pursue a full-time career. It’s a challenging dichotomy: when we’re at work, what is going on at home can preoccupy our minds, and when we’re at home, we’re always only one email notification away from being pulled back into thinking about work. The tech industry in particular is famous for an “always on” work mentality and overflowing calendars, and it’s easy to find ourselves trying to sort through what seems like never-ending lists of projects (both at work and at home) waiting for prioritization and completion.

As a group of parents who work at Uber in Seattle, we’ve given a lot of thought as to how we can help our workplace come together to support parents. (Sorry, we don’t have a mythical solution to help us all balance our lives perfectly — we’ll let you know when that one releases.) We realized that, though many of our coworkers share the same reality, working parents often feel alone in this dual existence and hesitate to address it. We set out this past year to tackle this missed opportunity: to not only comfortably bring our whole selves to work, but also to better support one another. In this article, we’ll reflect on how we came together as parents to create a local support infrastructure, offer kid-friendly events to broaden our office’s cultural offerings, and create a safe space for parents to talk about their needs and challenges associated with being a working parent.

Many companies have global resource groups for parents, but in our case, we found we were missing a local support system — so we built one of our own. We wanted to complement the offerings of the San Francisco-based Parents at Uber employee resource group. Our engagement model, shown in Figure 1, worked well for us, and we hope it might inspire you to spark a support system in your office. We spend so much of our lives in our offices and thinking about our careers, and everyone, not just working parents, can benefit from an open and inclusive professional environment that feeds our whole selves, not just our career goals.

Learning #1: Don’t overthink, just do

We’re all busy with a number of commitments. Sometimes with so many responsibilities both in and outside the office, we might overanalyze tackling new endeavors. Particularly as working parents, we’ve all asked ourselves, “Do we really have time?” “Can we balance this all?” Thoughts of scheduling nightmares with extra meetings and responsibilities alongside those pediatric dental checkups that can only take place during the work day…we get it. But we’re here to tell you that yes, while it’s important to consider all of our commitments, overthinking can sometimes lead to analysis paralysis. We encourage you to put aside the overthinking and just get started.

To avoid overthinking, start small. Don’t think of hosting extravagant events; start with an intro meeting. Set up a 30-minute meet and greet, invite all the parents in your office, and encourage them to invite other parents. In this initial meeting, you can encourage everyone to introduce themselves and share what they’d hope to gain from the group. This conversation will help you decide how you can best support one another. In our case, parents in the Uber Seattle office talked about having a safe space in which to ask questions and talk about the challenges associated with raising children at any stage. To respond to this need, we set up a “Parents at Uber — Seattle” channel on our internal chat system and initiated monthly brown bag lunches. We’ve already seen helpful posts answered about kid-friendly day trips, doctor recommendations, and back-up childcare. We’ve also spent casual and meaningful lunch hours talking about things like how to communicate more effectively with kids. Neither of these require much bandwidth from event organizers, but they offer real opportunities for parents to connect, ask questions, offer advice, and learn from each other.

Learning #2: Ask for help

We’re all relentless in the pursuit of excellence at our jobs, and we often have specific goals to develop our skills and master our craft. It’s easy to fall into a panic when we’re constantly swamped with work that feels distracting from these goals. We might also fall into an assumption that the time involved in coaching others to do a job takes longer than simply doing it yourself. The trap of “I can do everything by myself” is a dangerous thing for working parents. In our Seattle Parents at Uber group (and in our parental lives), we’ve found the opposite to be true: understanding that you can’t do everything AND reaching out for help demonstrates both humility and strength, as well as, sending a valuable message to our children about teamwork and collaboration.

In our supportive and understanding group, we lean on each other to get things done regardless of the ebb and flow of our demanding “regular” jobs. We’ve seen other members regularly step up to lead events or help lessen the load when workloads increase, vacations or sick days happen, or members even go on parental leave. Openly and transparently sharing concerns and responsibilities has resulted in all of us being happier, less stressed (at home and work) and more productive, which is a great win.

Learning #3: Include everyone

We’ve cultivated an active group of individuals that coordinates activities geared toward the parent community. However, one special group that we’ve learned to actively include is colleagues who aren’t parents but love supporting kid-friendly events! Maybe your deskmate has a background in caregiving and could lead a brown bag lunch on how to care for children in an emergency situation, or maybe — as was the case at Uber Seattle — they are a talented fellow designer who can help produce a visual identity and signage that promotes your next kid-friendly office event. We’ve heard directly from colleagues without kids that helping out has brought them joy. It really is a win for everyone! While these office events themselves have proved invaluable to parents at Uber, we wouldn’t be able to pull them off without the help of the entire company (see Figure 2).

Learning #4: Take time to reflect before moving on

After the event is over, it’s tempting to quickly move onto the next thing on the calendar, but we’ve found that pausing to reflect afterwards is an effective way to learn from the event, make sure our audience’s needs are being met, and prepare for future events. We’ve done so by sending brief surveys to participants to hear their experience and asking around the office for feedback. As a planning group, we also regularly talk about what went well and what we’d change in the future. Such purposeful reflection allows us to thoughtfully take on future plans, which leads nicely into our next learning about how valuable it can be to…

Learning #5: Create playbooks

Our final learning brings it altogether: spend the extra time to create playbooks so that activities can easily be shared or replicated in the future by different people (see Figure 3). In the past, legacy knowledge was often held by one person who might not be available, and we really scrambled to recreate events. Cutting down future questions is always a timesaver, right? One solution we found to avoid needing to reinvent the wheel was to create an event playbook. We’ve had organizers type up guides for hosting things like a school-supply drive or an office family-friendly Halloween party. These simple documents allow a potential organizer to (1) share a timeline and necessary processes, (2) pass off learnings, and (3) make it possible for others to organize similar events in the future. While creating playbooks is admittedly an extra step at the end of an event, it’s a huge value-add that wraps up the event and ensures the group’s future success, and provides a template for other groups to use to create events of their own.

Get involved

We hope you’re energized about the potential of creating or contributing to a parents group in your workplace. (Or a group centered around another common life experience!) You might still be a little hesitant, asking yourself a number of questions like, “is this work?” “Do we have the resources?” Yes, it requires some upfront effort, but there isn’t much that succeeds without some effort (which we definitely know as parents!). In terms of resources, a sense of community can grow without much budget. We listened (which is free) to our group’s need for a safe space and then designed low-cost events like informal brown bag lunches to foster such a space. And as we’ve learned, when we ask other people to be involved or to lead activities, it makes everything more manageable and it benefits everyone who participates. And on a final note: it’s worth it! If you can create a space that helps even one (or many) parent(s) feel less alone in the daily work-life world, your work is a success. The support structure we’ve created at our Uber Seattle office is welcoming of parents, yes, but moreover, it’s a safe space in which parents can bring our whole selves to work and give voice to what matters to us.

Creating workplace support for parents doesn’t have to break the time or money bank was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the late 20th century, the dominant technological question was “How do we learn better?” In the early 21st, that question has been followed by “How do we better use the things we’ve learned?” Uber is powered by information. Chances are good that your company is, too. We’ve all had firsthand experiences of an inconvenient truth: information is only as good as our ability to make use of it. If a roadmap is locked in the glove compartment, no matter how detailed it is, it’s not much use on a road trip. Managing, sharing, and learning from that information is the key to using it successfully.

Around the world, our engineers, researchers, designers, product managers and every member of every team learn new things that can make Uber better. We want to be sure that these insights could be easily submitted and shared so that a team didn’t waste time relearning in Mumbai what another team in Mexico City has already experienced.

That’s why we created Kaleidoscope.

This challenge is by no means unique to Uber. At your company:

• Do you want to make an impact with your insights?
• Do you need to find existing information and domain experts?
• Do you want to share insights from a specific project more broadly than with your immediate team?

Learnings, data, and ideas — when put together — represent dynamic patterns, as varied and colorful as the view through a kaleidoscope. Where a telescope offers a single long view and a microscope an in-depth, narrow view, a kaleidoscope triangulates changing views to create new patterns. Like a kaleidoscope our new insights platform allows teams to come together to create a macro-view that takes into account varying sources and perspectives. It’s through seeing and making sense from these changing patterns that we can perceive new images and pursue new possibilities.

Sharing vs. silos

At Uber, we are working to embrace insights across all levels and functions and strive to learn globally and diversify our perspectives in order to develop an effective long-term strategy.

At some companies, the science-based disciplines of research — including user experience research, marketing research, and data science — are viewed as more strategic, while operations-based insights from customer support and regional operations are seen as more tactical. They are frequently seen as separate categories, with little cooperation required or even desired between the two. Fortunately, we don’t feel that way at Uber.

I lead the Insights Platform, a group within User Experience Research. Our mission is to increase the impact of insights globally to inspire and inform Uber’s vision and priorities. The foundation of the Insights Platform is the belief that insights from all functions globally are valuable and that methodologically sound and valid insights can come from many places. In other words, we all have a lot we can learn from each other.

From our team’s inception, we knew that organizations across Uber would be “smarter together”, rather than remaining in “knowledge silos.” Our aims were simple:

• Share insights from a variety of teams around the world
• Inspire and inform the company’s decisions on where to invest resources

Simple, maybe…but not easy. Here’s how we set about accomplishing our goals.

Our Process

These are the steps we took to get to where we are today.

First: Developing our strategy

Our audacious goal was to build a holistic insights solution that could consistently deliver global and actionable insights to inform Uber’s priorities. While the expectation from stakeholders and leadership was to create a database to house insights, our strong belief has been that without mobilizing the necessary people and methodologies to gather, synthesize, and leverage those insights, the database would be ineffective. You can build the biggest library in the world, but without librarians and a card catalog, it’s pretty useless: without the people and process to leverage the database, impact would fall short.

Second: Establishing a unified insights taxonomy

Our first step was to develop an insight structure that anyone could use to import or export data. Because insights come from a wide range of data and sources, with functions responsible for different types of insights, we needed to define a unified way to navigate the data.

After reviewing more than 800 insights previously gathered in one planning cycle across the company, we noticed a few problems in the way insights were considered and presented. Insights varied in level of granularity and ran the gamut from a few words to a paragraph in length. Facts were often presented as insights without rationale, context, or explanation. A lot of insights were tactical recommendations to fix bugs, which, while important, did not address the larger issues and ignored the potential for a deeper, more lasting impact.

From this analysis, we established the insights taxonomy for Uber, striving for simplicity, consistency, and actionability. The insights taxonomy consists of the following components:

1. Insight statement: A succinct expression of what has been learned based on facts. It should be written with the syntax of “who + where + what + why” in order to be descriptive enough to stand alone and invite the reader to learn more.

• The ‘what’ explains the behavior, occurrence or situation that is notable or problematic.
• The ‘why’ explains the assumed reason for a behavior, occurrence or situation. From our audit of previous insights, the ‘why’ was most commonly missing from insights, and also the most critical part. The ‘why’ is the learning or takeaway.

2. Facts: Data from surveys and experiments that support an insight; anecdotes, user quotes and observations from qualitative research, analysis from customer support.

3. Opportunities: Recommended actions based on the insight. These can range from tactical to high-level “how might we” statements.

Third: Understanding internal users’ needs and motivations

The insights database exists to help Uber employees build better products and programs. We sought to establish a foundational understanding of our users through work sessions and user research, eventually arriving at two key user groups to design for: “insights creators” (who generate insights from various sources) and “insights consumers” (who use insights for learning and informing decisions).

We conducted several rounds of initial 1-on-1 interviews to understand the common needs and motivations for each group, and then followed up with iterative usability research. Users continue to help us prioritize feature development for the tool and our program.

Fourth: Identifying partners, piloting processes

Since this is our first cross-functional tool for insights and document discovery, we needed to establish an ongoing process for engagement. We conducted a few pilot programs to gather insights with our team of 90+ UX researchers. The purpose of these pilots was to test out the insights taxonomy, the approach without any custom tools, and the type of guidance users needed. Once we defined the process of submitting insights, we established a network of insights creators who shared common beliefs about knowledge sharing.

Fifth: Developing the minimal viable product, then iterating

Concurrent to the pilots, we built a simple MVP using external database software. With our MVP, we were able to bring to life the concept of the tool. Through some initial trials, we realized that the software itself posed too many usability limitations.

Through iterative user testing, we developed a design brief for the next iteration, which dramatically improved the user experience of our insights tool, generating awareness and excitement from users across the company at a company-wide launch. We continue to develop important features and functionality guided by our original vision and based on feedback from users. We are also integrating our insights database with other internal collaboration tools to optimize engagement and grow our platform of tools to serve existing workflows.

Principles of Uber’s Insights Platform

As our team moves into the second half of the year since launch, we reflected upon the learnings we have gathered from our successes and challenges so far.

Connect systems, rather than supersede

Each team and subteam at Uber has its own system of organizing insights and documents, as well as their own ways of sharing out their work to stakeholders. Some systems were already quite advanced at our launch, while others were just being created.

Many groups asked if they should override their existing system with our insights database. Others were reluctant to use another system, as their own was sufficient for their team’s purposes and challenging enough to maintain.

I use the mental model of “connecting strings of Christmas lights.” Each team is already shining bright in their own worlds. The most value we add is to connect these nodes and create a network that intersects. Never underestimate the power of connection.

Context and interaction are key to collaboration

While our focus has been to create an efficient, self-serve tool for sharing and discovering insights with supporting documentation and authors, we learned quickly that what users — researchers and product managers alike — desired was real-world, face-to-face connection with others exploring the same topics.

In early user studies for the insights database, users described wanting to find other subject matter experts to talk to. These experts could be from other functions and other regions who have knowledge and experience on their topic of interest from the past or present.

We learned that having context around insights and data gave contributors a sense of trust that information would not be misinterpreted. Context comes in the form of having robust supporting documentation, experts to follow-up with, and the assurance that the information is vetted for quality by our insights analyst who reviews each and every insight for consistency.

Triangulating insights drives focus and perspective
Deep knowledge on a particular user type, domain or geographical region through a single lens is highly valuable and actionable. Being able to aggregate and synthesize that deep knowledge from across functions and regions provides a holistic perspective on problems and opportunities that are more broadly addressable.

Validation and visible outcomes help sustain engagement

Building new organizational habits is difficult, particularly in a fast-paced, globally distributed company like Uber. Asking research, data science, and operations teams to share insights in an ongoing way requires reciprocity in the form of feedback from peers and leaders, and validation that their work is driving action.

In exchange for the visibility of their work, contributors ask for evidence that their insights are being put to use. Therefore, our team is currently working on features for the insights database aimed at enabling social engagement and activity tracking for insights — features that allow contributors to respond to comments and questions, track the number of views, and understand how their work is being used to stimulate more engagement.

By directly citing insights, bodies of work, and authors, we validate the hard work of contributors and create a currency system for insights and their application. At the end of the day, everyone would like to see how their work is making an impact on the decisions of the company.

The future of insights is now

This project originally envisioned a technical problem with a technical solution: a repository for insights. As we worked, however, we quickly came to understand that a piece of software — while vital — could only be one component of our solution. We realized that, after all, insights are more than just pieces of information. They are applied knowledge: created, developed, and improved upon by people and their networks together, not in isolation.

We needed to respect all aspects of this relationship to ensure quality and actionable insights. We built our strategy on three inextricable components:

• Partners: Empower a cross-functional, global insights network
• Process: Establish processes to generate and leverage insights to identify gaps and inform priorities
• Product: Enable access to insights for ongoing projects and planning through an open, self-serve tool

By building a tool that facilitates dynamic, sustained interaction between insights creators and insights consumers, we create something much richer than a simple repository of static information. Just as our network of people becomes self-reinforcing, so too does our network of insights, as creators and consumers cross-reference and make connections across products and categories. By establishing a process with engaged users, Kaleidoscope becomes the best kind of informational network: one that teaches us what it is in real-time.

As that network evolves, so will this project and our Insights Platform function. Because, ultimately, what is a kaleidoscope but a mechanism for the simultaneous creation and appreciation of beautiful patterns? As we continue to create those insights and learn from each other, Kaleidoscope will continue to change and grow.

About the author:

Etienne Fang leads the Insights Platform in UX Research at Uber. She is dedicated to increasing the impact of insights globally and cross-functionally at the company to enhance collaboration. With nearly two decades of experience in research, design, and strategy, Etienne thrives at the convergence of these disciplines to create new value for organizations. In and outside of work, she is passionate about people and the power of their stories to inspire change.

Connect with her on LinkedIn. Follow her passion project about women around the world: “Having It All Project” on the web www.having-it-all.org and on Instagram @having.it.all

Special thanks to:

Molly Stevens

Insights Platform team: Hallie Saber, Isabelle Elias

Kaleidoscope Designers: Charlie Waite, Stephanie Brisendine

Kaleidoscope Engineers: Benjamin Booth, Chris Duarte, Chris Hale, Eugene Sosnov, Garrik Sturges, Mo Kouli

Collaborators: Bob Cowherd, Jeb Burchenal, Pomi Tefera, Steph Tung

Supporters: Manik Gupta, Michael Gough, Mike Shoemaker

If you are interested in joining our team, please check out the current job listings.

The Power of Insights: A behind-the-scenes look at the new insights platform at Uber was originally published in Uber Design on Medium, where people are continuing the conversation by highlighting and responding to this story.