Case Study: Data Model Change & Redesign

Background

Cloud kitchens are equipped spaces created for delivery that cover the gap between demand and supply in a particular area. Each facility is divided into stalls that partners rent out to operate food brands.

At the time I joined the team, facility and partner data was spread across many spreadsheets and services. This made its collection inaccurate, which resulted in bad quality data to be consumed by our teams.

Additionally, tracking operational and financial performance on a stall level wasn’t possible. As there was no data source providing stall and partner information.

The Challenge

Our high-level goal for this project was to change the data model to get more detailed and reliable data from facilities and partners. We believed that by doing so, we would help drive better strategic decision-making and bring success to the business.

To achieve this change, we needed to include stall and partner information in our product. Making it the unique source of truth for our products and reports.

Role

As a Senior Product Designer, my responsibilities were to:

• Collaborate with Data and Engineering to rework the data model.

• Conduct UX Research with Business and Operations.

• Lead the redesign of the current interface to adapt it to the new data model (including stall and partner information).

• Rethink and improve the current UX.

• Create a temporal UI that helped with the old data migration.

Data Model Rework

I collaborated with the Data team and Engineering to help redefine the data model, and the relationship between the new elements.

We introduced Stalls and Partners to the existing schema and defined the relationship:

• Facilities are now based on stalls. A facility has many stalls and each stall can accommodate 1 or more vendors in it. Each stall can be operated only by 1 partner.

• A partner is the company renting the stall and can operate 1 or more vendors inside it. A partner can operate in more than 1 stall and in more than 1 kitchen.

Feature Proposal

As a consequence of the changes in the data model, there was a need to redesign the current interface to reflect it. And add a way to collect information on brands’ operators.

The current interface was a list of facilities and their details. Our users could navigate inside each facility and see its details and a list of vendors. By selecting a vendor, a modal would open with its details and settings.

One of the problems of the interface was that changing a vendor setting wasn’t easy. And this was one of the main goals of kitchen managers.

To do that, they would have to navigate into a facility and find a vendor. Then open the vendor details and find a particular setting. These many navigation levels and information was disorienting for our users.

Once they changed the setting of a vendor, they would have to submit the changes 2 times: in the vendor modal and in the facility details. Although we added a confirmation modal to avoid data loss, this pattern was still confusing for them.

Additionally, kitchen managers missed having an overview of the facilities and stalls they managed. They couldn’t compare data at a stall or vendor level.

So we decided to split the interface into 2 creation flows: facilities and partners. Partners would get a new page in the product to collect information on brand’s operators.

Ideation to Development

I decided to work with disclosure panels, nested tables and drawers.

Disclosure panels and nested tables conveyed a clear hierarchy between elements. At the same time, they provided a complete overview of facilities, stalls and vendors. Our users would be able to compare different sets of data without having to navigate back and forth.

By using a Drawer for the vendors, we could show the details without leaving the current page. Making task completion more efficient and within the same context.

After several iterations, we finally came up with a fleshed-out solution.

The collaboration continued on Figma. I reused components from the design system we were working on and built others that didn’t exist yet.

We followed the Figma file structure I introduced and builded upon the partner and facility creation flow, including each element detail page.

The ideation phase became mature after continuous iteration. Until we had the final designs for implementation.

Migration Wizard

To successfully migrate the old data, kitchen managers had to add manually the missing stall and partner information.

After a few iterations with Engineering, we decided to split the migration into 3 main steps:

1. Select a facility and assign a stall to each vendor.

2. Create partners and add the missing operator names.

3. Assign a partner to each stall of the list.

I decided to visualize it with a stepper. This task couldn’t be done at once in some cases. That’s why we opted to give the user a chance to leave the process saved and continue it later on.

We opted to make the unassigned row disappear once a stall was assigned. This way we encouraged users to complete as many allocations as possible, and freed space on the list.

Impact

The first reactions from users were very positive. They were happy to have a general overview of the facilities, stalls and vendors.

The Migration Wizard and the new Design exceeded expectations. 3 hours after Release, we were already tracking 100% of live stalls and 100% of live partners in UAE, Kuwait and Qatar.

Our team felt excited to see tables and lists being populated with live data so quickly.

Kitchen Managers didn’t need their old data spreadsheets anymore. They were so sure about it that they even deleted them from their browser’s bookmarks. This made our product their single source of truth for facility and partner data.

Our entire Vertical could now consume reliable data on stall and partner level. This had a direct impact on all our products including performance dashboards, reports and services.

From a design perspective, the team now had an improved and functional design system. This would make collaboration between design and engineering more efficient in the future. As well as delivering better designs to our users.

Reflection

I’m convinced designers should build strong relationships with engineers and product managers.

In this project though, I realized how important it is to also align objectives with the Data team. And how this influences my designs.

Our design system increased in size and sophistication thanks to this project. But it cost us precious time we could have used to deliver software earlier.

We didn’t include the design and implementation of each component in the estimations. Which unexpectedly increased the scope of the project.

During the Quality-Assurance phase, we encountered a couple of bugs and design mismatches. A few of them were because we didn’t have the time to update the components. Others, because engineers were working against the clock to finish the changes.

Sometimes, as Product Designers, we need to decide when a design is “good enough” for the sake of our business. Perfectionism is not a requirement, usually. That’s why we should set an acceptance criteria, and deliver value to our users.