Enterprise UX Governance

TLDR: what happens when a multinational corporation maintains a catalogue of 150 digital products, all designed and maintained separately? Absolute UX mayhem. Cue my efforts on their new team intended to add some clarity and direction to their UX group of over 250 fine people.

Project

OneUX Design System (tentative name)

Client

ADP

Role

Lead UX Designer

Team

Design System (20), UX department (250+)

Environment

remote

Methodology

agile

Website

N/A (all work for internal business systems products)

Key Skills

Design system, Patterns, Documentation, Component library, Wireframing, Research, Sketch to Figma transition

Summary

Provide UX governance; consistency and clarity to the many product and design teams through a well-built and documented design system.

Overview

In mid 2021, someone at ADP either noticed (or was notified) that their deep catalogue of digital products and services were completely misaligned.

Different designs, UX patterns, components, navigational conventions, etc. plagued the lot.

Perhaps difficult to identify from within, but painfully obvious to any customers using multiple ADP products everyday.

So in late 2021, they inaugurated a special new Design System team with the mandate to audit and realign all company UX/UI efforts.

How I joined this project

Technically headhunted by their official third-party agency partner, I joined in early 2022 interested in taking on a truly massive, complex challenge.

While it didn’t directly satisfy one of my prime directives to help society or improve the world, positively impacting tens of millions around the world using ADPs products in their everyday lives is arguably a related pursuit.

Objectives

In a nutshell: standardise everything and package it for mass consumption.

This included a catalogue topping 150 digital products and a UX team of over 250 talented professionals.

To tackle this, we divided deliverables into several categories:

  • Foundations (aka global atoms, partial gallery shown below)
  • Component library – including code alignment
  • Patterns
  • Photos
  • Illustrations
  • Documentation

Publishing methods

As for the packaging end, we began by publishing an internal documentation website, though as we began authoring content, it quickly became obvious that maintaining everything in multiple areas and in multiple formats (Sketch, Figma, Miro, CMS-based web publisher) was not only inefficient, but an invitation to very quickly amass enormous volumes of UX debt.

Partnering with engineering, we then created a utility for Figma’s API that could, for the interim, scrape documentation from inside our design files and publish it, eliminating redundancies.

Long term, we planned to eschew the website altogether and harbour all documentation alongside the design content itself, inside the Figma library files published to the entire organisation, reserving any website presence for a public edition.

Process failures

In effort to avoid any bias or unpleasant impressions, I will limit these points purely to factual details without commentary and leaving any quality inferences to the reader.

  • A Director and several Lead level designers from our Design System team, all with a decade or more service to ADP, left the company within the first few weeks of my arrival.
    • VP inherited all of the subordinate Director’s duties for about six months.
    • A single VP stretched between dozens of “direct reports” left scarce time for anyone to discuss issues or progress.
  • HR, onboarding, payroll, etc functions fell to said VP rather than individuals’ managers, which prevented requisitioning hardware/ software licenses and introduced occasional payroll issues.
    • After nearly a year, I never did receive a computer or mobile licences, instead needing to configure my personal hardware and software to work with or around their VPN.
  • Full time employees enjoy a robust onboarding experience; contractors receive a link to someone’s Webex recording briefly describing a few of the company’s key digital products.

My contributions

Throughout a near-year with the team, my efforts were focused thus:

  1. Complete their enterprise “UI Shell” and navigational construct
    • building the components
    • aligning with code
    • documenting all functionality and usage
  2. Author patterns
    • identify
    • research
    • illustrate
    • write and publish documentation
  3. Assist with enterprise transition from Sketch to Figma

UI Shell

This may have been the most complex aspect of the entire design system as it touches literally every person and product.

Nothing like a trial by fire as my first endeavour! 🔥

Component building

An incomplete array of assets and concepts existed in a derelict Sketch file started by someone long, long ago in a galaxy far, far away…

While that original file’s contents cannot be shown here, I can share excerpts of the final output below.

Specifically, I needed to convert any relevant, existing assets to Figma or create whatever necessary to fill the gaps across the atomic food chain.

To do this, I spent nearly a month in discovery, tracking down technical details, usage patterns, interviewing users, engineers, designers, etc. to map the truly mind-boggling number of requirements and pieces of the overall puzzle.

Below, you can see some of the atoms and molecules included within the layout. Others were hidden outside the visible area and withheld from publishing directly to library subscribers.

In all, nearly a hundred components and sub-components were created for this single system feature. 🤯

Since this universal shell was a bit foreign to many teams, I also needed to create some templates and examples for designers, including defining the coded environments’ actual column grids and break points, along with variations appropriate for each.

Curiously, developers in their thoroughness created breakpoints for the mega menu even on mobile where it would not be ideal, and where no patterns or direction had yet been given. Because we initially aimed for 100% code alignment, I also included horizontal menu examples for mobile that could be eliminated and tracked in a later sprint. 🤷🏻‍♂️

Code alignment

When it came to code aligning the dozens of UI Shell/Global Navigation components I designed, attention to every pixel of detail would in theory benefit the UX designers and engineers downstream.

To achieve total alignment nirvana, I spent 2-3 months in our Storybook environment examining every aspect of the navigation components’ code/stylesheets, in browser code inspectors, and on Webex calls with the lead engineer.

I even included the rendering glitches and CSS quirks in the designed components. Yes, I am that thorough. 😎

CSS quirks from code intentionally recreated in component design. User pop-up menu. Left, desktop; right, mobile.

Inspecting the user pop-up menu (when clicking their avatar in the toolbar): left, the desktop version which appears immediately beneath the avatar; right, the mobile version is a modal sheet which slides up from the bottom of the screen and casts a focus overlay across the rest of the screen.

For the desktop version, the tiny arrow which normally points at the avatar above, in code was an 8px white square, rotated 45 degrees. So that’s exactly how it was built and named in my Figma component.

For the mobile version, the developed sheet still had a border-radius for the bottom corners, partially revealing the overlay. So again, for better or worse, this behaviour was replicated in the components, purely for alignment sake, which could then be tracked via a ticket during a future sprint.

Documentation (prototype)

While we did need to explain every nuance of this component in excruciating verbosity, to be honest, much of that was purely for posterity, as designers and developers prefer to be shown than told.

So as often as possible, diagrams and illustrations served show. Check out a prototype of the component documentation (external link to Figma):

Check out the prototype for a sense of the documentation style.

Patterns

Overall, the patterns pillar ran somewhat independent from the regular Agile sprints; aside from defining basic stages of progress, the timing of each was simply too nebulous. Each finished when it finished.

Discovery

The leading phases for defining/documenting each pattern involved two steps:

  • Seek out and compile examples of said patterns existing within current products
  • Conduct basic UX reference research via published literature (N/N Group, Baymard Institute, etc.)
  • Show comparisons and contrast with other enterprise design systems
Excerpt from the UI Shell/Global Navigation pattern

Authoring

A basic gallery of the collected examples alongside the research is published for each pattern in a central Miro board, and participants across multiple teams are invited to discuss.

Feedback was then processed and discussed internally by the Design System team and a preliminary policy drafted, including creating any necessary illustrations or diagrams.

On a side but related note, while working on a number of patterns, I matured the team’s existing diagram illustration style.

Publishing

The entirety was presented centrally once more to collect final feedback before formatting and officially publishing.

The CMS-based web publisher required old-school exporting of web-optimised images and a lengthy formatting process.

The site was only published once per sprint, meaning new articles or updates needed meticulous planning to hit those deadlines.

