Internal workshops can be a great alternative to office parties and team building events when it comes to onboarding new employees and fostering relationships within a team. You can take our word for it — we did an 8-hour-long “test drive” for you! In this article, we will share our experience of running a workshop for a design team. Let’s get right to it!

Before the workshop

Before getting all the team members together and kicking off the creative process, we did some preparation. That is, setting the workshop’s goal and objectives, stating the approach to be used, and dividing the roles. This helped us to make sure that everybody is on the same page. Once we had it done, the workshop was ready to run smoothly (as smoothly as it potentially could… since it was our first time!).

Let us walk you through those steps with our own example — an internal workshop dedicated to the design of the Uber Super App.

Goal

Our design team has grown a lot during the last few months — now there are six amazing people, working from our two different offices, located in Omsk and Krasnodar. We needed to find a way to foster both professional and interpersonal relationships when standard team-building events wouldn’t work due to the distance. Brainstorming and creating alongside each other during a half online & half offline workshop appeared to be an optimal solution for us.

Objective

For 8 hours the team was working on the design concept of Uber Super App — an Uber’s service with the expanded functionality that includes food and grocery delivery. The idea was born after the news about Uber’s acquisition of a food delivery startup, Postmates.

Approach

We decided to use the JTBD (Jobs To Be Done) framework. The JTBD theory is based on the notion that people buy products and services to get a “job” done. The focus is shifted from the target audience’s characteristics to the context in which the product can be useful for a user. This decision is justified when the target audience is heterogeneous in composition — just like in the case of a taxi ordering service.

Roles

Every team member got assigned a specific role from the ones below:

The interface designers were in charge of the introduction of new functionality and identification of food ordering and delivery scenarios. The Promo designer was busy identifying the app’s offline and online entry points, creating an onboarding process, and elaborating a subscription model. The analyst was the voice of the customer — he was conducting interviews along with analyzing and testing the team’s hypotheses. And, finally, the product owner was coordinating the whole project.

Constraints

