Government SaaS Platform

Overview

In 2016-17 UnitedHealth Group and its tech branch, Optum, must have foreseen a market in and some impending collision of government and insurance by founding a new startup division called State Government Solutions (SGS).

Their ultimate aim was to create a SaaS platform, leveraging their enterprise-level databases and security experience, that could be resold to multiple government entities who would benefit from instant access to these integrated systems.

They aimed to piggyback development of this new SaaS platform via their inaugural project with the State of West Virginia Department of Health & Human Resources, who had several decades-old systems sorely in need of modernisation and integration.

How, why I took this project

Why work on something that isn’t beautiful, cutting edge, or even at least lucrative?

In short, to help people.

Given WV’s rank of affluence in the union, I saw a good opportunity to lend my skills for the benefit of fellow Americans humans. Because being a good person and affecting positive change in the world ranks as a crucial criterion for my project selection process. The world is what you make of it, etc…

As for how, the poor intern who SGS thought would/could shoulder all of the design (and even some development) to the tune of massive profits quickly saw how deep the pool really was and immediately sought senior level pros like me to fill in the many, many competency blanks.

Though I was brought on as a Senior UX Designer, within the first year, my role became Principal level, overseeing many of the high level responsibilities, most complex subsystems, mentoring junior teammates, delivering formal presentations, partnering with engineers, of course along with my banana-fuelled wireframe output.

Initial challenges

• Startup environment, extremely low UX maturity
• Immediately spent over 90% of budget on business analysts, PMs, and an army of developers
  • Developers mostly stood idly by from day one with nothing to build
• The whole of UX and design was to be foisted upon a single intern 😳
  • Actually, Optum maintains an internal UX Design Studio, but because its time is charged back to any other group requesting their time, with little/no remaining budget, SGS largely opted out of using UXDS
• UX viewed by leadership as low-level “monkey” work (sadly, their actual word), akin to graphic design…or something. A mindless, perfunctory step merely serving to assist unimaginative coders (aka the real contributors).

“Lipstick on a pig”

…or what might otherwise be labelled a wakeup call or course correction.

Once the State witnessed our initial presentation of progress at the six month mark, that folksy idiom echoed repeatedly throughout the sizeable conference room.

They saw no meaningful improvement; at best some cosmetic differences that did not excite.

Resetting expectations

First, with the help of our project manager/director, we needed to remind them that our mandate was not to create a new system, but to refurbish their existing.

Second, we came prepared with slides articulating our high level UX vision, guiding principles, and goals.

Fortunately, business-friendly concepts like reducing clicks, system redundancies, improving overall organisation, accessibility, etc. brought even the hottest tempers back to earth.

My contributions

If it’s no stunner, what did I even do?? To be clear, we targeted “bookish” beauty versus “pageant” beauty here.

Specifically, as the principal of our team, I provided UX leadership for our team’s efforts at each step of the UX process and product life cycle. To summarise my specific involvement:

(emphasis denotes critical functions I managed alone 💪)

• Define
  • gather requirements from BAs, state officials, tech SMEs
  • translate requirements into discrete, achievable goals and define our core UX problems to solve
• Research
  • interview users, SMEs, devs, and BAs
  • define personas / roles
  • attend actual, formal State user training
  • analytical system research (understand the source material)
    • investigating every nook and cranny of the old system
    • reviewing the outdated user manual
    • identifying its gaps and authoring/publishing missing content as an appendix to team.
  • card sorting to support the information architecture & navigation
  • match accessibility requirements to our project requirements
  • research industry and best practices
• Infrastructure
  • define “CRUD” standards in senior UX roundtable sessions
  • designed all system components
  • assembled all assets into a cohesive design system
  • created the toolsets for the UX team to actually use the design system
  • authored style guides and technical documentation to developers and other designers
  • developed templates and best practices for design production
• Design
  • produced wireframes (my focus was the most complex system functions)
  • led (re)branding efforts
  • facilitated bi-weekly UX team round tables to review work, answer questions, align efforts, gather suggestions, and provide mentoring for junior members
• Validate
  • conducted user and stakeholder presentations, demos, and interviews
  • constructed specific testing scenarios, authored scripts, and built presentational materials in close partnership with dev team
  • validated code against UX schematics with dev team