As mentioned earlier, building and maintaining multiple instances of the documentation proved grossly inefficient, so we began migrating all documentation to reside inside their respective pages within the Figma library documents.

This allowed immediate updates at any time and a single source of truth directly adjacent to the content being described (in addition to allowing live elements in prototype view). 👍

Examples from List Pages pattern

Many times, especially in data-rich corporate environments, software must display lists of various types.

To help the many product teams align on some standards, I identified a handful of core use cases, applied general UX research for best practices, and authored the pattern content.

While the above examples were in progress, simpler, low-fidelity versions helped instruct the engineers about how to build templates. Interestingly, they had no trouble translating the super simple style into existing components.

Figma ambassador

The organisation began a mass transition from Sketch to Figma just as I arrived.

Fortuitous, as without a company-issued computer, I could not access their software installer nor company Sketch licence. Figma, however limited me not.

As a power user, I volunteered for their transition ambassador program, where I spent time:

  • Fielding questions in a UX team chat (yes, the same hundreds of teammates)
  • Demonstrating best practices
  • Contributing to training and helpful resources
  • Attending weekly ambassador meetings
  • Attending personalised training directly from Figma’s design advocates
  • Expediting Design System (components) transition from Sketch

Findings and insights

In contrast with the earlier process failures, these most certainly do contain some personal biases from my own experiences.

  • Some highly visible product teams carried on as if immune to alignment efforts, in turn influencing other, smaller teams to also diverge from defined standards.
    • Perhaps some manner of certification accountable to leadership would persuade more teams to participate in the design system.
    • Some of these divergences were then submitted back to the Design System team as contributions, thinking they would simply overwrite established standards. This worsened inconsistencies and complicated alignment efforts.
  • Many of the design system efforts were targeted only towards desktop users and layouts, procrastinating mobile for “later”
    • My contributions always included a minimum of mobile, tablet, and desktop deliverables.
    • I discovered a number of undesirable results from developers implementing their best guess in the absence of design guidance.
    • I repeatedly advocated in our DS team roundtables for at least mobile standards in addition to desktop, to a fairly unreceptive audience from leadership and those with greatest seniority.
  • Some of the Leads on our team, overly eager to win acceptance and adoption from other teams, approved external submissions to the DS without research, discussion, or any kind of QA, resulting in conflicting, redundant, superfluous, or inappropriate features, polluting rather than purifying the system. Better communication/submission process would improve the design system plus inter- and intra-team politics.
  • Clearly some internal, political issues between management and team members caused an exodus of long time employees. Lesser human capital on the team deeply affected our efficacy.
  • Similarly, the organisation clearly favours full-time employees, relegating contractors to second-class citizens with virtually no onboarding, lack of integration with the regular employee teammates, zero resources or privileges to acquire essential hard/software, nor the ability to engage directly with leadership, leading to gross inefficiencies.

Additional design artefacts

A handful of the foundations, or global atoms.

Some of my documentation supporting Do/Don’t illustrations

Legacy Product Design

TLDR; some of my old, publicly released web/digital product work 🤷🏻‍♂️

Before we begin, realise most of the below projects precede the emergence of flat design trends, before responsive web design was standard practice, or even UX/UI as their own distinct fields.

Included here for context in my larger career and to illustrate some sense of design progression or contrast my natural aesthetic against the trends of yesteryear (skeuomorphism, anyone??).



Monkeypaw Games

Project: Branding and websites
Role: Creative Director, Designer, Front-end Developer
Team: <10
Environment: Remote
Key Skills: Photoshop, Illustrator, Brand Identity, Web design, HTML, CSS
Summary: Creating a teaser website for display during development of a full e-commerce site, plus establish corporate branding/identity.

Monkeypaw Games approached me first in need of a new website to promote its line of digital game releases on the Playstation Store, and as a company based in Japan, it marked my first international project*. A secondary objective to re-imagine the logo and branding lurked in the bushes, as their interim identity frankly looked the result of too casual a black Sharpie on napkin.

Die first, resurrect and live later

Monkeypaw needed something for visitors to land upon while their more robust site containing an online store and media engine underwent development.

A “tombstone” site back in the day described a single-page website, usually meant as a placeholder or simple informational block to satiate visitors with the basics. No links, tabs, menus or other frills; just the one page.

A surprising cottage industry sprouted in the late 00s supporting this trend, especially favouring new or small businesses wary of investing heavily in an online presence. Ironic for tombstones to represent so many new companies rather than “deceased” 🤷🏻‍♂️

Two discarded concepts. Too literal/grotesque (left) and too whimsical (right).

Curiously, their initial branding centred around a rather kitschy jungle motif instead of something slick and befitting a tech/gaming company. Anyway, a few rounds of sketches led us to the image below; a light-hearted illustration evoking tropical undergrowth and Incan ornamentation. …because monkeys?

Left: My quick sketch
Right: the fully illustrated final UI

Rebranding

I do remember learning from our calls that their starter logo really was hand-drawn…on an inappropriately disposable substrate no less. Disposable indeed.

Because of illegibility at small sizes and an unrefined appearance, the simians bookending “MonkeyPaw” had but a single redeeming quality: its one colour reproducibility. It otherwise absolutely misfired as the image of a fresh gaming upstart whose products all lived on digital storefronts.

Going back to the drawing board, something much more edgy–literally in your face–emerged.

Left: The actual logo, shown in the brand’s black and red colours.
Right: Alternate photo-textured motifs using the logo’s shapes as masks.

In addition to the standard black and red branding colours, the new logo allowed contrasting photographic textures masked within the shapes, as shown above right, or displaying the foot as a standalone graphic element.

Somewhere in my vast collection of sketchbooks lie a cornucopia of progress sketches, however their location remains a mystery…for now.

The accompanying word mark can be seen in my web examples below.

Reincarnated web experiences

Beyond the tombstone, we eventually released a full website. Primarily a destination for fans and customers to gather news or other information about the company’s products, for the first five years it existed as a non-responsive, “classic” website (see below), courtesy of other designers/agencies.

Early versions of the desktop only website. Note these sport an alternate logo and word mark, courtesy of another designer.

Only when 2015 came around did the site blossom into a fully responsive, multi-device offering. Shown below with my layouts, logo and word mark. Note the mobile (phone) version is intentionally truncated to display alongside its counterparts; some repetitive content not shown.

My responsive layouts, plus the logo and word mark. No disparagement intended to the previous designers, but these all display an obviously higher degree of professional TLC.

* Technically, I joined a project in the late 90s with a Canadian company, but do not consider it part of my professional canon 👍


Bardo Entertainment

Project: Website, pitch decks 
Role: Creative Director, Designer
Team: <10
Environment: On-site in San Francisco Bay Area, California
Key Skills: Photoshop, UX/UI, Web design, HTML, CSS
Summary: A small tech company website (Bardo) aimed at delivering community-focused portal and B2B partner program sites, primarily to the gaming industry.

Freshly transplanted in the San Francisco Bay Area during the late aughts, this marks one of my first freelance projects in the area, spearheaded by my contacts in the video game industry and online game developer Bardo Entertainment.

Bardo hired me to design and pitch a massive growth project for their online community and gamification platform. We also partnered with enterprise web software company, OneSite, who developed much of the back-end technology.

Despite IE6 chucking its notorious wrenches into cross-browser compatibility for years, we wanted to include a few “cutting edge” web techniques (for 2009), such as massive, floating and overlapping layers and translucent elements, mostly for projecting some pizazz and technical prowess, given the site’s otherwise simple presentation.

