How to make 20 years of internal-facing apps cohesive

Problem

HCA had recently spun off its shared services department into its own company, which came with the technical baggage of 58 different Internal Revenue Cycle Management apps that had beed developed across 13 regional service centers. None of them had design help or were homogenous – they were created out of necessity by the developers & business analysts over a span of 20+ years.

For the first time, tools were starting to be used across multiple service centers. Parallon needed help developing a shared visual language and more standard interaction patterns… they just didn’t know quite how to articulate their needs.

Research

Initially, the team was asking for standard brand colors and fonts to aid in development. Talking more with the service center leads, I realized that what the different teams were asking for was bigger than that. They were asking for a library of common components to draw from, so that the team didn’t have to write front-end code every project.

Together with a business analyst, we ran an initial audit of the interaction patterns across all 50+ tools and found that several were doing the same things, just in slightly different ways or using different nomenclature. Presenting these findings to leadership, we identified a core of apps that would be the standard-bearers for their specific functions.

Solution

I put together a kitchen-sink kit on the main dev server that anyone could start a project from.

As the only designer for 40+ developers, providing a dev-focused resource met the team where they were at. Being able to pull the kit directly into Visual Studio meant that they could copy / paste menus, buttons, headings, and page skeletons pre-styled to meet their needs.

Part of the standardization was creating logos for all of the shared applications that stayed true to the spirit of any ‘original’ logos that the teams were both familiar and proud of.

Results

With a standard set of components in place, internal apps were able to be designed in 30% less time – almost wholly attributed to having standards and not needing to hand-roll CSS every project..

A big bonus of standardization is that we were able to retire 11 apps due to redundancy. Everyone was happy for less tech to maintain and we threw a party the day we got to delete all of the bugs related to those apps from the backlog!

Most importantly, the standardized patterns made the apps easier to learn for a broad audience of service center workers that used these apps 40 hours a week – in some cases (as measured by accounts worked per hour) productivity increased by 50%!