Delivery Hero Vendor Portal: Building UX Design Foundations

Katarina Petrov
13 min readFeb 5, 2022


(Berlin, 2020-present day)
My role: As a Design Manager I helped grow the initial team and define design-related processes together with the team. I lead design processes within the following complex projects and initiatives.

The beginning

In early 2020, after five and a half years spent in a lovely Mjam (Delivery Hero Austria) team, I was transferred to a new team in the Central Delivery Hero in Berlin.

It was super exciting to take on the responsibility of helping to grow a new design team and improve the UX of the then-existing Delivery Hero Restaurant Portal (Vendor Portal (VP)).

I was ready to put all of the learnings from my previous role and position to the test. The challenge was accepted!

Discovery 01: Product Map Analysis & Results

Back in 2019, Portal growth has been already accelerating — new features due to the increase in development capacity were built, new countries joined, and centralization was happening.

But, the current solution for Vendor Portal UX Design, with no UX Guidelines and Principles for designers in place, was struggling to keep up with these new requirements. Designs for the features were developed and scattered across the globe.

As our product was growing, more people and teams were involved. This as well increases inconsistencies across the brands and features leading to unnecessary extra effort from developers and a broken experience for users.

Here is an example of how the Restaurant Performance section looked like in two regions, both using Vendor Portal.

Same feature, similar content, a different design solution

Another thing I noticed was there was no shared understanding of what the big picture of the product looked like and what can be learned about user frustration just by taking a look at it.

So, as one of the first collaborative projects as a new Design Team, we mapped out the entire product with all of the pages and user flows included.

During this study, all of the designers collaborated to identify the most critical visible usability issues the users had to face.

Here’s what we learned just by mapping the Vendor Portal:

  • complex and misleading navigation system,
  • confusing information architecture (eg. no logical arrangement of or order of the main sections)
  • inconsistent UI patterns and lack of conventions,
  • a lack of guiding user flows, often leading to Blackbox (eg. Menu confirmation during onboarding)
  • no solution for different importance levels for different user groups
  • no. of clicks needed to complete a simple task was huge (Vendor performance plugin where the user needs several clicks to see visualizations)
  • a lack of actionable and insightful information and navigation types
  • a lack of support and feedback
  • insightful and unhelpful data representation,
  • a lack of brand representation,
  • poor mobile experience
  • noncompetitive user experience
  • frequent overlapping features and lack of cohesive experience with the other DH products

Discovery 02: Desk Research Results

After we successfully mapped out the most visible usability issues, we documented them and took them as a great start to understanding user needs for the first time. Before 2020 in the Vendor Portal team there were no existing Product teams, therefore just a handful of user interviews or tests were conducted.

To gather as much as possible feedback from a few previous research studies, we conducted desk research to collect learnings from the past.

This method completed our learnings with a deeper understanding of user needs.

As a user ….:

  • I’m confused about where to go to find the information I need
  • I find the navigation system very misleading and complex, so hard to use
  • I find it hard interacting with UI due to inconsistent components and patterns
  • I feel like I need to spend too much time on the portal when I just need to find the information fast and complete the task I need
  • I think I’m getting a lot of redundancy and unnecessary information
  • I want everything to be super simple, easy to use, and mobile-friendly
  • I want the data in all reports to be consistent
  • I want to be told how to improve, not just look at numbers and charts
  • If I buy a marketing promotion, I want to know whether it had an impact or not
  • I always need an expert to help me with using Vendor Portal
  • I need to spend a lot of time & effort learning how to use Vendor Portal
  • I think VP is not competitive: Wolt has many better features!

Having completed the research we felt we had enough information to proceed to the next step — setting a new much-needed set of UX Guidelines and Principles for designers to use when they need to make critical decisions about what they’re building.

Defining Vendor Portal UX Principles

The design team ran a workshop to define the first set of VP UX Principles. We followed the framework described by Jared Spool.

We couldn’t agree more on the guidelines provided by M. Spool on how to create great UX principles:

01. Principles are guiding phrases, rather than statements or global phrases

02. Principles are research-driven: they are giving us guidance to create the right solution to user frustrations

03. Principles distinguish your product from competitors

04. Principles can be revisited and reversed overtime

05. Principles need to be constantly discussed & tested

06. Principles are aligned with stakeholders

After closely reviewing tho most current and critical user frustration we formed guiding phrases answering the following question:

If you were to guide someone in the future to make your product better, what would be the rule of thumb you’d give them as guidance?

The question enabled the team to reframe user frustrations to guiding phrases.

