Best on a bigger screen

My portfolio is built for a laptop or desktop

The case studies are full of detailed boards, journeys and live prototypes that need room to breathe. Open this page on a wider screen to explore them properly.

Osama Eldrieny (Oo)

Staff Product Designer with 10+ years shaping complex products, backed by deep design-systems expertise, hands-on front-end skills, and leadership across international teams.

  • Enterprise UX
  • AI-Driven Design & Automation
  • Design Systems & Tokens
  • B2B
  • B2C
  • SaaS
  • Team Leadership
  • Mentorship
LinkedIn (opens in a new tab)
Download CV
Portrait of Osama Eldrieny

Portfolio

Case studies

Two screens of the Panda design system: the documentation site behind, and the theme playground in front, with theme controls beside the colour palette and buttons.

How I designed a three-tier token architecture that scales to unlimited themes and cut design-to-code effort by 82% on average

Role:
Design System Lead
Timeline:
5 Weeks
Domain:
Scalable Design Systems for Product Company
View case study
The Booking Manager app on two phones, Home and Calendar, with a notification saying a double booking was prevented.

How I designed one app that syncs Airbnb and Booking.com so hosts stop double-booking their units

Role:
Solo UX Designer
Timeline:
1 Month
Domain:
Short-term rental management
View case study
Two screens of the gas nomination platform: Facilities and Operations Planning behind, and the Suppliers and Demand Centres forecast data step in front.

How I led the move from heavy Excel sheets to a gas nomination platform that saves planners about 68 hours every cycle

Role:
Design Lead
Timeline:
Sep 2023 – Jul 2024 (11 months)
Domain:
Enterprise operations, Oil & Gas
View case study

Case study 01

Token Architecture · Multi-Theme Design System

How I designed a three-tier token architecture that scales to unlimited themes and cut design-to-code effort by 82% on average

A deep-dive into how I defined the token architecture: three tiers of tokens, a shared naming system, and independent theme layers, so brands and modes never leak into each other. I then connected it to code with a Figma-to-code pipeline: a design decision change now needs zero developer effort, and adding a new brand or theme in code takes about an hour instead of days.

Role
Design System Lead
Timeline
5 weeks
Domain
Scalable Design Systems for Product Company
Three floating black tiles stacked like tiers: four small pills at the bottom feed two medium pills, which feed one large pill on top.

Context

The product
A token-based design system with a component library and an automated Figma-to-code workflow. This case study follows its most used component: the Card.
7 independent theme dimensions on the same components
Brand3 modes Color2 modes Language2 modes Typography2 modes Density2 modes Radius3 modes Shadow4 modes
Company size
1000+
Team size
20
Used by
Designers and developers
  • The Card with the Diamond brand (purple).
    Brand · Diamond
  • The Card with the Amber brand (gold and beige).
    Brand · Amber
  • The Card with the Opal brand (blue).
    Brand · Opal
  • The Card with light color mode, Diamond brand.
    Color · Light · Diamond
  • The Card with dark color mode, Diamond brand.
    Color · Dark · Diamond
  • The Card with light color mode, Amber brand.
    Color · Light · Amber
  • The Card with dark color mode, Amber brand.
    Color · Dark · Amber
  • The Card with light color mode, Opal brand.
    Color · Light · Opal
  • The Card with dark color mode, Opal brand.
    Color · Dark · Opal
  • The Card with English, left to right.
    Language · English
  • The Card with Arabic, right to left.
    Language · Arabic
  • The Card with the sans serif typeface in English.
    Typography · Sans serif · English
  • The Card with the serif typeface in English.
    Typography · Serif · English
  • The Card with the sans serif typeface in Arabic.
    Typography · Sans serif · Arabic
  • The Card with the serif typeface in Arabic.
    Typography · Serif · Arabic
  • The Card with comfortable density.
    Density · Comfortable
  • The Card with compact density.
    Density · Compact
  • The Card with square corners.
    Radius · Square
  • The Card with rounded corners.
    Radius · Round
  • The Card with pill-shaped corners.
    Radius · Pills

Section 01

Problem

Design and code named the same decisions differently, and every brand and mode was wired to the same values, so each new theme meant manual rework instead of a simple switch.

  1. Naming
  2. Architecture

