Building a content design process at United Airlines
Problem:
No person or team owned UX content at United Airlines, leading to inconsistent usability and brand voice in different sections of the site. In addition, no one owned digital content at United, and therefore voice, tone and usability varied in quality and consistency from product to product throughout the experience, as shown in two current examples of “1.0” and “3.0” pages. These two problems drove high levels of support requests.
1.0 Site Map — many of these pages use entirely different design systems and were written by product owners and developers without oversight. Some pages are defunct.
3.0 Farelock, which was built using the United Atmos design system.
While this design debt was in part a holdover from United’s merger with Continental Airlines in 2013, the fundamental issue in these wildly varying experiences rooted from a lack of central ownership of each product team’s UI content. All application pages on United.com — that is, not static, informational or marketing pages — were written by product teams themselves. No one person knew what content lived where. More importantly, no content usage standards emerged consistently throughout the experience. In one product team, a “back” button might not save any entered data. In another team’s usage, a “back” button would save data until the user exited the flow entirely. In addition, content was typically only considered after comps had already been created — writers were not included in the design process. This led to misunderstandings that often pushed timelines for short pieces of copy into multiple weeks of effort.
My role:
As United’s sole UX writer, I came to the design organization with the goal of creating a process by which, over time, UX content creation and standards would be centralized and made consistent throughout the experience as the company migrated pages from 1.0 to 3.0.
What I did:
I interviewed business analysts, designers, and product owners, as well as our marketing editorial team, to understand how and when actual content requests are made. I found that copy requests took at least one week, and often up to six.
Agile product teams at United work with a number of tools, most prominently Atlassian Jira. However, content requests were made almost exclusively over emails to a list of editors, who would reply individually that they could tackle the work. Sometimes teams had individual editors they preferred to work with. This work was not shared broadly in any style guide or within the editorial team, and editors were often not made aware of results of testing.
I integrated with product teams early, attending sprint planning meetings across all 13 product teams (not all at the same time) in order to understand business priorities and upcoming content design needs.
While I built a sense of our broader roadmap to moving pages to 3.0, I built working relationships with individual designers on current projects, starting with pair writing sessions and critiques.
Instead of asking product teams to continue to rely on emails and Teams messages to individual editors, I set up a Jira intake workflow that allowed me to take in trackable content requests from product managers and designers. This workflow required filers to include necessary context: Sketch files, audience goals, business goals, sprint cycle and priority, existing research and testing, etc.
What happened:
Through my product team integration, broader roadmap awareness and updated content request intake, I managed to reduce the time it took to handle most UI content requests from one week or more to a few days. These were handled often through pair writing sessions with UX designers, where we used content design principles to consider terminology, usage, brand voice, and current standards for both United style and accessibility to ensure our 3.0 work. Usability of our content improved vastly as shown in usability testing, with complex concepts like reshop for irregular operations (changing a flight when your existing one is canceled) becoming much more comprehensible to average users.
1.0 sign-in modal. Heavy on unnecessary words, inconsistent tone (“if you wish”) from United’s standard confidence.
3.0 sign-in modal. Streamlined copy, more focused CTA, accessible hyperlinks.
Most importantly, I was able to build an overview of how we use language throughout United’s design org, and had begun to incorporate standards developed across multiple teams into our upcoming design system, Atmos.
Learnings:
While, at the end of 8 months at United, I had on my own managed to implement a UX writing workflow across our 300+ person design org, there’s much work to be done to implement changes across tens of thousands of pages on united.com. I learned primarily that it’s critical to build relationships early — without the support of UX designers who had their workload reduced by implementing content design principles, product owners and analysts would have been less willing to let me in the door to their sprint cycles as the “editorial guy.” Much of my work was based on showing that content design was as important as more traditional UX design, and would make their product better.