As a result of a one day workshop the team, specifically focusing on points 01 and 02, we were able to define and align on the first set of unrefined* UX principles:

01. Know your audience
Always design by keeping users in mind and celebrating local knowledge and cultural nuance for users and our teams.

02. Insights over raw data
Always present meaningful information (insights) over raw data for users to make further decisions.

03. Design for habit
Always design self-explanatory products by establishing familiarity through following existing patterns.

04. Respect user’s time
Always lead the users towards completing the task as quickly as possible with easily digestible solutions.

05. Friends at first insight
Always design to empower the users’ sense of ownership of their experience.

06. Aim for better

Constantly refine and improve designs in order for them to continue to create the best value for our users.

(*Unrefined UX principles are still a work in progress and are planning to get finalized and refined in Q2 2022)

Design Focus Day

There were still a few things left to be defined before we kicked off the first UX redesign of Vendor Portal features and plugins.

As mentioned Vendor Portal teams were growing and more and more designers were joining teams and starting collaborating on UX improvements.

After we got UX Principles ready for designers to use when building the product, we still needed to define a direction a designer should take when they start taking that path.

Aligning on Visual Design Language

The design team cleared out a day in their calendars for a Design Focus day. We took a day to discuss and develop design directions we would own and use when designing new features.

The goal of defining Visual Design Language was not only to align on one shared language, to build a product with clarity and without friction but also to provide a more cohesive user experience to our users who were using some other already existing products.

We aligned on a few more rules to a new Design Language with a few designers from another DH Restaurant Partner's team in a separate design session. They are building different products, but often share the same users as Vendor Portal.

The result of alignment in multiple sessions was in the first foundations of Visual Design Language to follow:

  • We create a consistent experience by following existing patterns as much as possible
  • Our UI is straightforward. We don’t hide information. We highlight important details. We create a sufficiently guided and supportive experience
  • We think of our users. We ask them. We test. Our visuals show different types of people.
  • We keep our designs clean and simple by using lots of white space and focus.
  • We keep our users informed about what is going on with clarity.
  • We always provide relevant and actionable insights to the vendors
  • Anyone can use our application. Even with slower internet connections and old devices.
  • We design for multiple global brands and support localization.
  • We always keep accessibility in mind

Chardonnay — Vendor Portal Design System: Changing The Strategy & Final Decision

By defining UX Design Foundations for the ever-growing teams, now we were ready to provide a more autonomous process to help designers AND developers collaborate better.

The history

Six months prior the Central VP Team proposed to focus on creating new re-designed portal components and start including them into low maintenance plugins managed by the Central team.

All Global Teams agreed it’s time to build a robust Design System because:

  • A new design system is geared towards taking designers and engineers away from having to reinvent the wheel every time by keeping things consistent and reusable.
  • A new, modern design language for Vendor Portal, is determined to take it away from the early 2000’s design style.
  • Purpose-built with components and patterns specifically for Vendor Portal users and use cases.
  • It’s designed for use by all Portal web-app products teams (including NCR, Stores, etc)
  • We need a comprehensive and ever-evolving Figma library driven by user research and the team’s needs

They even gave it a name: Chardonnay Design System

In addition, other Global plugin teams could also suggest their own solutions and contribute towards creating components that are heavily used by them.

This would slowly result in the development of the entire design system.

Although the team was aware of specific constraints of the proposed execution plan, it still appeared there will be more challenges along the way.

The Challenge

The plan to roll out component by component for the main central plugins was a considerably sufficient short-term plan for the central team, but the project was developing too slowly for it to achieve its objectives in the foreseeable future and serve all global teams in considerable time.
It was still lacking a long term vision and clarity in certain important areas:

  • How will Central and Global teams collaborate in contribution to DS in the future?
  • How long will it take to start using the DS?
  • There was no clear ownership of the project and a lack of dedicated resources to make fast progress.

The challenges the team was facing made the circumstance to build a strong and sustainable design system in a short time, less and less achievable.

Consequently, the team decided to take a step back to explore alternative directions which would potentially get us an effective DS in a very short amount of time.

Exploring alternative directions

In addition to existing goals, we also wanted to ensure that the design system we use is available to all the teams much sooner while still being able to improve user experience and address business outcomes at the same time.

We were considering two directions to achieve that.

Option 1: Accelerating approach would require a dedication of all resources to the project for a limited amount of time to achieve fast progress. The risk of this approach was creating a possible bottleneck on other projects and development.