This case study focuses on Architecture and Naming. Feel free to ask me later about Pipeline and Workflow.

01 · Problem

Naming

Naming is where communication between design and dev breaks down: two teams name the same five decisions, with nothing in common.

Not scalable
Each new component invents its own names.
Not flexible
Nothing can be themed without editing code.
No shared source of truth
There's no way to trace a code value back to its design decision.

01 · Problem

Architecture

Get the architecture wrong and the structure can't scale: brands and modes lose their independence from each other, tokens become inflexible, and every design decision means manual rework for developers.

Structure mismatch
Modes in one collection don't map to files per theme. The shapes don't fit.
The handoff breaks
Design changes leave Figma, but never reach the product.
One value, wired to everything
No brand or mode boundary in between. Every wire moves together.

01 · Problem

Why does this matter?

For the team

Unified Language
One naming system shared by Figma and code.
Single source of truth
Every value updates design and code together.
Simplified Change Tracking
A flaw doesn't mean rebuilding tokens and components.
Task Automation
Repetitive handoffs run themselves, automatically.

For the company

Time & Cost Efficiency
New brands and modes ship in hours, not projects.
Clear Identity
One source of truth, consistent everywhere.
Strategic resource allocation
Time shifts from theme work to product decisions.
Scalable Solutions
New brands and markets, without rebuilding the system.

Section 02

Challenges

  1. How might we…
  2. Figma vs code
  3. Theming structure

02 · Challenges

How might we…

  • HMW

    Add unlimited themes without ever touching components?

  • HMW

    Let designers change decisions without creating manual work for developers?

  • HMW

    Make Figma tokens and code speak the same language?

  • HMW

    Automate the path from Figma variables to production code?

02 · Challenges

Figma vs code

The challenge
I compared the Figma components with the values in the code and found mismatches and inconsistencies between them.
What I did
I audited the front-end components with developers: how components consume values, and which values are fixed and which are configurable. Only the configurable values became tokens, so new themes can be added without touching the components.
Why
If tokens don't match how components are built in code, automation always breaks. Tokens were treated as API contracts, not visual variables.

02 · Challenges

Theming structure

The challenge
I checked the theming structure and found it was not scalable enough to accept new themes easily.
What I did
With developers, I mapped each theme dimension to the properties it controls, to show what changes and what stays the same.
Why
This defines exactly what needs tokens and keeps each theme independent and combinable.

Section 03

Solutions explored

  1. 4 structures
  2. Trade-offs

Structure 1