• Iterate
  • analysed/ synthesised feedback into actionable revisions
  • maintained standards, design system, style guide, templates, etc. as necessary

Findings and insights

• Team structure: the new enterprise division exhausted ~95% of budget on BAs, PMs, and an army of Developers. Management expected devs to “build, build, build!” starting day one, without any direction, schematics, etc. UX cannot be effective as a procedural afterthought or post-production Instagram filter.
• UX Maturity: limited UX resources (time and money) and lack of leadership understanding about modern software development, meaning we spent inordinate amounts of time pitching and advocating for even the basics like research, time to define standards, building a design system, etc. We still had to cut plenty of corners.
• Statement of work: the contract stipulated tech migration and modernisation, but leadership planned both tracks to happen simultaneously.
  • Realistically, this only muddied the waters of both, introducing countless issues that nobody could diagnose or attribute to one group’s efforts or the other, limiting either’s ability to correct. Ideally, these should have been done in consecutive, not concurrent stages.
  • State officials frequently cited vaguely worded requirements to smuggle whole new features into the project, obviously also introducing significant costly delays. An escape hatch clause ensured we must comply or risk forfeiting any/all payment for work already done. More legal due diligence up front would have levelled this playing field.
• Enterprise-Government liaison: a third party meant to neutrally traffic both parties in reality limited communication and effectively prevented us access to users. Only when the agency noticed a lack of their own input into the process or its results did they start demanding direct involvement, finally allowing us limited user access and feedback. Access to target users should be explicitly negotiated or defined in any/all contracts.
• Third party vendors & software:
  • Some external vendors were hired for their proprietary tools ended up clashing with internal tools and compatibility.
  • Many sub-teams/project managers selected off-the-shelf and free/open source tech, apparently hoping to save time or money, but this only introduced additional incompatibilities and complications to assimilate. Always involve UX, even in the tech stack discussions, and invite representation from all teams when making foundational decisions, even to a single pillar of a project.
  • Vendors frequently stalled progress in order to extend their own billable hours or statements of work; they also regularly refused to partner with internal teams, favouring their own billable resources.
  • I spent an inordinate amount of time in audit trying to untangle this project’s UX spaghetti; overzealous PMs resisted any change to their own fiefdoms. We would have done well to be more judicious up front in evaluating these external tools and providing greater transparency to potential partners about the demands required for success.

Building UX infrastructure

Beginning with team white boarding activities, our infrastructure consisted of three primary pillars: standards & patterns, components, and documentation.

Standards & patterns

CRUD, or Create, Read, Update, Delete served as our standards baseline, mainly because those database interactions represented everything our users would experience with the system.

CRUD also made sense because the legacy software relied exclusively on various “modes” that generally equated to one of the database interaction methods.

While we would have loved ultra-modern, edit-in-place fields, technical constraints (eg form validation logic, 508 compliance, error message handling, etc) dictated we use modals to clearly define for users which CRUD method they were currently interfacing.

A few excerpts from a much larger body of governing standards:

Additional context & detail

Due to the sheer volume of data on many screens, common instinct—even for experienced UX designers—is to parcel them away behind layers of various interface widgets.

Our target audience (primarily mid- to late-career professionals) was accustomed to straightforward display of information a la the legacy system and not reliably proficient in common app widgetry of 20XX. Obviously every click reduces efficiency, but with every layer of hiding data or functionality behind interface widgets, we risked confusing and frustrating users by making more difficult what never used to be.

Therefore, we wanted to explicitly define and limit those tendencies to conceal information. This included strict rules for how different expandable components may be used alone or in combination.

Links vs buttons

After discovering some of the agency’s systems using text links and buttons interchangeably and often for wildly different ends, we sought to clarify use patterns for a more consistent experience (a 508 concern).

• Buttons trigger actions, and never for navigating between pages.
  • Being actions, button labels must contain a verb
• Links only navigate to other screens, and never trigger actions or modals.

We also defined placement for buttons, so any and all actions could be quickly identified.

Tables

Ubiquitous throughout the system, we defined 2.5 table variants, largely to work nicely with the columnar flex box model.

