GEM

Hilton’s Guest Engagement Manager (GEM) web application is a comprehensive system used across its Customer Support organization. Development is on-going, but in the first 24 months of development it had already replaced eight legacy enterprise applications.

Problem

The GEM development project was fast-moving with rapidly-shifting priorities based on which legacy system was to be decommissioned soonest and which API functions became available. There was little lead time during or before each sprint to do the design work before coding began, and even less to do user research and testing.

I joined the project about six months after coding started. Because GEM was to be built on the Salesforce platform using its Lightning Design System, there was no UI designer on the team. Two user experience architects (UXAs) had been doing UI design, as well as all other aspects of UX: user research and discovery, copywriting, content strategy, information architecture, user flows, interaction design, etc.

Because of the workload, they were doing little more than cranking out Sketch wireframes and mockups, which only went through cursory review before going to developers. The user experience in the monthly releases often varied widely from the mockups created by the UXAs. Developers used their own personal judgement or developed for expedience rather than usability. 

The result was a disjointed experience that was becoming worse as layers of one-off design were added on top of each other and would eventually lead to performance issues for agents.

Design Audit showing post-deployment variations from design specs
Design Audit showing post-deployment variations from design specs

Solution

A robust design system was needed along with a closely-synced code library. This would minimize the need for detailed design specifications as developers would pull library code components that already incorporated the design system.

Creating the design system and code library would be a challenge. The entire team was operating at (or above) capacity. There was no resource availability for additional work.

Design System

From the beginning of the project, the expectation was that design would follow the Salesforce design system. However, unique requirements and the unforgiving pace of the project led to more custom code than use of out-of-the-box Salesforce components, which would have alleviated some of the design issues.

The UXAs on the project had a shared Sketch library file, but it was not routinely synced with their own working files. With the constant stream of new feature requirements, the design was becoming inconsistent.

A thorough design audit was conducted to identify all elements and components that would need to be included in the design library. At the same time, other usability and design issues were identified to create a backlog of UX work.

Design system color tokens and layer styles
Design system color tokens and layer styles
Symbols page of the Sketch Library file
Symbols page of the Sketch Library file

Process

Once design elements were identified, empty placeholder components were created. Regular weekly meetings of a design library team, including product managers, dev leads and UXAs, would be held to identify components that would be needed for upcoming feature releases. The UXA could then create the design system element before it was needed, and there would be time for the developer to incorporate the design into the code. After a review by the design library team, the design and code would be officially added to the design system and code library.

 

Scroll to Top
Scroll to Top