Richard Emberton UX Designer

User Experience Design, UI and Visual Design


Guidelines for a suite of diverse apps

Bringing a family of acquired products together


Vertafore had built up a collection of apps for the insurance industry, some acquired, some developed in-house, and needed to unify the different user experiences, for coordinated suites.

The user experiences across the product range was tremendously varied, with some having older style UI, and others simply being engineer-built. And years of patches and fixes were also apparent in the UX.

Guidelines site prototype main menu.

Problem/Solution

Several key obstacles existed:

A guidelines document was proposed, with areas initially targeted:

Card sort exercise with a Post-it notes wall: Goals, needs, priorities and pain points for the guidelines document.

Role and Scope

The Designer's Role: One designer in charge of the entire guidelines effort, to get across-the-company guidelines up-and-running, own/control it, and get buy-in from all the key players.

All while being part of a team of 6 or 7 designers and researchers, who were each using their own unique ad hoc guidelines for the various apps they supported.

The unified guidelines would be successful if they:

And v1 was needed ASAP (separate style guide and pattern libraries could be spun off later.)

Stakeholders also indicated certain areas were not in scope. Some particular features would be left as-is, or have visual fixes only. Dev was obligation to not touch certain areas of legacy code that management didn't want to risk breaking.

Research and personas

Existing research was leveraged from particular products, and their designs, as the basis for the cross-product guideline. That general design was then trimmed down to just the basics, with parameters to allow some flexibility.

The research did indicate that users who'd learned an existing and even awkward product didn't want to re-learn something they already knew how to do. So we'd also need to present the "upgrade" as a usage advantage, not a style change.


Users knew their unique UX and might not want it to change.


Existing personas were borrowed from individual product teams, and used to prepare proto-personas for the different proposed suites. On a strategic level, these consolidated personas helped reveal which products should be grouped into which suite offerings. Personas were also prepared for the guidelines document itself, for the developers and designers who'd use it.

Sketch to capture the basic task flow: A developer has a UI question, uses Search or a Contents page, and jumps to an individual entry.

Ideation and design

For designing the guidelines site itself, a first step was to determine what dev and UX team members want it to do... Card sorting exercises helped bring priorities to the top.

And don't rely on names of UX widgets, as those weren't consistent across dev or design.

The site should also be easy to maintain and debug, using simple HTML.

An initial sketch to find a more logical nesting order for various navigation mechanisms across the products.

For editing, adding and updating entries in the guidelines, a simple review/approve process would be in effect at the start. Initially approvals for changes would be done case-by-case, with the plan to later add a mechanism to check-in/out and track changes.

The guidelines would also need to grow and evolve, while monitoring for occasional "work-arounds" or rule-breaking:

A high-fidelity mock-up for visual explorations for a common navigation mechanism.

Prototype and Test

Example guidelines pages were prepared, with real content in place, to get a basic HTML internal site up for review and walk-thru.

Simple interactive wireframe prototypes were used to help finalize common sequences and behaviors.

Final results

The guidelines site was up and running for full in-house access. As comments came in, changes were reviewed and integrated.

Example from the style-neutral guideline for base navigation and general page structure.

The project was largely successful, but also very much a learning experience, some key points:

Example from the style-neutral guide for common error indication locations.




Next project →




© 2018 Richard Emberton