The extra half variant really meant converting each table row into a card for mobile screens.

• A traditional table of rows and columns for simple purposes;
• A table with an expandable drawer that opens beneath the row to reveal additional data that would otherwise exceed the limitations of a traditional table.
  • Careful consideration was given to data prioritisation; which would be columns in the main row and which inside the drawer.

We were also mindful of user focus and scope when it came to triggering actions.

• Simple tables showed all of the data in each row, so actions could be shown alongside it; in the same row.
• Expandable tables place lower priority data in the drawer, so to prevent users from accidentally deleting anything without seeing the full context of the row’s data, all action buttons also reside inside each row’s drawer.

Modals

Information in legacy usually consisted of fields jigsawed and truncated to fit a single terminal window, with little rhyme or reason, making reading or finding information a chore.

Editing data however was straightforward: press the PF2 key and any editable fields would change from blue to green. When finished, press another key to save and exit update mode. The only failure here might be relying on changing text colour alone for accessibility reasons.

Vocally disliked by many, modals aptly solved switching from display mode to something like editing. We could neatly organise data into sections and columns, give users relevant actions per section, and then collect any modifiable fields into a single, focused, and labelled modal window.

Gathering all editable fields to perform a specific action also solved a technical issue as all fields needed to validate together upon submitting the form.

We could also use modern UI widgets to deal with groups of information in ways not possible previously. Large section titles, columns, tabs, accordions…they all translated neatly to tabs inside a modal.

Curiously, the legacy system had virtually no methods to protect against accidental erasure of records. Modals allowed us to inject a confirmation step across the system and also clearly display specifically what would be permanently deleted.

Hydrogen Documentation

Standards and patterns: ✅
Component library: ✅

Literature explaining it all: 🦗🦗🦗

Unfortunately management saw no point. “Design system? What’s that? Component library? Huh!? Style guide? More graphic designer prima donna hogwash!”

However, as an indefatigable optimist, I undertook these things anyway…on the DL and without approval. Not from a rebellious bent, but because I couldn’t stand to intentionally work inefficiently nor allow teammates to either.

A year later, these covert efforts paid off when management realised they needed documentation (and the rest of that “hogwash”). Cue muted words of appreciation.

This forethought helped build some credibility for our team, and got a foot in the door for additional UX advocacy. But I digress…

Anyway, we published two sets of documentation, one for engineers and one for a general audience. The former focused on specs; the latter upon explanation and demonstration.

Engineering edition

As with the components themselves, the documentation starts with the atoms and builds molecules, organisms, etc.

I have the CSS in mind whilst building components, so I often include excerpts, especially if suggesting SASS transformations or tokens, which would not be obvious simply from inspecting a design in Figma/Sketch.

Because we knew it would be displayed on a second monitor like our wireframes, I formatted this guide the same as our wireframes: landscape 1280, even using the same 12-column bootstrap grid.

Establishing the root atom & grids

Base colour atoms, values, purposes

Type atoms scale, definitions, etc.

Icon atoms, purposes

Button molecules

Input molecules

Advanced selector templates

Navigation organisms

Pattern resolutions (addendum)

General edition “Ultraguide”

Yes, we actually called it the Ultraguide internally, as it was meant to be all-encompassing; everything to everyone. Because we anticipated heavy printing, I formatted it portrait 8.5×11″.

Also built with an atomic mindset starting with the basics and building up complexity, this guide included orders of magnitude more explanation, do’s and don’ts, and guidance.

Seriously…I regularly received emails asking if we could include “a (whole??) page” on something as specific as defining date/time formats, because while built into the components for engineers and designers; BAs, managers, state officials needed this guidance.

Don’t get me wrong, I love pedantic detail, and when it comes to a large product with hundreds of moving parts and dozens of teams, one can never really be too prepared for delivering consistency.

Printable pages!

Starting with basics, including the H₁ atom

Color atoms; more examples shown here than the engineer edition.

Type atoms. Plenty of explanation.

Type style. Mostly the same; a bit of added explanation.

Typography Do’s and Don’ts.

Icon atoms, part one.

Voice, copy, etc standards.