Web browsers generally didn’t support 24-bit PNG yet, forcing us to adopt 8-bit GIFs and PNGs with their inherent jaggies and dithering effects familiar to anyone who might have played SNES games back in the 90s.

The Bardo “phoenix” in the background helps funnel the viewer to the centre and then downwards through the content. This let us streamline and prioritise the information, giving users just what they need, nothing more or less.


Sega of America, SegaNerds

Project: Website, pitch decks 
Role: Creative Director, Designer
Team: <10
Environment: On-site in San Francisco Bay Area, California
Key Skills: Photoshop, UX/UI, Web design, HTML, CSS
Summary: A reinvention of Sega’s own community-facing presence while also building a network of third-party partner/affiliate sites under its umbrella.

A joint effort with Bardo Entertainment and Sega of America to improve their community outreach program both with their everyday users and also fans running their own sites, blogs, forums, etc.

We partnered with OneSite, a provider of enterprise-level front- and back-end solutions, especially for social media, which includes blog and forum features, but the platform’s biggest draw was its community gamification; giving users points for various activities, redeemable for exclusive gaming swag or digital goodies.

The plan included migrating Sega’s existing site, blogs and forums to OneSite’s platform, and then invite select fans to migrate their sites to sit alongside Sega’s official offering. Post launch, additional game studios and tiers of fan sites were scheduled for inclusion into the network, exercising common templates while also featuring each organisation’s unique branding, staff, and voices.

Shown above is an example pitch of “SegaNerds”, the world’s most popular unofficial Sega site, as it might look on the OneSite platform circa 2010. Note that I took liberties with an original typeset logo and custom illustration, since at the time, their site was essentially a WordPress blog with some stolen sprite art plus the actual Sega logo.

Admittedly, by today’s standards, the web portal style might be a bit busy, however it still represents an approach to organising heaps of content into a single page, in this case unifying a blog, forum, and the new platform’s content all in a single touchpoint.

Although now offline, a not insignificant portion of the intellectual property is evident in services like Loot Crate.


Nicalis

The deceptively simple, yet responsive site for Nicalis software's head honcho.
The deceptively simple, yet responsive site for Nicalis software’s head honcho.

Project: Website 
Role: Designer, Front-end developer
Team: <20
Environment: Remote
Key Skills: Photoshop, UX/UI, Web design, HTML, CSS
Summary: A companion site for the CEO of an indie gaming company to do fan-direct PR and other random communication.

Nicalis is a darling of the indie gaming scene, amassing a huge fanbase with their niche titles released across virtually every platform. The studio’s boss came to me around 2014 looking for a way to make personal announcements and connect directly with those fans in ways exceeding Twitter’s capabilities.

Using Tumblr as the base CMS platform, additional requirements and features such as Twitter integration, AMA events, and multi-device responsiveness were designed and implemented.

The graphic above shows screen grabs of the site as it exists today (latest post 2017), replete with rendering anomalies either the result of modifications made by the client post release or changes to the hosting platform/browsers over time. 

Curiously, instead of any title imagery, he opted to render his name in simple Japanese kana and live HTML text. Whatever the thinking behind it, it remained a popular destination far longer than Tumblr itself.

Sadly, no static renderings or wireframes of the pre-release development process exist, as most of the UX design work happened directly in the browser while I coded it, but the above does closely resemble the product I delivered. I may at some point recreate assets to further illustrate the process.

New Retail Product CX Design Case Study

TLDR; A look at what went into trying to launch an unusual new product within a larger, successful line of traditional offerings.

Project: “it™ bed” Product, Brand UX/CX Design
Role: Art Director, Product Designer
Client: Sleep Number (formerly Select Comfort)
Key Skills: Wireframing, Photoshop, UX/UI, Web design, Brand design, Style guide, Illustrator, Figma
Website: itbed.com (retired; now redirects to sleepnumber.com)
Summary: A swashbuckling adventure to define the branding and (mostly digital) brand user experience of a new product within the confines of its larger retail brand.



Preamble

Sleep Number (formerly Select Comfort) is a premium mattress and sleep product brand in America. In mid- to late-2016 they launched a new product to compete in the growing “bed in a box” space mostly owned and pioneered by Casper, but also to reach a younger demographic than they had been pursuing for decades. Enter the it bed. It married some of the adjustable Sleep Number technology with smartphone connectivity, but delivered in slender, unboxing-memeable cardboard.

The efforts put into engineering this new product unfortunately did not translate in equal measure to its marketing or branding; the result: an obvious collage of individual contributions, ranging from elements indistinguishable from the company’s “core” line of products to a schizophrenic series of new identities, tones, and brand languages every other month. Nobody said launching a new brand and identity was easy or quick.

In early 2017 Sleep Number approached me to lend my skills in product design and UX to help unify all of these points, paired with a structured market plan. Because all of the brand’s assets were designed scattershot by whomever seemed to have bandwidth on a given day, rather than approach any of those individual components (like the website, logo, or app), I aimed to apply comprehensive, end-to-end UX concepts to the entire brand; everywhere the public might encounter it.

Harnessing Scattershot Efforts

Left: a sample of one inherited brand identity. Right (2): two excerpts of a larger onboarding series of emails targeted to new or interested prospective buyers.

That said, due to the it bed being a subset of the larger Sleep Number brand, a few things were unfortunately beyond our team’s control or influence, such as affecting the product name, logo, etc.; the prevailing reasoning was to avoid disrupting the delicate sensibilities of the myriad contributors thus far. 

A Styleguide to Rule Them All

My first point of business was to establish a brand style guide, replete with baseline tone, voice, and visual language to serve as a yardstick against any work—whether done internally or externally, across all channels. Until my involvement, only partial guides with vague aspirational content and stock imagery existed; courtesy of an external agency—the entire body of them outdated by virtually every measure of our new internal team’s white boarding of brand attributes, so it was an obvious cornerstone towards building a stable foundation for the brand’s design and overall UX.

Sample pages from the brand guide. Note that some pages are altered to show analogous content from other brand guides in this portfolio.
New iconography that contributed to the overall new design language that would eventually inform the digital product UI.
New logo exploration to mirror and dovetail with the other design language and also better describe the physical product.

Aligning Multi-channel Touchpoints

The second was to begin scaling the mountain of the product’s website, built impetuously to be little more than a two- or three-page promotional resource and merely to have a minimal online presence. Shockingly, according to the company’s web manager, the site was built without any regard whatsoever for commerce, a brutally honest admission made brutally aware to any visitor looking to make purchases or find deeper information, only to encounter wave upon wave of sales-affecting hurdles. Luckily, this wasn’t the first time I have inherited what is essentially a WordPress theme and challenged with maturing the UX end to end.

Onboarding, welcome, and promotional emails that benefit from intentional copy, photography, and brand UX principles.

The third point, was to develop regular marketing materials (promo emails, display ads, etc.) to refine the content used to inform the bigger, more permanent first and second points, through iterative design exploration and A/B testing. As above, the prevailing method for these consumer touchpoints had been to apply whatever the current identity to the persistent cycles of sales promotions; so an email or banner ad campaign every few weeks with the new promo—and of course, a menagerie of brand identities to match.

Posthumous Recognition

Unfortunately, despite my and the team’s best efforts, based on a nearly complete erasure of it from the internet, it appears the it bed—a premium, tech-infused, semi-portable mattress for the millennial vagabond—was simply too limited a market and too expensive a product to survive. Mere months after my departure from Sleep Number, the company disappeared the it bed, apparently in favor of the lower end version of its traditional product line.

