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.

Product Designer turning complex enterprise workflows into simple, AI-powered products.

10+ years in enterprise and SaaS. Today I design AI workflow automation at Nintex, using design systems and AI to turn ideas into working prototypes.

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

Portfolio

Case studies

The Create connection modal with a grouped connector list, showing Unified and Workflow connectors with surface chips.

How I redesigned connector search so people can find the connector they need without knowing where it lives

Role:
Senior Product Designer
Timeline:
Sep 2026
Domain:
Enterprise integrations, workflow automation
View case study
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 theme setup from days to hours

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

Case study 01

Enterprise UX · Integrations

Confidential · please don’t share publicly

How I redesigned connector search so no user is ever blocked from finding the connector they need

Enterprise teams need connections to use their tools, and every connection starts with picking a connector. While connectors move to one unified hub, they sit in three separate lists, and people get lost. I designed one search that covers them all.

Role
Senior Product Designer
Timeline
Sep 2026
Domain
Enterprise integrations, workflow automation
The Create connection modal with the connector list open, grouped into Unified and Workflow connectors, each with a surface chip.

What is a connection?

This is how enterprise companies use connectors to automate their processes and workflows.
Each step runs through a connection to the tool it works with.

User registersTriggerGoogle SheetsAdd userConnectionGoogle MailWelcome emailConnectionMicrosoft TeamsAlert #signupsConnectionDone

Today, a connection stays in one product

A connection made under Workflow can’t be used in Apps. Integration Hub fixes that by unifying connectors: connect once, use everywhere.

The migration takes time, so connectors move over one by one.

TODAY: LEGACY CONNECTORSWorkflowConnectionOnly inWorkflowAppsConnectionOnly inAppsOther productConnectionOnly inOther productsA connection can’t be shared across productsUNIFYINTEGRATION HUB: UNIFIED CONNECTORSUnifiedconnectorConnectionWorkflowAppsOther productsOne connection works in every product

Until then, connectors live in three places

Until every connector is unified, connectors live in three surfaces: Workflow, Apps and Unified. The Create connection menu asks people to pick one before they can search, and picking the right one is left to them.

CONNECTORS LIVE IN THREE SURFACESWorkflowLegacy listJiraSalesforceAppsLegacy listSalesforceAmazon DynamoDBUnifiedWorks in every productSlack
Today’s Create connection menu

Section 01 • The problem

Three connector lists, zero awareness of each other. Searching the wrong list shows “No connector found”. Maybe it doesn’t exist. Maybe it lives in another list. People get blocked: no answer, no next step.

UnifiedNot available

WorkflowAvailable

AppsNot available

Section 02 • How we discovered the problem

We started from the live product, not from opinions: audit every list, then test real connectors in each one.

02 · Discovery

What users told us

105 tickets in the last 3 months mentioned missing connectors or asked for new ones.

  • 24 tickets

    Discoverability

    “I know the connector exists, but where is it?”

    • “Why am I seeing two Salesforce connectors? What’s the difference between them, and which one should I use?”
    • “I’m trying to connect Slack to my workflow, but I can’t find a Slack connector. Is it available?”
    • “I know the platform supports SharePoint integration, but where can I find its connector?”
  • 21 tickets

    Availability & capability

    “Is this connector supported?”

    • “Can I integrate our workflow with SAP, or do I need to request a new connector?”
    • “Does the platform support Oracle integration out of the box, or do I need to submit a request?”
    • “Can I connect to Snowflake from my workflow, or is that connector not available yet?”
  • 60 tickets

    Custom integration request

    “Sales asked us to build a connector.”

    • “A customer is asking for a Dataverse connector. Is it on the roadmap?”
    • “A prospect needs a Microsoft Graph connector to move forward. Can we build it?”

    Most requested on the customer ideas board

    • Oracle20
    • Dataverse13
    • Snowflake12

Two goals: never block people from creating a connection, and grow the connector list faster.

02 · Discovery

I picked five connectors to cover every case

UnifiedWorkflow legacyApps legacyNo listSlack1 listJira1 listSalesforce2 listsSalesforce2 listsAmazon DynamoDB1 listHubSpotno listDoesn’t exist anywhere

02 · Discovery

What happened when I searched each one

UnifiedWorkflow legacyApps legacyThe gap
JiraNot availableAvailableNot availableExists, but only in Workflow
SlackAvailableVia UnifiedVia UnifiedAlready unified, works everywhere
SalesforceNot availableAvailableAvailableExists in two lists, not unified
Amazon DynamoDBNot availableNot availableAvailableExists in one list only
HubSpotNot availableNot availableNot availableDoesn’t exist anywhere

Via Unified: not its own entry, but it works there because Unified covers it.

How might we make sure a missing or hard-to-find connector never stops someone from creating a connection?

Section 03 • Exploration

One question, two answers, both tested against the same five connectors.

  1. Option 1: Guide inside the drawer
  2. Option 2: Pick a list first
  3. Trade-offs

03 · Exploration · Option 1

Option 1: Guide people inside the drawer

  • Keeps today’s flow: a menu, then one drawer per list.
  • A short alert above the search says where else to look.
View prototype (opens in a new tab)

1. Pick a list

2. An alert before the search

3. Searching a missing connector

03 · Exploration · Option 2

Option 2: Pick a list first, then search

  • Keeps today’s flow: a menu, then one drawer per list.
  • Explains each dead end, and says where the connector lives.
