Back to work

HILTONCASE STUDY2021–2025

Hilton Honors, from guest experiences to a shared mobile design system

From designing mobile experiences to leading the system behind them.

2021–2025 · Senior UI Designer (contract) → Lead UI Designer → Product Owner, Mobile Design System

I joined Hilton to design the mobile interfaces guests used before and during their stays, then led the multidisciplinary pod that turned recurring decisions into reusable foundations.

Chapter 01

Introduction

Role progression · Retrospective reconstruction

I joined Hilton to design the mobile interfaces guests used before and during their stays. Working across features exposed a recurring problem: teams were solving the same interface decisions independently. I helped turn those decisions into reusable foundations, then led the multidisciplinary pod that prioritized, built, and maintained them.

  • 01 / 2021–2022 · Contract

    Senior UI Designer

    Guest-facing interfaces · Honors, add-ons, Digital Key, TV

  • 02 / 2022 · Emerging system

    Lead UI Designer

    Reusable foundations · Figma guidance and feature support

  • 03 / Within 2022–2025 · Mobile system

    Product Owner

    Roadmap, backlog, prioritization · Multidisciplinary pod and releases

Chapter 02

Designing the experience

When I joined, Hilton’s UX and UI disciplines were separate. UX teams defined the experience. My role was to turn it into polished, high-fidelity interfaces and prototypes. I worked on the Hilton Honors mobile homepage redesign, stay add-ons, and Digital Key, and supported the Hilton TV experience.

Digital Key · Retrospective reconstruction

Reconstructed Hilton Digital Key screen showing Room 328 with a green indicator labeled “Unlocking.”
Guests use Digital Key to unlock their room door. The “Unlocking” state shows that the app is working on the request. I prototyped the Digital Key sound that reached production.

Digital Key called for feedback beyond the screen. I prototyped the sound for the experience, and that sound reached production. The work taught me to consider what guests could hear as well as what they could see when using an interface.

Chapter 03

Recognizing the problem

Across features, I saw teams solve similar interaction problems in different ways. Hilton had no established shared mobile design system at the time. Each new feature brought another opportunity to reconsider controls, states, and handoff details that could have been shared.

I began teaching atomic design and reusable component methods to my immediate team. Those conversations grew into workshops with the wider design organization and discussions with engineering. The feature work gave us concrete examples to discuss together.

Retrospective reconstructionWhat teams compose and what the system supplies
Feature teams compose the guest experience. Shared foundations supply content structure, action hierarchy, and accessibility rules.

Chapter 04

Establishing shared foundations

As Lead UI Designer, I became the primary point of contact for the emerging mobile design system. I established reusable foundations, documented components and patterns in Figma, and helped feature teams apply them.

The Honors homepage redesign was an early proving ground for introducing the system into product work. I worked with UX, UI, content, accessibility, iOS, and Android specialists. Directors across UX, UI, iOS, Android, and Mobile Engineering supported formalizing the system and exploring its potential beyond mobile.

A recurring decision was where to draw the boundary: which behaviors should the system define, and which combinations should feature teams own?

Original iOS Sandbox crop · Shared hotel resultEditorial crop of the iOS Sandbox Card / Wide instance. Hotel Details and View Rooms are verified on this platform crop. Tabs and chrome outside the card are excluded.
iOS Sandbox Conrad Las Vegas card with photo, title, nightly rate, and Hotel Details / View Rooms actions.
01 · Content
Hotel name, nightly rate, and refundable label.
02 · Actions
Hotel Details and View Rooms appear in the original iOS crop.
03 · Accessibility
The guideline specifies that the title is announced first.
Original Figma guideline · Standard and compact cardsM3 Figma Card guideline overview. Standard examples sit above; compact examples sit below.
M3 Figma Card guideline overview comparing standard and compact examples on iOS and Android.

Original iOS Sandbox crop. The card gives the hotel name, rate, and next actions a shared structure. The Card guideline also specifies that screen readers should announce the title first.

Button Group · Editorial reconstructionBoth platforms keep the same action emphasis. The documented three-action treatment spans the container on iOS and centers a compact stack on Android.

iOS · Full-width stack

Android · Compact stack

View the original Button Group matrix
Button Group matrix · Source evidenceOriginal Button Group guideline showing two horizontal actions and three vertical actions on both platforms. [Button] is a template label.
Original iOS and Android Button Group examples with two and three actions. [Button] is a guideline placeholder.
iOS · Source evidence
iOS Button Group examples with two and three actions. [Button] is a guideline placeholder.
Android · Source evidence
Android Button Group examples with two and three actions. [Button] is a guideline placeholder.

Historical guideline with template labels. [Button] is a historical placeholder.

View populated Button Group, AlertMessage, and DatePicker specimens

SearchBarButton

iOS Sandbox · Source evidenceCropped iOS Sandbox header showing SearchBarButton in context. A verified Android frame in the same state was not found.
Las Vegas search entry beside a back arrow at the top of the iOS Sandbox screen.