What you’ll see in the materials shown here are a few snapshots representing the resulting direction of the above explorative processes; I feel uncomfortable revealing the starting points because a) they aren’t my work to share, and b) by comparison might reflect negatively upon those who did work on them.

Of note: a) the responsive designs; b) consistent branding elements; c) custom iconography… all my direct efforts, made in Adobe Illustrator, Figma, and Photoshop.

Responsive web designs: mobile (left) and tablet/desktop (right). New video content was developed to support all of the points, especially because the target market favors video over reading blocks of text.

Some of these designs represent actual creative released to the public. Others represent in-progress/in-development projects that remained private to protect any promotional or sensitive brand information; available now that the product has expired over a year ago.

Custom CMS Product Design Case Study

TLDR; an online gaming news site and community I’ve led the building and rebuilding half a dozen times since 2005.

Project: Web-based app, custom-built CMS for online media outlet
Role: Director of Product & Design
Client: GoNintendo
Team: 5–40
Environment: Fully remote
Key Skills: User research, market research, mobile first, wire framing, Figma, design system, brand design, documentation, code alignment, leadership
Website: gonintendo.com
Summary: An iterative web project spanning more than fifteen years, starting from the reskin of a humble WordPress-based site to its rebranding and replacement by a custom-built, responsive CMS…twice thrice.

Overview

GoNintendo has been the world’s top destination dedicated to Nintendo gaming news and community since 2005. Having undergone six major product launches in that time—all under my direction, this case study will document the most recent launch from March 2022 following an internal tragedy which forced a site hiatus for the better part of a year.

For a deeper look at the history and previous releases, including my biggest career failure, read my article here

The Objectives

While we had previously built two completely custom CMS front- and back-end solutions replete with a content publisher and admin interface, the latest incarnation brought several new challenges that meant we could not simply recycle past efforts.

The outgoing site—while still highly capable—remains a testament to yesterday and simply not up to the challenges facing devices in 2022, supporting a team of writers or the structural differences in presenting feature content versus news.

Tragedy tends to put things into perspective. What worked yesterday was suddenly unfit for tomorrow.

– Aaron Hoffmann

Where things were

  • A fifth-generation system that while efficient, was built to support a feature set suffering from years of accumulated bloat
  • Fully responsive, but built to serve a largely desktop-based audience
  • Supported multiple domains, users and permissions groups, but the largely code-based editor resulted in huge output discrepancies and rendering issues between authors, even after training
  • Almost exclusively focused on the news feed in a blog-like format, at the expense of promoting editorial and exclusive content

Where we needed to go

  • New content mix, new layout and database/information architecture. Post-tragedy, the CEO’s vision for the site changed from mostly news to a larger emphasis on editorial and exclusive content.
    • New layout could not completely betray the passionate user base’s expectations. We learned this the hard way once before.
  • Massively streamline the feature list. Not minimal viable product, but it required a serious discussion of priorities amongst leadership. In terms of overall feature quantity, most of the past would be left behind.
  • Mobile first. For realz this time. Based on traffic analytics, we would for the first time be building for a mostly (80%) mobile audience. Compared to ten years prior, mobile technologies and expectations evolved substantially.
  • More organised editorial review workflows. The team would be expanding ten-fold to realise the new site’s direction and needed completely different technology and UX to support everyone.
  • A publishing tool that forced consistency between all authors. Expecting dozens of new staff to be or quickly become well-versed in HTML/CSS enough to all produce compliant content is unreasonable. Needs to work for beginners and experts alike.

The Work

Of course, with me, projects never begin with wireframes, largely because like developers, I prefer to avoid wasting time or expensive rework as much as possible.

While some back-end technology pieces began immediately and in parallel with design due to time constraints, I directed the project follow a structured UX methodology.

Define

  • gather requirements from CEO/leadership
  • translate requirements into discrete goals, including feature set
  • establish timeline and roadmap for launch and post-launch
  • define personas and essential new workflows

Research

  • conduct user interviews
    • understand usage patterns
    • understand device usage
  • outline essential workflow diagrams and matrices
  • competitive research and analysis

Structure

  • created design system
    • tokenised colours, sizes, etc
    • all components
  • began branding / identity refresh
  • authored documentation / style guide
    • targeting devs and future advertising partners

Design

  • produced wireframes and prototypes
  • facilitated weekly check-ins with leadership and design/development
  • completed re-branding efforts

Validate

  • weekly check-ins with leadership and dev lead, including demos and presentation of progress
  • conducted regular user interviews
    • A/B testing
    • Group interviews
    • Individual interviews
    • guided and unguided sessions
  • validated code against UX schematics with dev lead
    • my target was 80% accuracy by launch

Repeat

  • analysed/ synthesised feedback into actionable revisions
  • weekly sprints

Definition

We conducted a series of preliminary meetings to define the goals, then identify and triage the feature list, and finally establish realistic delivery windows for launch and beyond.

Defining basic IA, core feature set, personas, and a publishing user flow.
Persona matrix and publishing user flow
Working out the onboarding user flow and permissions, accounting for previously onboarded accounts and brand new people.
Defining the semantic structures early, to simplify design output later, but also to allow development to begin creating basic templates and test code with semi-accurate placeholders.

Research

We then conducted market/competitive research, partly to discover whether similar solutions existed but also to understand what our target audience is experiencing elsewhere, aka Jakob’s Law.

We spent considerable time researching and analysing our traffic data. Surprising almost no one, our device demographics nearly flipped since our previous iteration (built 2013-15), going from roughly 70% desktop to 80% mobile, 18% desktop, and the remainder filled by tablet and non-traditional devices.

Admin headaches

When it came to the publisher, the single greatest struggle in past iterations was training new users how to use the bloody thing, because until recently, good WYSIWYG editors still often relied on knowing enough HTML to tweak/fix things to achieve the desired result.

Plus, even if we could get the average person to rudimentary HTML fluency, each writer would still format their content however the cosmos struck them that day, aka zero consistency.

Rudimentary example of a block editor. Authors can easily and consistently build articles without coding. Simple options shown in the first header’s contextual flyout.

The lead developer and I each independently brought in the concept of a block editor, basically a component library for writers.

By stacking pre-made content blocks (eg headers, image galleries, pullquotes, etc.), each with predefined styling and simplified options, users would never need to muck about in the code, and would all produce identically formatted, valid HTML entries.

Ironically, WordPress introduced a similar feature in 2018, and though we had no interest in reverting to the platform we ditched over a decade earlier, their Gutenberg block editor did represent the direction we wanted to go, just without all its complexity and fluff.

To determine what blocks we would need, we first brainstormed a list, and scraped the database for 50k past stories to generate a word cloud of common tags used by authors, and then compared the two.

It was then just a matter of prioritising (or alphabetising) the final collection, much like the arrangement of keys on an English-based keyboard. We chose organisation by usage over alphabetisation, as not every writer would know our vocab for the block they needed.

The complete list of blocks available to the writing teams.

Structure

Building an entire web app from scratch with an extremely tight delivery window meant that feeling our way in the dark was not an option. Unlike past iterations which allowed organic progress, highly collaborative efforts between design and development was critical to success this time around.

To that end, though we had some very, very rudimentary sketches to illustrate the overall concept and vision from the Define and Research stages, as development set its groundwork with various frameworks and libraries, I began building out our design system, starting with the essentials.

To save time further (ie two birds with one stone), I compiled and documented all components and design system elements as a style guide as they were built.

Design system foundations

As always, my preferred design system rests upon an atomic, 16-point soft grid. All facets of the system from font sizes to spacing relate to multiples or fractions of 16.

