User Experience and Product Designer
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
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
Research and personas
Existing research was leveraged from particular products, and their designs, as the basis for the
The research did indicate that users who'd learned an existing and even awkward product didn't want to
Users knew their unique UX and might not want it to change.
Existing personas were borrowed from individual product teams,
and used to prepare
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
The guidelines would also need to grow and evolve,
while monitoring for occasional
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
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.