Option 2: Adopt an existing DS, provided by another Delivery Hero team. We assumed adopting a mature DS, providing all required principles, guidelines, components, and flows, then adding VP specific components and patterns to it by the VP teams, would be the right direction to meet our new expectations and still ensure we are providing the right experience to our end-users.

Decision-making map

We spoke to multiple DH teams who had already developed and implemented design systems or are using some type of frontend libraries and tried to assess each of them against our core expectations:

  • Can we reuse rather than create a new design system yet again?
  • Is the DS mature and exhaustive enough to be immediately reusable (Does it already cover most patterns and components we need?)
  • Would we get sufficient support to use the design system (which teams are using it? What is their collaboration and contribution model? How can we leverage their expertise?)
  • Is it easy to use for our technical teams? (Does it cover our platform & technologies, is it easy to use, is it lightweight to create a fast page load and navigation)?
  • Is it fit for purpose for our product, users, and usage context (e.g. desktop-only internal apps, native mobile B2C, B2B, etc)
  • Is it immediately ready to use? Speed and fit of initial delivery (we want it now)
  • Can the DS support multi-brand products (e.g. variable brand color and graphics)?
Design decision map

None of the systems we investigated could provide the expected benefits

We had to rule out two systems quickly because two of the teams hadn’t built a standalone DS.

We investigated more deeply two remaining Design Systems:
Armor Design System build to accommodate internal DH applications and
Bento is built for consumer-facing apps,
but found that neither was a good solution for us.

Armor Design System (left), Bento Design System (right)

While both existing Design Systems were mature and could be immediately reused, there was no certainty that the different DS owners will be committed to supporting or prioritizing our requirements.

If we’d have specific needs that fall outside of what the adopted DS can currently support, we will be required to align with their contribution model or DS roadmaps. Dependencies would be introduced as our priorities would need to compete with that of other squads that do not build for VP.

If not, we may need to build custom components based on the adopted DS. This results in additional work that negates the benefits of adopting their DS.

Final decision: In parallel, an investigation of ways to improve Chardonnay showed significant promises

Ready to use: Most of Vendor Portal was already built on top of Material-UI by the majority of teams, an open-source UI component library for React framework.
While the Material UI isn’t specifically made for VP type of users, it’s battle-tested, robust, and can be customized, restyled to the extent we need. Using it as a base would provide an acceptable solution very quickly.

All components missing in the existing Chardonnay can be picked from Material UI initially, and we can customize them initially or over time if they are not fit for the purpose.

How Do We Do It: Short-Term Execution Plan

To implement the Chardonnay design system and, in the process, to update the visual styling of Vendor Portal we split the execution plan into a few phases:

Phase 01: Chardonnay team will import generic Material UI components into the Chardonnay library to fill up the gap of missing components within the existing frontend library

Phase 01

Phase 02: Global teams install the generic Material UI components from the Chardonnay component library. Where possible, any custom-developed components should be replaced with Material UI components. Teams slowly start using custom components that are going to be more available in time.

Phase 02

Phase 03: Chardonnay team updates cross-plugin components from generic Material UI to custom Chardonnay style

Global teams work to restyle any plugin-specific custom components in the Chardonnay visual style

Phase 03

Phase 04: When most of the cross-plugin components are available in Frontend Library and most of the plugin-specific components are customized based on Chardonnay Design Direction, side nav and app background are switched to white and localized brand colors are implemented.

Showcasing New Designs

While Design Team was still finalizing the last bits of new UX Foundations, Reporting & Insights team already started incorporating the new design directions and a new design library into the process of revamping some of the Vendor Portal sections that needed the most urgent attention.

There is a lot to be demonstrated about the journey of achieving all the UX improvements showcased below.
But for now, let’s just focus on how the new UX design foundations, described in this story, helped us grow from a place like this…

The old Reporting section

…into this:

I can now say the process of creating all of the new designs wouldn’t be as easy and efficient as it was because of the new UX foundations at hand:

  • We had guiding phrases to follow when we were making critical design decisions
  • We were able to keep the consistency across different sections even in times when lots of new members joined newly created teams
  • We were able to stay focused on what’s important the most — the user and their needs
  • We were able to keep the design clean and straightforward

The process of completing improvements to Vendor Portal UX Design is, by this day, still in progress. The same process is in place while maturing and evangelizing UX Principles and Chardonnay — the design system. This story wants to simply demonstrate how the comprehensive design process can solve the future aspects of not only the ways how the product shall develop, but also how the collaboration between designers, developers, and stakeholders can significantly improve — all thanks to the simple foundation they followed.