Happy to explain that in greater detail…just reach out.

The most basic elements like font scales, colour grades, and tokens came first, followed by layout grids, buttons and input fields.

With Tailwind CSS as our presentational foundation, we also relied upon their official Heroicons collection to cover our limited iconography needs for the external facing front end.

For the block editor within the admin panel, we relied on a combination of official and custom icons inspired by FontAwesome 6.

Additional examples of more developer focused anatomical diagrams and notes:

Rebranding efforts

For a major relaunch not only of the digital product, but also a renewed vision of the services offered within it, we also wanted to introduce a refreshed branding to reflect a resurrected spirit.

Ok, enough with the “re-” words.

Some of the branding exploration. 1, one of our past logos. 2, the revised version. Third column, partial showing of commercial typeface options. Fourth column, my custom-designed typeface options. 3, the final selected lock-up.

Without exhausting the long history, we explored a number of options, but decided upon a simple streamlining of a past, fan-favourite identity.

For this, my goal was to reduce overall geometry for maximal use across devices and sizes.

Although we explored a number of commercial typefaces for our word mark, we ultimately used one I completely custom designed via Adobe Illustrator.

Design

Our goals included not just a responsive, public-facing front end, but a full admin panel and publisher, plus the new identity.

Public-facing

Given our early discussions, competitive analyses, etc.; we quickly settled into a viable mobile concept as our flagship and then expanding upon it to create desktop and tablet versions.

Early, low-medium fidelity mobile menu prototype options test:

Working prototypes of initial mobile menu options considered. External link to Figma.

The desktop navigation proved a more formidable hurdle, as the additional real estate allowed for a much wider variety of options. We ultimately presented these options in A/B testing for user validation (further below).

The remainder of the public-facing UI design mostly revolved around how each of the publisher’s story blocks would render across devices.

Examples sorting out other UX work like feature user flows and device-specific prototypes:

Ad placement

Ad placement required us to consider both the intrusiveness impact to users while balancing business needs to pay bills.

But the larger UX conundrum was how to intersperse ads given the user behaviour we discovered in earlier research.

In the past, standard pagination (click Next or Previous to load a new page) allowed us to place ads in consistent and specific locations within a layout; something highly desirable to ad companies.

However, based on our initial user research and their usage patterns, we explored using infinite scrolling instead of static pagination. This added several issues:

  • Infinite scrolling only allows a single masthead (most valuable, main header) ad once, and then lesser value ads between content as the user scrolls. This means considerably less revenue.
  • Most ads use iframes and loads of javascript, which significantly reduce performance with each instance, a serious problem for mobile (read: 80% of our) users.
    • this is further compounded by the media-heavy content our editors already post
  • Some users reported hating (automatically loading) infinite scrolling, so we needed to find a solution that allowed the freedom to peruse content endlessly but also remain purely opt-in.
Given the high level templates for both desktop (left) and mobile, we also needed to account for the necessary evil of ad placement (yellow blocks).

As visible in the low-fidelity wireframes above, once we identified the main sections per layout across the app, we could identify the prime locations for ads.

When it came to infinite scrolling, to solve for the desired opt-in behaviour, avoid performance hits, and a consistent placement for advertisers, we:

  • Made loading infinite content a simple button/link at the bottom of each block.
  • Ad placement only affects the first fifteen articles; the initial load of content.
  • Users see the same amount of ads as a single static pagination, have freedom to load additional content as desired, and advertisers gain their reliable placement. 🥇

Admin panel & publisher

Having defined the necessary publisher blocks earlier and their external-facing appearances, we needed more detailed design and UX attention given to the space our staff would be interacting with the most.

As shown below, we began with really bare bones wireframes, mostly to establish the base functionality, necessary fields, database structures, etc. Everything was essentially a single column with tiny block management buttons hugging the left side; with a stationary, floating panel along the bottom of the user’s screen.

The main UX challenges here:

  • assert consistency/logic to field arrangement
  • provide users a preview of the block content when appropriate
  • provide users enough help/context for each block’s functionality
  • make each block visibly unique/identifiable when scrolling through a longer list of them
  • simplify block management tools while providing a more robust selection of functions
  • simplify the footer contents

We performed a rigorous testing of the interface, blocks, options, etc. over the course of several weeks to refine and optimise the UX for maximum productivity and usability.

The solutions (shown in image):

  • a two-column layout was chosen; data left, options/preview right.
  • previews for blocks like images or text appear in the right column, immediately next to the input for side-by-side comparison
  • explanatory text resides beneath and/or placeholders inside most fields
  • the left margin was repurposed for its identifying icon, which can easily be scanned whilst scrolling
  • each block has a management menu next to its title, with greater options to re-order, add, remove, etc.
  • footer was simplified to a single dropdown, allowing the interface to remain consistent across browsers, display sizes, and independent of the addition/removal of blocks

Our block editor brilliantly achieved its goal of a large, diverse team all publishing consistent content and with virtually zero training.

Aaron Hoffmann

When it came to other areas of the admin area, we again streamlined wherever possible.

The dashboard underwent several iterations, ultimately formatted with cards to present writers/editors all of their necessary stats or to-dos at a glance.

It wasn’t always this organised.

And finally, to show a bit of the other scaffolding, flows, and IA behind the scenes of behind the scenes, in this case, features available to moderator and admin personas.

Orange buttons/text on and adjacent to wireframes indicate notes for design/development.

Branding

Honestly, we kept most of the identity work internal throughout the process until launch, relying more upon leadership approvals than user validation or external focus groups.

We felt confident with this approach for one reason: as mentioned earlier, we based the new branding upon our most popular past identity, and our primary aim was to reduce complexity while remaining faithful to the source.

The overwhelmingly positive reaction upon release validated this decision.

Validate

Our validation phase relied on two primary sources: direct user feedback via interviews and sessions; and code review.

We relied upon the former to ensure the layouts, navigation, etc worked as expected and that we delivered on users’ needs.

The latter, in order to reach our defined goal of 80% compliance by launch, largely relied on my personal review of production code and comparing it to the design specs, and then prioritising for the most salient or efficacious cost/benefit ratio.

User focused

For user interviews, due to Covid and our internationally-distributed team, all sessions were conducted remotely.

Users would be presented anything from low-fidelity wireframes to working coded demos. Notes taken during sessions were processed and findings presented in our weekly leadership and development check-ins.

Below, an example of a medium-fidelity A/B prototype I designed, meant to capture user feedback regarding possible desktop navigation constructs.

Note the lovingly crafted micro-interactions and transitions intended to make each option maximally desirable. ❤️

Prototype designed for A/B user testing of desktop navigation options. External link to Figma.

In this particular case, after user testing, we ultimately pursued the “Mega Menu” approach:

  • Amongst users who expressed a preference, they strongly favoured either Traditional menus or the Slide-in, and strongly disliked the other.
  • While fewer people so strongly preferred it as the other two, nobody disliked the Mega Menu. 🤷🏻‍♂️

Code focused

Often this process involved excerpting the Github repository or browser inspector, then using Figma to create aides that illustrate deltas, issues, or present rationale for needing certain code revisions.

In the below example, a slight deviance from the desktop grid spec meant our app’s massive tomes of text would be less readable, and in fact many users commented on it despite being unable to articulate precisely why.

UX pros ought to understand classic typesetting principles; font size, column width, and leading are a balancing act with algorithmic underpinnings for ideal legibility, meaning this was simple to identify and fix.

Release

After teasing on social media for months prior, we publicly released right on time; precisely one year after going offline (what I dubbed our antiversary), to nearly universal acclaim, surprise and delight.