iOS Sandbox only. A verified Android frame in the same filled state was not found.

View the search control close-up
Source evidenceSearchBarButton close-up.
Search bar button displaying Las Vegas, NV.

AlertMessage

Simplified reconstruction · Severity statesRealistic severity copy and the Show More action. Source specimens keep the [Description] placeholder.

Warning

The room rate may change before booking.

Show More

Information

Check-in begins at 3 p.m.

Show More
View the original alert specimens
Library specimen · WarningLibrary specimen · Warning. [Description] is a placeholder. Show More is the documented action.
Yellow warning AlertMessage library specimen with an alert icon, [Description] placeholder, and Show More action.
Library specimen · InformationalLibrary specimen · Informational. [Description] is a placeholder. Show More is the documented action.
Blue informational AlertMessage library specimen with an information icon, [Description] placeholder, and Show More action.

DatePicker

Simplified reconstruction · Selected rangeJune 2025 stay with a selected range summary. Omits nightly price labels and other source details. One sourced platform treatment.

June 2025

Jun 8–11, 2025 · 3 nightsApply dates
View the original calendar and range specimens
Calendar grid · Source evidenceCalendar grid. Sample values from one sourced platform treatment.
DatePicker calendar grid with sample nightly prices under each date.
Selected range · Source evidenceSelected range. Sample values from one sourced platform treatment.
DatePicker selected range with highlighted dates and a summary action area.

Later parity work also covered ChipRow and related selection patterns. Atomic design was a teaching model for building modular components with defined behavior.

Chapter 05

Recognizing the bottleneck

As more teams came to me for guidance, too many decisions depended on my availability. The same arrangement that helped us start the system was becoming a bottleneck. A decision about a shared control could require input on design, content, accessibility, and implementation, yet teams still depended on one person to bring those perspectives together.

That changed what I needed to build. We needed a dedicated team with a shared way to evaluate requests and the authority to make decisions together.

Retrospective reconstructionFrom one point of contact to shared decisions
Initially requests converged on one design lead. In the pod, product ownership coordinated decisions reviewed by design, content, accessibility, iOS, and Android.

Chapter 06

Building the Design System Pod

As Product Owner and lead of the Mobile Design System Pod, I coordinated the roadmap, owned prioritization and the backlog, and brought cross-team decisions to the people who could evaluate them. The pod included a UX Design Consultant, UI Designer, UI Advocate, UX Content Expert, Accessibility Expert, iOS and Android developers, and a Scrum Master. A Director of Android Engineering advised me on product ownership and management.

Feature teams had public channels for requests and support. We triaged requests internally, reviewed them weekly, tracked the backlog in Jira, and coordinated capacity through PI planning and proactive conversations with other product managers. The pod evaluated requests across disciplines. Engineers used peer-reviewed pull and merge requests, and we shared changes through Zeroheight guidance, changelogs, and weekly release announcements. Sprint retrospectives helped us adjust the process as the work evolved.

Retrospective reconstructionInside the Mobile Design System Pod
Product Owner coordinates the roadmap and backlog. UX, UI, advocacy, content, and accessibility review the design. iOS and Android build it. A Scrum Master supports delivery and an Android Engineering director advises.

Request to release · Retrospective reconstruction

  1. 01

    Intake

    Feature teams use request and support channels.

  2. 02

    Triage

    The pod reviews requests weekly.

  3. 03

    Prioritize

    Jira backlog, PI planning, and product coordination.

  4. 04

    Evaluate

    Design, content, accessibility, iOS, and Android weigh in.

  5. 05

    Build & review

    Engineers build and peer-review pull and merge requests.

  6. 06

    Document & release

    Zeroheight, changelogs, and weekly announcements.

Retrospective reconstruction of the pod’s request-to-release workflow. Sprint retrospectives fed changes back into the process.

View the original Decision Log template
Original template · sample entryDecision Log template. The 2024.05.28 entry is sample template content, not a verified completed decision.
Decision Log template with a sample dated entry and instructional placeholder copy.

Original Decision Log template. The dated entry is sample template content, not a verified completed decision.

Chapter 07

Outcomes

The pod delivered mobile design foundations, shared iOS and Android repositories, reusable components, guidelines, and contribution tooling.

By the end of my tenure, I estimate that reusable components supported approximately 90% of existing mobile application workflows. This was an estimate of workflow coverage. We were beginning to establish formal component adoption measurement when organizational layoffs ended my tenure.

Engineering leadership reported an approximately 45% improvement in mobile feature delivery speed. The original measurement baseline is unavailable, so I present this as a leadership-reported result.

Chapter 08

Reflection

I started by designing the interface and became the person teams came to for system decisions. My most important lesson was learning to distribute that responsibility. A shared backlog, regular release cadence, and multidisciplinary review gave people the context and authority to make decisions together.

That experience changed how I lead. I still care about how an interface behaves and feels. I also pay attention to the relationships and routines that let a team keep making those decisions after any one designer leaves.