As we were working on the concept of an already existing app, the main condition of the workshop was to create UI within Uber’s design system (https://brand.uber.com/). We also used Mobbin — a tool for searching the most popular apps’ screens, and Uber’s guidelines in Figma.

During the workshop

Step #1. Preliminary research

First things first, we needed to identify the problem that the app was going to solve.

How can Uber Super App help its users achieve what they want? All design solutions should be addressing this problem in one way or another.

The product owner prepared an information base that helped the designers better understand the service and its limitations by comparing it with its direct and indirect competitors.

Designers reviewed the above apps in detail and analyzed their navigation, control elements, and pros & cons.

Step #2. Brainstorming

During a 40-minute-long brainstorming session, the team came up with ideas for the app’s concept and collected hypotheses for testing. Apart from adding food and courier delivery, we decided to go further and expand the app’s functionality with:

• packages delivery with an AR ruler
• food order creation together with friends
• voice assistant
• Instagram-like stories with recipes

Step #3. Testing ideas

Before implementing any idea, a designer must be sure that their assumptions and expectations align with the ones of the users. So all ideas that were born during the brainstorm session had to be tested on a sample from the target audience.

To test our ideas and identify priority areas for future work, we decided to use the Ask the Crowd method. The sample consisted of 60 people (the rest of the Ronas IT team) that fit the Uber Super App’s target audience. We created surveys and collected the results using Google Forms.

First, we asked how often people use taxi and food delivery services and what problems they are currently facing when using them, how long they are ready to wait for the delivery, and what they usually do on a ride. By identifying the most popular answers, we got a general idea of the users’ behavior and preferences.

For example, the survey showed that users like the idea of ”co-ordering”. When we order food delivery for a group of friends, the total bill has to be divided manually (that’s always such a mess!) , so it’s preferred if the app itself can split the bill between users.

Step #4. The marketing component of the design

This step consisted of the implementation of the Voice Assistant and the creation of the onboarding. Both of them help to introduce the user to the new functionalities and explain how to use them.

At the beginning of the ride, the voice assistant greets the passengers from the driver’s phone, asks them to buckle up, announces the travel time, and describes the new functionalities.

We used the voice assistant as the entry point to the app. If the passenger is not an Uber user, and the taxi was ordered for him/her by another person, then such onboarding will serve as a call-to-action for the passenger to install the Uber app. This type of interaction is called Zero UI Design.

Inside the application, an introduction to the new functionalities begins with several screens when opening the app. The first screen tells the users that now they can “use their travel time smart.” The following screens show exactly how: by ordering dinner on the way or by delivering a package with a drone or Uber. The final screen introduces the user to the Uber Pass subscription. To be clear, we didn’t invent it, but used the current subscription screen, adding one item about delivery.

After onboarding, we keep reminding users about new features with Instagram-like stories. Stories don’t promote the new functionality directly, instead, they can suggest a dinner recipe with a list of ingredients that can be ordered through the app.

Step #5. Functionality implementation

Home screen

The home screen should show the user that Uber now has mini-apps (food delivery, courier delivery, etc.). At the same time, we didn’t want to switch the focus from the core functionality completely. Uber is primarily a ride-hailing app, so we kept the spotlight on the map, hints, and a large input field for entering a destination address, and then added new buttons to navigate to mini-apps.

The problems with the interface creation started with the visual presentation of mini-apps. To go to a selected mini-app, users must tap on its icon. The first option of the home screen UI (screen 1) had tiles without a white background. After testing, we had to ditch it, as users didn’t understand that the tiles could be swiped up to open the backdrop (screen 3) with other mini-apps and smart feed. So the solution became obvious and we added the white background to the tiles, which helped to make the app’s navigation more intuitive.

With the addition of new functionality, we faced the fact that some of the old features, such as renting bicycles and scooters, became inconvenient to use. So we brought them to the home screen with brief information about availability.

Food ordering

We used a standard food delivery scenario, where the user can:

• choose restaurants by type of cuisine
• specify the number of persons
• order at the nearest restaurants
• view previous orders

We also added the option of “co-ordering” — a feature that allows users to order food for a group of friends and split the bill between each other in the application.

The idea of “co-ordering” came to us when we were discussing food ordering in general. Splitting a bill in the app is much more convenient than calculating how much money you have to transfer to your friend. We made a joint shopping cart where several users can modify an order and pay for it.

During the workshop, we didn’t have enough time to test all of our theories. At what stage of the order is it more convenient for a user to choose a payment option? Do users need the ability to pay for individual dishes? And how about synchronizing shopping carts of different users? We’d love to test these questions if not the time constraint.

Since the concept of the super app was supposed to unite the services of Uber, we transferred some of the elements and patterns from Uber Eats and Postmates apps, indicating their continuity.

Packages delivery

Uber is already partnering with various courier services to deliver food, and we decided to add courier delivery for personal packages. There are several tariffs to pick from:

• a drone for small items and documents
• a courier for light packages
• a car for oversized cargo and heavy packages for long distances

The logic of ordering package delivery is the same as of ordering a taxi. The user chooses the points where to pick up and where to deliver the items; they can track the delivery status and the expected time of arrival, as well as they can contact the courier.

We added an AR ruler to measure package dimensions. It works like this: the user presses the ruler button and the camera opens. The user places the package in the area of the camera, and with augmented reality, they can see the dimensions of the package, on the basis of which a suitable tariff is selected.

Step #6. Testing the design concept

We tested the created concept using the Side by Side method. We showed the app’s potential users different versions of the same screens and asked them to choose the best one.

For example, we could divide choosing a taxi and a payment method into two screens or leave both of them on the same screen. The majority of users voted for “on the same screen” because having all the important information available at hand makes it easier to make a decision.

We also listened to the users’ opinions when choosing between two different versions of the Home screen and the Order screen.

Side by Side survey helped us to make decisions easier and faster. And, most importantly, those decisions were based not on our assumptions, but on the preferences of potential future users of the app.

After the workshop

After our workshop we have not only a new project in Figma named “Uber Super App”, but also some takeaways:

1. The workshop format is a great solution for teams that work remotely or that can’t involve all team members in real projects at once.
2. The workshop format is a great solution for teams that work remotely or that can’t involve all team members in real projects at once.
3. Workshops are a new and interesting alternative to team building events, that can serve various purposes.
4. The workshop allowed us to see the strong and weak sides of each participant and of the team as a whole.
5. We faced the challenge of working with third-party design systems, the features of which can’t be fully understood in the format of an 8-hour workshop. It’s a great exercise for your design muscles, however!
6. We actively used surveys and research, which has put us in the shoes of the users and helped us see the design process from another perspective.
7. We realized that the JTBD methodology works better for product sprints, where the focus is on finding and solving problems, while Customer Journey Mapping is centered around understanding the behavior of existing users.

TL;DR: workshops are a great alternative to team building events, that can serve various purposes such as introducing team members to each other, getting new employees familiar with internal standards and guidelines, trying on new roles, and unwinding from the day-to-day tasks. If your team has never done anything like this before — go ahead and try it for yourself!