Thanks to our pre-release user testing, we anticipated the commonest constructive comments, and announced plans to address them in successive patches in the near future alongside our relaunch.

Results

  • Released all planned features on time.
  • Targeted 80% accuracy of code to design specs, achieved over 95%.
  • Vastly improved quality and consistency of staff output, while simplifying publishing workflows and virtually eliminated the need for any training.
  • Improved user onboarding, in reduced steps required and time needed from register to usable account.
  • High praise from users, partners, and even competition for both the product and our fresh take on a beloved branding from the past.
  • Exceedingly few unanticipated “issues”.

Obstacles and learnings

  • 突貫工事. Honestly, the largest hurdle we faced was time. What would normally require 1-2 years to build had just four months (plus one upfront for planning) start to finish.
    • While the Product, UX, and development leads found a number of efficiencies to exploit, allowing us to perform some steps in parallel rather than purely sequential from planning to design to dev, a solid methodology was what truly allowed us to meet our targets.
    • Deadlines were what they were; sometimes walking a short plank is unavoidable, but given talented resources and a process, success is achievable.
  • User testing and research was invaluable. Not only did it provide insights during the planning stages leading to less design and development in production, it allowed us to rapidly narrow focus after our initial builds and iterate to release candidate.
  • A design system (including documentation) is worth multiple times its weight in gold, even for projects below the enterprise threshold. Without one, UX debt will seep into and dampen any project.
  • An organisation’s UX maturity can make or break a project, especially the more limited its resources of time, money, or talent. Being able to directly affect this from a Director level was a convenient win, but having worked with projects and companies suffering a lack of UX maturity, the contrast is black and white.

Case study: my UX process

TLDR: a guided tour through my UX solving methods, followed by a case study showing it applied to a surprise failure under threat of an impending presentation deadline.

If you think good design is expensive, you should see the cost of bad design.

Ralf Speth, CEO, Jaguar Land Rover

Preface

You may notice from the contents above that at least numerically, “design” doesn’t appear until halfway through the UX process.

Certainly, given white boarding, napkin sketching, and other abstract visual activities; flavours of design can surface during any stage, but proper wireframes can only precipitate from the information and decisions of preceding stages.

Using a homebuilder analogy, imagine the foreman demanding blueprints straightaway; day one, because they already booked the construction crew and couldn’t afford them to stand idle. If the architect took a stab in the dark and started drawing things up without time to gather supporting information or even strategise their own output while the crew broke ground immediately; the client’s reaction to an industrial-sized department store lavatory dominating their living area or a trendy fire brigade pole supplanting a traditional staircase in the dead centre of the kitchen shouldn’t surprise anyone.

Succinctly put, design decisions follow data.

For all intents and purposes described here, let’s assume a project has already met the requisite thresholds and deemed viable.

Also, this process is first described in general, as it might apply to a product’s overall lifecycle, but can be scaled up or down to an individual feature if necessary (example of small-scale shown further below).

Process definitions

1. Define

If one doesn’t understand the problem or ask the right questions up front, should it be any surprise later on when the delivered solution misses the mark?

One of the most important yet often overlooked aspects of UX is the art of definition; ensuring a solid footing with clear goals and understandings about how to achieve them. “We need a website for X” lacks sufficient information to warrant any work, design or development.

A website for what audience? On which devices? On which tech stack? Why do you need a website; what do you hope it will do for you? Does the current solution succeed or fail in any ways we can build upon or avoid? To what end; which metrics will gauge success or failure? The list goes on…

Defining personas, user flows, user journeys, etc. may also happen at this stage.

Given a list of questions whose answers distill to a series of requirements and objectives, we can continue to flesh out each point with supporting data.

2. Research

Data informs the ideal pathway to a solution, and the research which gathers that data is the heart of all UX.

Though obviously not an all-inclusive list, this process might include

  • competitive analysis to understand the relevant industry or audiences,
  • interviewing existing or prospective users,
  • research relevant existing, past, or future company products,
  • gather style guides or other branding assets,
  • exploring best practices (why reinvent the wheel??),
  • or establishing the best mix of staff, tools, or technologies to achieve each objective.

3. Structure

With a wealth of knowledge in hand, we can develop the scaffolding upon which the resulting product can emerge.

At a minimum, this should include a design system and CRUD-like standards/patterns to establish a common toolset and design language with which all UX designers and developers can refer to and produce consistent results.

Sometimes a company or product may already have these (if so, gathered in the Research stage). If not, they should be created during this stage, precede Design, and align with the data from previous steps.

While a design system (and standards) continue evolving with the needs of the project, having them as mature as possible before design reduces the amount of avoidable rework and inconsistency, otherwise known as UX debt. This debt accumulates and compounds quickly, equating to real-world values of time and money to correct, reinforcing my recommendation to mature the Structures as early as possible.

Additionally, a style guide and documentation could benefit a larger team, such as BAs, developers, external agencies, etc. through detailed explanations and diagrams of the UX work.

4. Design

Finally, we can begin designing!

Starting with the lowest fidelity; often simple, monochromatic boxes and nondescript text (if necessary at all), the highest level features, functions, organisation, etc. are evaluated first. Think of it like this: the most abstract concepts of the product begin with the most abstract design.

We do this primarily for efficiency. For example, if we can explore whether a navigational layout does or doesn’t work using basic elements, we’ve avoided wasting heaps of time compared to producing highly detailed mockups. Similarly, lower fidelity allows us to iterate much more quickly without the burdens of complexity.

Any designs moving forward should in theory meet the success criteria we defined in stage one.

5. Validate

Designs complete, we need to test their viability by presenting to users, stakeholders, developers, etc. This step will identify issues, obstacles, inefficiencies or other points needing more UX attention.

Of course, project management may elect to ignore this feedback and proceed towards release, but in general, a client will expect improvements if given the chance to identify some.

6. Repeat

Humbled by feedback, anything which failed validation gets fed back into the UX machinery. Often this means the Design stage, but may also involve some additional research or structural augmentation.

Repeating the design or structural stages allows opportunity to increase wireframe fidelity, mature the design system, or improve any prototype or existing front-end implementation.

Upon completing revised design work, it needs revalidation. Rinse and repeat as many times as necessary or allowed (management will often push to curtail iterations, citing budgetary or deadline constraints).

Once considered “satisfactory” and all objectives achieved, proceed to release.

7. Release

Once a design passes validation (or is given a pass by management), a project can proceed to full development, QA, or whatever team follows in the pipeline.

UX should continue to advise on and validate the product on its journey to final release.

Case study: “CNCX”

Here, we’ll examine a specific issue-resolution from my Government Agency case study project. It revolves around a specific function within the application’s largest and most complex subsystem, known as CSENet, a federal interface enabling intra- and especially inter-state agencies to share and manage case data.

CNCX is the function’s archaic acronym for “Create New CSENet Trans’X’ions” and will be used here forth.

UX failure: the story begins

I flew across the country to deliver a progress report of sorts to the government officials on behalf of our UX and development teams. Arriving a week prior to prepare, imagine my surprise when in the eleventh hour, I get a frantic call from our SME that one of the core features we planned to present contained a fatal flaw

It turns out one of our UX designers failed to follow a process like described in this article, which resulted in a design that did not attach to the codebase; it literally could not (ever) be made to work and required a complete redo.

Putting aside the obvious revelation of a show stopping gap in our validation process, while normally not an issue for UX pros, with the presentation just a business day and a half away, how could I possibly solve this?

A: methodically.