View prototype (opens in a new tab)

1. Pick a list

2. Search that list

3. A dead end explains itself

03 · Exploration · Option 2

Option 2 across the five connectors

Every dead end is explained, but each is a different message, and the user still chose a list first.

View prototype (opens in a new tab)

Jira. Exists in Workflow only. The drawer says so and offers a request.

03 · Exploration · Trade-offs

What the two options left open

Option 1: Alert in the drawerOption 2: Pick a list first
Users never get lost
Hint onlyThe hint comes after choosing a list
After a dead endExplained only after an empty search
Can request a new connector
No requestThe alert only points elsewhere
Can requestThe dead-end message links to a request
Knows the next step when it’s missing
GenericOne alert, whatever was searched
SpecificEach dead end says where it lives
Effort for developers
LowOne alert per drawer
LowReuses today’s pickers
Fewer steps in general
Three stepsMenu, drawer, then search
Three stepsMenu, drawer, then search

Section 04 • Final solution

One search, every connector. The list becomes a label, not a gate, and there is always a way forward.

04 · Final solution

Search every connector in one place

No choice up front
Create connection opens straight onto the search.
Always see where it lives
Grouped by list, with a chip on every row.
Nothing hidden
A connector in two lists shows under both.
Never blocked
Not listed? Build a custom connector with AI and keep going.
Always a way to ask
Want us to add it? Request it and get told when it’s ready.

04 · Final solution

One search across the five connectors

Same five connectors, one search, one answer shape.

View prototype (opens in a new tab)

Jira. Found, with a Workflow chip.

04 · Final solution · Never blocked

Nothing matches? Build it or request it

1. Two ways forward. Build a custom connector, or request it and get told when it’s ready.

2. Build it yourself. Describe it to AI, import a spec file, or paste a spec URL.

Section 05 • Validation

A two-week A/B test with 935 users. Drop-off at the connector step fell from 27% to 11%, and 66% of users who hit a missing connector stayed.

05 · Validation · Approach

Live A/B test: current design vs new design

Users were randomly shown the current design (A) or the new one (B) and kept it for the whole test. We measured what they did.

Measured
Completion, time to select, drop-off, recovery
Tool
Mixpanel
Split
50/50, random

Of 50% of all traffic

Duration
Two weeks
A · Current design

452

users

B · New design

483

users

05 · Validation · Events

Events tracked

The same eight events were tracked in both versions, so the funnels compare side by side.

  1. 01Flow started
  2. 02Connector list opened
  3. 03Search
  4. 04No connector found
  5. 05Request clicked
  6. 06Build with AI clicked
  7. 07Connector selected
  8. 08Connection created

05 · Validation · Results

New design (B) vs current design (A)

Median time to select a connector
22 secCurrent design (A): 48 sec54% faster
Drop-off at the connector step
11%Current design (A): 27%Down 16 points
Recovery from dead ends
66%Current design (A): 0%Up 66 points
Connection completion rate (end of flow)
71%Current design (A): 58%Up 13 points

Drop-off and completion: p < 0.001. Recovery is directional: 68 users hit a dead end in B.

05 · Validation · Selection

More users get through the connector step

Share of users who opened the flow · 452 in A, 483 in B

The step the redesign targeted

Selected connector

64%
A · Current design
74%
B · New design

+9% requested a connector or built one with AI. They are not counted as drop-off.

+10points

05 · Validation · Dead ends

When a connector is missing, most users stay

90 users found no connector
A · Current design100% · 90
0%recovered
68 users found no connector
B · New design34% · 23
25% · 17
41% · 28
  • Left the flow 23
  • Requested a connector 17
  • Built with AI 28
66%stayed in the product

45 of 68 who hit zero results stayed: 17 requested a connector, 28 built one with AI.

Directional: small sample, 90 users in A and 68 in B.

05 · Validation · Insight

Insight: the most wanted missing connectors

RankConnectorUsers searchingRequestsBuilt with AICompetitor coverage
1Snowflake17196 out of 875%
2monday.com14366 out of 875%
3Microsoft Graph5242 out of 825%
4Azure AD6132 out of 825%
5Service Now4422 out of 825%
6Oracle7211 out of 812%
7Dataverse3111 out of 812%
8Microsoft Planner8210 out of 80%
9Microsoft Teams Approvals4110 out of 80%
–Total681728

A directional signal for the roadmap. Competitor coverage: how many of the 8 competitors offer the connector.

Competitors: Cyclr, Make, OutSystems, Power Automate, Prismatic, ServiceNow, Zapier, n8n

Connector discovery

Thank you

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

Case study 02

Token Architecture · Multi-Theme Design System

How I designed a three-tier token architecture that scales to unlimited themes and cut theme setup from days to hours

A deep-dive into the token architecture I defined: three tiers, a shared naming system, and independent theme layers, so brands and modes never leak into each other. I built it and the Figma-to-code tooling together with developers. In a survey of 25 team members, most said design changes now need zero developer effort, and a new theme still needs developers but 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 in code in about an hour

Section 06 • Impact

Reported outcomes

From days to hours, as reported by 25 team members

Reported results of the multi-theme design system, from a survey of 25 team members
MetricBeforeAfterImprovement
Design decision change2 to 5 days0 developer effort(76% of respondents)—
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%

Source: before/after survey of 25 team members, self-reported estimates, not time-tracked. Figures show the most common answer in each survey; sprint hours are bucket midpoints.

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 03

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. 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

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.