Combined themes in many alias collections

  • YesWorks in Figma
  • NoFlexibility to change components independently
  • Needs confirmationIndependent modes (light and dark change on their own)
  • Needs confirmationIndependent brands (one brand's values never affect another)
  • NoThemes expand without Figma limitations
  • NoConverts cleanly from Figma → JSON → CSS, no manual fixes
  • NoNo code changes needed for design updates

Structure 2

Switching from alias to semantic naming

  • YesWorks in Figma
  • YesFlexibility to change components independently
  • Needs confirmationIndependent modes (light and dark change on their own)
  • Needs confirmationIndependent brands (one brand's values never affect another)
  • NoThemes expand without Figma limitations
  • NoConverts cleanly from Figma → JSON → CSS, no manual fixes
  • NoNo code changes needed for design updates

Structure 3

Separating themes into independent collections across token levels

  • YesWorks in Figma
  • YesFlexibility to change components independently
  • Needs confirmationIndependent modes (light and dark change on their own)
  • NoIndependent brands (one brand's values never affect another)
  • YesThemes expand without Figma limitations
  • YesConverts cleanly from Figma → JSON → CSS, no manual fixes
  • YesNo code changes needed for design updates

Structure 4

Making every token collection brand-aware

  • YesWorks in Figma
  • YesFlexibility to change components independently
  • YesIndependent modes (light and dark change on their own)
  • YesIndependent brands (one brand's values never affect another)
  • YesThemes expand without Figma limitations
  • YesConverts cleanly from Figma → JSON → CSS, no manual fixes
  • YesNo code changes needed for design updates

03 · Solutions explored

The four structures compared

Each structure fixed more of the problems than the one before, and only Structure 4 fixed them all

The four structures compared against the evaluation checklist
Checklist itemStructure 1Structure 2Structure 3Structure 4
Works in FigmaYesYesYesYes
Flexibility to change components independentlyNoYesYesYes
Independent modes (light and dark change on their own)Needs confirmationNeeds confirmationNeeds confirmationYes
Independent brands (one brand's values never affect another)Needs confirmationNeeds confirmationNoYes
Themes expand without Figma limitationsNoNoYesYes
Converts cleanly from Figma → JSON → CSS, no manual fixesNoNoYesYes
No code changes needed for design updatesNoNoYesYes

03 · Solutions explored

Trade-offs

  • 1 → 2

    Semantic naming stopped changes from spreading to other components and modes.

  • 2 → 3

    Splitting every token level into its own collection let themes expand past Figma's limits and convert to code automatically.

  • 3 → 4

    Making every token level brand-aware finally gave each brand its own independent values.

Section 04

Final solution

  1. The Tokens Architecture
  2. What each theme controls
  3. The output

04 · Final solution

The Tokens Architecture

Why this solution

Every brand, mode and dimension is fully independent

Safe design iteration: designers change decisions without breaking code

Full automation from Figma to code

New themes can be added without hitting Figma's limits or needing manual fixes

04 · Final solution

What each theme controls

Each theme is independent and controls its own properties

The seven themes, their modes, and the properties each one controls
ThemeModesControls
BrandDiamond, Amber, OpalColors (with Color theme)
ColorLight, DarkColors (with Brand theme)
LanguageEnglish, ArabicDirection, text content, left/right border width, plus typography (with Typography theme)
TypographySerif, Sans-SerifFont family, size, weight, line height (with Language theme)
DensityComfortable, CompactPadding, margin, gap
RadiusSquare, Round, PillsBorder radius
ShadowFlat, Subtle, Default, RaisedShadow X, Y, blur

04 · Final solution · The output

Demo

A live preview of a few components in the browser, as phase 2 of the pilot test.

Open the demo

04 · Final solution · The output

Design System Documentation

A Storybook-style guide to every component, its variants and guidelines, with copy-ready code and a source of truth for AI.

Open the documentation

04 · Final solution · The output

Dashboard Prototype

A dashboard built from the component library, switch between any theme combination.

Open the prototype

Section 05

Validation

  1. Pilot test

    Proving the system early, on one very small component

    • Planned tokens
    • Assigned variables
    • Defined the theme structure
    • Exported to code
    • Changed a decision without touching code
    • Added a new mode, no Figma limits hit

  2. Iterations

    From one component to many

    • Proved the structure on one component
    • New components followed the same structure, with their own tokens

  3. What it confirmed

    Validated in both design and code

    • Changed a decision without editing code
    • Added new components with no restructuring
    • Exported to code with zero manual fixes
    • Added the new theme without a developer

Section 06

Impact

Measurable outcomes

From days to hours, with an 82% average improvement

Measured results of the multi-theme design system
MetricBeforeAfterImprovement
Design decision change2 to 5 days0 developer effort100%
Add new theme in Figma1 day10 minutes98%
Add new theme in code5 days1 hour98%
Design iteration & debugging time80 hrs/sprint56 hrs/sprint (24 hrs saved)30%

Extra mile

I built a Tokens Generator, a Variables to JSON plugin, and a Theme Manager to speed up token creation, keep exported values correct, and make theming possible without code, then shared all three with the community for free.

  • A Design System Tokens Generator promo card: plan, create, and structure design tokens fast, with a preview of color families and scales, and the dttb mascot.

    Tokens Generator

    What: Creates tokens with the naming system built in, across three levels: option, alias / semantic, and component-specific.

    Why I should care: Creating tokens by hand takes a lot of time, and naming them is hard.

    Impact: My team and I create tokens faster, with full control of the naming system.

    Open the Tokens Generator
  • A Variables to JSON promo card: JSON is now formatted for Style Dictionary Configurator, converting variables to a single file or multi-theme JSON.

    Variables to JSON

    What: A Figma plugin that turns Figma variables into JSON compatible with the Style Dictionary configurator.

    Why I should care: The plugins I tried kept exporting wrong values.

    Impact: The JSON converts to code, and the values work with no issue.

    Get the plugin Read the story behind the plugin
  • A Design System Theme Manager promo card: manage, preview and export themes in seconds, with a preview of the variables.json input and a themes list.

    Theme Manager

    What: A standalone tool that manages themes while converting JSON to CSS.

    Why I should care: Some teams don't use Figma variables.

    Impact: Theme management becomes a no-code experience, without Figma.

    Open Theme Manager

Multi-Theme Design System

Thank you

Thank you for taking the time to read this case study.

Case study 02

Product Design · Unified Booking Manager

How I designed one app that syncs Airbnb and Booking.com so hosts stop double-booking their units

Hosts in Saudi Arabia juggle bookings, guest messages, cleaning and finances across several platforms by hand. As the solo designer, I interviewed hosts running 2 to 9 units, mapped their journeys, and designed one app that syncs bookings and automates the routine work.

Role
Solo UX Designer
Timeline
1 month
Domain
Short-term rental management
The Booking Manager app on two phones side by side, the Home screen with today's arrivals and occupancy and the Calendar with bookings by platform, with a notification between them saying a double booking was prevented.

Context

A platform that brings bookings from Booking.com, Airbnb and local apps into one place, so hosts can run several rental units without the manual work.

  1. Hosts

    Own or manage two or more units, often as a side business next to a full-time job.

  2. Many platforms

    The same unit is listed on Airbnb, Booking.com and local apps at once.

  3. Guests

    Come from inside and outside Saudi Arabia, with different languages and payment methods.

  4. The app

    One place to sync bookings, message guests, coordinate cleaning and track money.

Section 01

The problem

Managing rental units across several platforms is slow, manual and error-prone.

Availability by hand
Hosts block dates on every platform themselves after each booking.
Guest communication
Check-in details, reminders and review requests are sent one message at a time.
Operations
Checkouts, cleaning and restocking are coordinated by phone and chat.
Money
Income, expenses, deposits and refunds are tracked manually across platforms.

Section 02

Why does this matter?

Double bookings
A missed calendar update means two guests for one unit, and a cancelled stay.
Slow replies
Guests wait for instructions, and reviews suffer.
Missed checkouts
Late checkouts break the cleaning schedule and the next guest's arrival.
Lost money
Untracked deposits, refunds and expenses cut into the host's profit.

Section 03

Discovery

  1. User interviews
  2. What we asked
  3. As-is journey

03 · Discovery

User interviews

Research Method
  • One-to-one user interviews.
  • 50 minutes to 1.5 hours each.
  • Questions in English and Arabic, across five themes.
Interview Goals
  • Understand how hosts run bookings, guest messages, check-in and checkout, and money across platforms.
  • Find where it costs them time.
Sample size
  • Location: Saudi Arabia.
  • Criteria: at least two units, listed on more than one platform, with guests from inside and outside Saudi Arabia.
  • Number: 3 hosts, with 2–9 units each.
hosts interviewed
3
units each
2 to 9
per interview
50min to 1.5h

03 · Discovery

What we asked

Questions in English and Arabic, grouped into five themes.

Booking management
How hosts handle bookings and conflicting reservations across platforms.
Payments
Limits for guests from outside Saudi Arabia, and payment problems.
Instructions and check-in
What hosts share with guests, and how much effort it takes.
Checkout
Late checkouts, damage, and same-day checkout and check-in.
Ratings and reviews
Challenges with rating guests and getting reviews.
Wish list
What an app for managing all their units should do.

03 · Discovery

As-is journey

Following one stay from booking to deposit refund, the host does almost every step by hand.

Most painful steps
Blocking dates on other platforms, sending unit details and payment info, checking stock, and refunding deposits.
Repeated messages
Check-in instructions, passkeys, Wi-Fi details and review requests are retyped for every guest.

Section 04

Define

  1. Persona
  2. Pain points
  3. How might we…

04 · Define

Persona: Ahmed

“Property Management Pro”, 38, in Jeddah: manages five rental units as a side business next to a demanding full-time job.

Goal
A great guest experience with as little manual work as possible.
Needs
Reliable tracking of bookings, payments and availability, easy coordination of cleaning and restocking, and automated reports.

04 · Define

Pain points

What hosts told us takes the most time and causes the most mistakes.

Booking conflicts
No real-time sync between platforms.
Guest messages everywhere
Time-consuming communication across several apps.
Manual check-in and checkout
Delays and extra effort at every stay.
Late checkouts
Disrupt cleaning and need extra fees.
Stock and damage
Manual tracking, refilling, reporting and guest follow-ups.
Money and repetitive tasks
Refunds, income and expense reports, payment reminders and reviews done by hand.

04 · Define

How might we…

  • HMW

    Keep every platform's calendar in sync, so a unit is never booked twice?

  • HMW

    Send guests the right message at the right time without the host typing it?

  • HMW

    Turn checkout, cleaning and restocking into one smooth routine?

  • HMW

    Show a host their income, expenses and unit performance without a spreadsheet?

Section 05

Final solution

  1. To-be journey
  2. Features
  3. Information architecture
  4. Every screen at a glance
  5. Prototype
  6. Key flows

05 · Final solution

To-be journey

The same stay, with the app doing the routine work. Steps marked “Auto” happen without the host.

Automated
Blocking dates on other platforms, sending unit details, checkout reminders, cleaning assignments, restocking alerts, review requests and deposit refunds.
Host stays in control
Checking the unit and handling damage stay with the host, supported by templates and photo reports.

05 · Final solution

Features

Features in three groups, from connecting the platforms hosts already use to automating the messages they used to type.

What hosts valued most
Stars and thumbs on each card show the features the hosts we interviewed valued most.

05 · Final solution

Information architecture

Five tab-bar sections, with everyday actions one tap away and urgent work reachable straight from notifications.

Running the day
Home, Calendar and Inbox: today’s arrivals, every booking across platforms, and all guest messages in one place.
Running the business
Tasks and Insights: turnovers, restocking and damage reports as quick sheets, and income and occupancy per unit.

05 · Final solution

Every screen at a glance

05 · Final solution

Prototype

Start on the lock screen and tap a notification, or explore the tabs: approve a request, handle a late checkout, restock supplies.

Notifications first
Hosts mostly react to what happens, so every alert opens straight into the screen or sheet that resolves it.
Sample data
Guests, units and numbers are made up; unit photos are illustrations.
Open the prototype

05 · Final solution

Key flows

Section 06

Next steps

This project covered research and definition. The planned next steps:

  1. Prototype the core flows

    Starting with the most valued features

    • Booking sync across platforms
    • Automated guest messages
    • Checkout and cleaning routine

  2. Test with hosts

    Back to the hosts we interviewed

    • Moderated usability tests on the prototype
    • Check the wording in Arabic and English

  3. Measure what matters

    Compare against today's manual process

    • Double bookings
    • Messages typed by hand
    • Late or missed checkouts

Unified Booking Manager

Thank you

Thank you for taking the time to read this case study.

Case study 03

Enterprise UX · Gas Nomination Platform

Confidential · please don’t share publicly

How I led the move from heavy Excel sheets to a gas nomination platform that saves planners about 68 hours every cycle

An Oil & Gas company in Malaysia planned gas supply from 50 suppliers in heavy Excel files, copying every input by hand and re-planning for up to a day after each disruption. I led the design team that joined two months late, found that nobody really knew the users, and turned interviews, journeys and a discovery workshop into an MVP that users rated 4.5 out of 5.

Role
Design Lead
Timeline
Sep 2023 – Jul 2024 (11 months)
Domain
Enterprise operations, Oil & Gas
An operations control room with a wall of monitoring screens and operators at their desks.

Context

A web platform that helps gas network planners collect forecasts from about 50 suppliers and demand centres, validate them, plan facility activities and run supply simulations, replacing a set of heavy, manual Excel files.

  1. NI Requester

    Asks suppliers and demand centres for forecast data and chases missing inputs.

  2. NI Validator

    Checks the submitted data, compares it with past forecasts and approves it.

  3. Control-centre team (PBOCC)

    Monitors live operations and advises on activities that affect the plan.

  4. Three planning horizons

    Every plan is prepared for the next 30 days, the next 90 days and the next 1+1 years.

Section 01

Problem

The current planning process relies on manual, fragmented Excel workflows, making supplier data time-consuming to process, difficult to track, and inefficient to review at scale.

  1. The current system
  2. Pain points
  3. Why does this matter?

01 · Problem

The current system

Excel sheets full of numbers: hard to read, slow to load and filled in by hand.

Manual input
Planners copy and paste every supplier input to organise it in a template, then type the same activities again into the model: about an hour per supplier.
No overview
Nothing shows what changed or what still needs attention, so checking a cycle by hand takes about 6 hours.

01 · Problem

Pain points

What planners told us in the interviews.

No time for analysis
Most of the day goes into copying and pasting user inputs, then entering the same activities again in the model.
Manual requests and follow-ups
Each request is a 10-minute email per supplier, then planners chase the missing ones one by one: about 4 hours for every round of follow-ups.
No room for the 90-day plan
The model has no space for activities that belong to the 90-day horizon.
Slow, heavy files
The Excel file takes a long time to load because it is so large.

01 · Problem

Why does this matter?

Disruptions need fast re-planning
When a facility trips or a supplier changes its forecast, the whole nomination has to be redone, and today that takes 12 to 24 hours.
Every delay costs revenue
Slow re-nomination means missed cargo opportunities and lost income.
Contracts depend on it
Late or wrong nominations put agreed supply commitments to customers at risk.
People depend on each other
Planners, validators and the control centre all wait on the same spreadsheet.

Section 02

Challenges

  1. Joining two months late
  2. Nobody knew the users
  3. How might we…

02 · Challenges

Joining two months late

The design team joined the project two months after it started. The business already expected visible designs, so there was no time for full research first.

recorded meetings and workshops (17h 40m) watched
9
user stories read in the backlog
48
grey areas still open afterwards
9

02 · Challenges

Nobody knew the users

I asked for user interviews. The business suggested talking to the team first, but they knew how the current system worked, not who used it. So I brought 50+ team members together to put every open question on one board.

open questions about the users
32
answered with “we believe” or “no idea”
30
with a clear answer
2

02 · Challenges

How might we…

  • HMW

    Understand real users when the team building the product doesn't know them?

  • HMW

    Get business, users and developers to agree on one version of the requirements?

  • HMW

    Get every supplier's data in on time without chasing them one by one?

  • HMW

    Let suppliers submit their data once, so planners never retype it?

  • HMW

    Spot wrong or changed data without checking every number by hand?

  • HMW

    Turn dense Excel sheets into steps a planner can follow during a disruption?

Section 03

Discovery

  1. Research and design in parallel
  2. User interviews
  3. Personas
  4. As-is journey
  5. To-be journey
  6. Information architecture
  7. Design discovery workshop
  8. Requirements

03 · Discovery

Research and design in parallel

The business agreed to user research. To save time, we designed first drafts while the interviews were running, then reviewed them with users.

Research track
User interviews, personas, task priority, user journeys and information architecture.
Design track
Wireframes for one task, reviewed with the team and validated with users, then updated.

03 · Discovery

User interviews

Research Method
  • Online user interviews.
  • Over two weeks.
  • Run alongside the first wireframe drafts, which were then reviewed with users.
Interview Goals
  • Understand how each user group handles gas nomination today.
  • Find what slows them down.
Sample size
  • Segments: NI Requesters, NI Validators and control-centre users.
  • Number: 8 interviews (3, 3 and 2).
NI Requesters
3
NI Validators
3
Control-centre users
2

03 · Discovery

Personas

Two personas came out of the interviews, each with needs, pain points, observations and opportunities.

NI Planner
Wants time for analysis instead of copy and paste, but likes the flexibility of Excel. Would value seeing differences from past forecasts and automatic reminders to suppliers.
Control-centre user
Keeps operations running and gas quality at the right level. Isn't involved in simulations today, and wants to see what's happening so they can advise the planner in time.

03 · Discovery

As-is journey

One planning cycle today, run on Excel, email and WhatsApp: the planner requests, chases, re-types and checks everything by hand.

Most painful steps
Chasing missing submissions, copying every input into a template, and typing the same values again into the model.
Issues surface late
The control centre only sees the plan at the mid-month meeting, and re-planning after a disruption takes 12 to 24 hours.

03 · Discovery

To-be journey

The same cycle with the platform: one request reaches every supplier, inputs flow straight into planning, and the control centre follows along.

Biggest changes
Automatic reminders, validation against the last forecast, and no data entry: about 68 hours saved per cycle (estimate).
Everyone in the loop
The control centre sees the plan as it is built and can advise in time, with re-planning in under 5 hours (target).

03 · Discovery

Information architecture

One map for the whole product, so every later feature had a place to go. Stars mark what shipped in the first release (MVP1).

03 · Discovery

Design discovery workshop

I brought everyone into one room: users, business, project owners, business analysts, developers, solution architects, testers and designers. We reviewed the findings together and agreed on goals, personas, pain points, journeys and the information architecture.

Team alignment
For the first time, everyone shared the same picture of the users.
Found the gaps
Compared business requirements with what users actually need.
Scoped MVP1
Agreed what we could build first.

03 · Discovery

Requirements

Most business requirements didn’t match what users actually need. In the workshop, we replanned the releases around the user research.

wrong requirements
33
correct requirements
23
missing requirements
67

To fit the timeline, we kept 15 for MVP1, moved 64 to MVP2 and 11 to the backlog.

Section 04

Final solution

  1. Collecting forecast data
  2. Planning and simulation

04 · Final solution

Collecting forecast data

The 30-day request adds conversion values, a due date and remarks in one form.

04 · Final solution

Planning and simulation

Planners set facility and operations limits in editable tables instead of separate sheets.

Section 05

Validation

At the end of each sprint we tested the designs with real users.

  1. Planner usability test

    November 2023 · forecast data and facilities planning pages

    82% task completion · 4.5 / 5 ease

    • Five of the six planners, nine real tasks
    • Failures in 4 of 9 tasks, mostly setting limits
    • What we changed: auto-save and inline table editing

  2. Control-centre site visit

    January 2024 · watching the control centre at work

    • Learned how they monitor live data and run simulations
    • Mapped their current tools and pain points
    • What we changed: updated the control-centre personas

  3. Control-centre usability test

    July 2024 · control-centre modules

    80% task completion · 4.5 / 5 ease

    • Four users. We stopped when every session showed the same issues
    • All four failed one task because it used the planners’ terms (open/close, min/max)
    • What we changed: clearer labels, descriptions and keyboard navigation

05 · Validation

Usability reports

Pages from the planner and control-centre test reports: results, findings and next steps.

  • Completion and ease of use for each of the nine planner tasks.

  • 82% average task completion, rated Good, and 4.5 out of 5 for ease of use.

  • Issues found on the forecast data screen, with a recommendation for each.

  • Issues found on the facilities and operations planning page.

  • What we agreed with the team and users, such as auto-save and inline editing.

  • Completion and ease of use for each of the five control-centre tasks.

  • 80% task completion, rated Moderate, and 4.5 out of 5 for ease of use.

  • Issues found on the facilities and gas planning page.

  • What we agreed with the team after the control-centre test.

Section 06

Impact

About 68 hours (99%) saved per planning cycle

Estimates for one cycle with 50 suppliers

Estimated time per planning cycle, before and after the platform
TaskBeforeAfterSaved
Request data8 h 20 min10 min × 50 suppliers30 seconds~8 h 20 min99.9% less
Follow-ups4 hours30 seconds~4 hours99.8% less
Data entry50 hours1 hour × 50 suppliers0 minutes50 hours100% less
Validation6 hoursAutomaticdifferences highlighted~6 hoursup to 100% less
Re-planning after a disruption12–24 hoursUnder 5 hourstarget—

Usability results

Both user groups completed most tasks and rated the platform easy to use

Before any of this was built, the discovery workshop had already caught 33 wrong and 67 missing requirements.

Usability test results
Users testedTask completionEase of use
Planners82%4.5 / 5
Control centre80%4.5 / 5

Gas Nomination Platform

Thank you

Thank you for taking the time to read this case study.