1. Defining

Obviously, the primary problem was that our UX solution solved nothing.

However, doing just a bit of legwork to determine precisely why it didn’t work serendipitously uncovered a secondary usability puzzle.

Let’s first examine the known pieces of this puzzle:

Technically, our guy included all of the fields, albeit in such a slapdash fashion that he seemed to intentionally disregard every one of our CRUD standards and the design system.

Putting those critical failures aside like so much spilled milk…

The problem laid in the fact that he did not interview anyone or investigate how the screen actually behaves in the legacy environment, instead referenced only a screenshot from the user manual and jumped straight to designing wireframes.

This meant that the designer was unaware that this screen features a linear chain of logic and business rules and thus requires a specific linear user flow.

The legacy system included no mouse or free interaction with fields on-screen; every bit of navigation required use of the TAB key, much like screen readers today. This more or less forced users to complete every screen in sequential order.

Our CNCX solution lacked any linearity whatsoever; instead offering a smorgasbord of clicky interface widgets that [despite a tab order defined for accessibility] users could freely interact with in any order. Without the requisite linear flow and dependencies, the form could not validate or attach to the business rules.

The new system architecture omitted these limited legacy input methods as part of the overall modernisation mandate, meaning this cascading method of locking/unlocking fields based on completion order was not an option.

Further, our standards/patterns forbid the use of hiding/showing screen elements (for accessibility purposes), precluding our ability to simply reveal a new field as the user completes one.

The secondary problem emerged from the mouths of literally every person I interviewed in effort to define the primary problem: while the legacy software technically worked, it worked so obtusely that almost nobody could actually figure out how to use it. So most people didn’t. They would actually fill out the paper version and snail mail it. 😳

Definition summary:

  1. Design did not match the legacy system in form or function; causing it to fail validation.
  2. The legacy system was nigh unusable for all users, forcing them to time- and cost-inefficient non-digital workflows.
  3. Defined success as an interface that faithfully reproduces the input and output methods of the original system while also being usable with any level of experience.
  4. Defined the basic user flows.

2. Researching

Until I could gather more detailed technical specifications and supporting information, I couldn’t properly ideate solutions.

In this case, despite having already discovered the general nature of the problem, I was effectively brand new to this screen’s functionality and knew nothing of how it actually worked.

Problem one: technical defects

Why was this linear flow necessary?

After reading through some of the dense source governmental documentation, it became clear that this function generates a whitespace-sensitive text file where each character position corresponds to a specific value and must therefore follow a universal standard so any recipient can decipher it.

Example of the coded data output plus chart explaining what vales each character position corresponds to.

*Not included in this case study is my research and solution for the underlying IRG (Intergovernmental Reference Guide) function that also stands atop a federal lookup table and powers many of the agency address functions throughout the system.

Examining again the basic user flow defined earlier, I came to understand that the initial field groupings (1-3) represented a hierarchy of specificity; earlier fields were more general and later more refined.

The first grouping served as a main category, the second a sub-category. The combination of those two act as a boolean AND operation; the result abridging a list of 250 reasons to a more browsable ~ten for the third field (Txn Reason).

This meant that presenting users a non-linear assortment of fields fundamentally violated the business logic, making the form unable to validate and ultimately why our original design failed.

Problem two: usability defects

This linear logic also reveals the usability failure affecting 99+ percent of users.

Through interviewing users, SMEs and developers, I learned that the third field was ultimately of most interest; the Txn Reason being a five-digit alphanumeric code describing the specific nature of the transaction.

Unfortunately users could not skip directly to this field; they needed to complete the first two steps. Why? Two reasons.

First, that is the same order those value are generated to the output file, and thinking like a developer, the simplest way to program the application too.

Second, the reason codes numbered an unwieldy 250 possible values and could benefit from a filter or two to shorten the list and improve discoverability. At least this was the thinking decades ago.

So, the legacy system implemented the first two fields as filters, each whittling down the list by about eighty percent, resulting in a more manageable list of 5-10 codes by the time our intrepid users got to step three.

In theory, this makes sense…use filters to reduce a long list to a shorter one. Looking at the graphic above, imagine scrolling through a list of 20k US cities. It makes much more sense to first sort by State, then County, making the City dropdown much, much shorter.

The usability problem arises whenever a user doesn’t know which Type/Action combinations produce which Reason codes.

And this was the case for literally all users, causing most to repeat the process multiple times, trial and error style, to find their desired code.

In fact, during the 30+ year lifespan of this software, apparently just one person in this agency ever memorised each code and its combination of filters.

Luckily this one person happened to be my primary SME and ultimately our saviour.

Making sense of mountains of coded data. Some of this data is also available publicly.

Fortunately for us, this person once upon a time transcoded their mental matrix of codes and combinations into a more tangible spreadsheet. Studying this allowed me to identify and extract data patterns which then led to the solution.

Because of the dangerously brief and looming deadline, these first two stages happened in a single afternoon (plus a few evening hours from my hotel room).

Research summary:

  1. Interviewing developers and technical SMEs filled in the blanks to how/why this screen functions as it does.
  2. Interviewing users helped identify their pain points and desired goals when using this screen.
  3. Studying the federal interface’s documentation and SME’s collateral allowed me to formulate a strategy to solve both the technical and usability problems.

3. Structuring

Fortunately, I built our entire design system and served a pivotal role in defining our CRUD standards/patterns, which gave me a holistic understanding of and how to best apply both to these problems.

We actually established a “wizards” pattern for linear processes; a parlance familiar to most Windows users. The nearest analogue for most people might be software installers, which guide users through an installation step-by-step.

The maximal wizard flow, replete with alternate and conditionally dependent steps not shown in the original designs, but which fit neatly within the overall process and everything in their correct order.

The fields on CNCX were a bit misleading in their visual simplicity; several of them triggering modal pop-ups with alternate steps/fields depending upon the larger data constellation. For example, a specific Type, Action, and Reason given a case’s details might also trigger a pop-up to select someone’s employer, or choose from a list of children who would be affected by this transaction. All still part of a linear process, yet each being much more complex steps that appeared in neither the original screen nor our designer’s version, but could be easily added as a step within a wizard.

CNCX as a wizard could connect to adjacent wizards for a seamless user workflow.

Coincidentally, I designed other functions adjacent to CNCX which I already knew had hooks into and could bookend both sides of it in a user’s workflow. Those functions also used the wizard pattern, meaning CNCX as a wizard could integrate seamlessly between them, allowing a continuous, guided user flow rather than segmented steps.

Structure summary:

  1. My participation in the creation of our design system and patterns gave me a holistic view of the system to know that our wizard pattern would work best here.
  2. I designed adjacent functions (also wizard patterns) that could tie into CNCX as a wizard, offering a deeper integration and convenience for user workflows.

4. Designing

Remember that black and white screenshot of the legacy software…or our UX designer’s stab at it?

Both of those complicated, unusable failures transformed into this under my direction:

Step one of the new Create Transaction process = step three of the old one.

“Too simple to be true”, I can hear you thinking.

Technically correct as this is only the first step of the re-imagined process, and additional steps do follow.

However note that this new “step one” corresponds to the third step of the legacy process; those menacing first two steps no longer appear to hinder or confuse users.

So what happened to them? As required fields, surely their values must exist when the data gets transmitted.

Rather than serve as obstacles users must forcibly overcome, my design grants users their wish to directly access the reason selection.

My research uncovered a way to let the system automate the rest of the annoying bits.

Why It Works

Simply put, we reverse engineer the filters/category selection with some automation and reverse lookup.

Top: example Reason codes with their corresponding Type and Actions. If you rearrange the table columns, it still works with all rows aligned.

Referring to the graphic above, I’m effectively reordering the lookup table’s columns whilst leaving the rows intact. Putting the Reason first lets the system automatically populate the appropriate Type and Action from the next column with no additional user input required.

If I was the developer here, especially thirty years ago, a simple set of filters to match the lookup table structure, output file’s formatting, etc. might seem the obvious approach. But given modern UX practices, we can achieve much more efficient and usable products with just a bit of care.

This deceptively simple result neatly illustrates the tremendous value of UX to modern products.

Aaron Hoffmann

This design, wireframes and flow happened in a single day, leaving just a weekend between finishing and our presentation.

Design summary:

  1. Given a definition of success, adequate research data, and components/patterns from the design system, the actual design falls into place quite easily.
  2. The resulting wireframes and flows satisfy all of the success criteria while respecting our design system’s edicts.

5. Validating

Blessed with a devoted team of developers inspired by this unique new vision and a desire to present their very best work to the state, they happily volunteered weekend overtime to build a semi-working live demo for our presentation Monday morning.

Below, one of the detailed, annotated prototypes I prepared for developers, to assist building our presentation demo. Orange buttons in the upper left corner contain notes on hover.

I also authored additional documentation and scripts to support additional scenarios in the demo.

Prototype excerpt of the presented, revised CNCX workflow. External link to Figma.

The following Monday, when presented to the state officials and delegation of field case workers, the disbelief and delight could be read on everyone’s awestruck faces. Welcome to be sure, but far better a reaction than I anticipated. 😳😳🤯

Most of the audience seemed to expect a hidden catch, as though too good to be true. The tech/dev leads’ mental gears visibly churned, double- and triple-checking my logic until finally acquiescing in approval. A resounding success all around.

However…once the initial hubbub settled, one glaring issue remained:

This overpopulated dropdown extends well into the ninth circle of UX Inferno.

The above image shows only a fraction of the codes available in this field; imagine it four times longer.

Giving users what they really wanted (immediate access to that third step) turned out to be a wish too much granted. 🥴

Despite having a search-in-place functionality for dropdowns, one with 250 options clearly ran afoul of usability best practises. Not to mention now users couldn’t reach consensus around the data sort method in that dropdown: code first, or description first?

Right on cue, a BA towards the back of the room confidently suggested adding some filters or grouping the items by Type/Action to make better sense of all these Reason codes.

To which I could only respond by projecting a slide of that awful legacy screen and ask, “by a show of hands, how many preferred when we tried that last time?”

“Oh…right. Nevermind then”.

This illustrates why I love user feedback, but never take it at face value. What interests me is the rationale driving the feedback, and how my expertise can transform it to identify and solve the core problem.

I love user feedback, but never take it at face value…probing for their why reveals a more actionable insight.

Aaron Hoffmann

Rather than react literally to “can you add some tabs, add a link to X, put a button, etc.” I usually probe for why they want, need, or suggest something, and then as the UX expert, take the underlying insights back to the drawing board.

And so went the second (and a half) day of this process.

Validation summary

  1. Users and developers alike LOVED this new approach.
  2. However, the Reason selection method needed additional consideration, as a single dropdown with 250 options fails a number of usability concerns.

6. Repeating

The only aspect of my radical new approach that failed user validation was that pesky, overgrown dropdown.

As it happens, our design system contained other selection components and patterns. Tables to the rescue!

By transforming the dropdown into a table, we could offer a more robust method for viewing, sorting, or reducing the entire list using real-time text filters.

While a partial solution, not ironically, repeated user validation found users needed greater sort and filter functionality.

Step one, we split the data into two columns, which solved for sorting. However our real time text filters supported only one column per table, meaning one of the two would not be “searchable”.

Internally, this table selection pattern frequently caused debate amongst the UX team as to its viability, and this CNCX situation finally and firmly pushed the issue over the threshold into “must resolve” territory.

Surprise UX issue #3: the design system

Specifically, these points regarding the table selection pattern repeatedly arose over the course of our project, but now required an immediate resolution:

  1. Accessibility.
    • Some tables required a button press with the filters to retrieve new data, while others could filter the data already there with no additional hit to the database.
    • Filters and search patterns often looked the same, confusing users why one screen would be formatted as X while another as Y.
    • Similarly, offering search and filtering for the same screen was impossible.
    • The individual filters were also separated and sized differently from their respective table columns, often betraying user expectations.
  2. Inefficiency.
    • If used at all, our developers insisted each column have a filter, even if it didn’t need one. This could be counterproductive in some situations, and certainly space-inefficient given the size of the filter fields.
  3. Inconsistency.
    • Date fields especially presented issues. While often shown as a discrete value in the table, as a filter, users would realistically need a range, and our date picker could not accommodate two values for one field, requiring two date filters for one value.
    • Developers had trouble implementing the filters (query DB or not?) due to poor documentation of the source material and
    • Designers often delivered inconsistent or technically inaccurate wireframes. Sometimes a submit button would be present, sometimes a reset button, sometimes both, sometimes neither. Sometimes filters for each column, sometimes just one. 🤷🏻‍♂️🤷🏻‍♂️🤷🏻‍♂️

Introducing inline table filters

Let me first acknowledge that I did not invent this concept. It already existed in the wild and addresses all of the above issues.

I took this opportunity to jump back to Step 3: Structure and upgrade our design system components and patterns: the inline table filter.

In addition to simple sorting per column, users could also independently filter the data of each via targeted widgets.
Issues resolved
  • CNCX has sortable and searchable columns for its 250 codes
  • Accessibility improved
    • filters are directly connected to the data being filtered
    • confusion over buttons and search eliminated
    • ability to include both search and separate filtering functionality
  • Inefficiency improved
    • columns could show or not show filters if desired
    • overall vertical space reduced by up to 200px
  • Inconsistency improved
    • Date filters can include ranges when necessary, and in a single input
    • Developers no longer confused about data retrieval methods; all filters use the same method.
    • Designers have a single, flexible component
The final CNCX selection solution
The entire product benefits from solving this one (actually three) surprise UX failures.

Now, after only a few brief revision cycles, we not only solved a massive UX conundrum, but introduced an upgraded component and interaction pattern that actually solved a number of other development and usability concerns throughout the rest of the product, while pleasing every single user in the process.

Conclusion

You made it to the end, congratulations!

I realise this process may sound overwhelming; that it must certainly require more time (and therefore money) to enact than just jumping straight to design concepts.

But consider that at 5-25x the cost, rework represents one of the greatest threats to a product’s budget, not to mention the additional time to do it all, adversely affecting any deadlines.

So imagine how likely success will be the first time around with undefined, uninformed, unstructured design.

Or by expecting high fidelity for all concepts, rather than start simple, validate, and build up complexity over time?

Or by appropriating funds to begin building designs with an army of developers day one, before anything has been tested or validated as worth developing in the first place?

Success would be highly unlikely, especially in a first or single round of effort. In these situations, everyone should expect plenty of extra rework effort by both design and development teams.

By contrast, imagine approaching a product cycle having defined the objectives, done research to narrow focus, etc. and before committing to the expensive development, having most of it figured out. Much less waste of time and money, despite a longer lead up to prototypes and codebase production.

The lessons learned from the tortoise and hare of Aesop’s Fables fame also applies here. While this process may seem counterintuitive or slow by comparison, the data and results speak for themselves: a steady methodology at any speed wins every time. 🐢💨💨💨 🐇