Back to Work Samples

Case Study:

Argo Design System Pt. I: Background, Assessment and the Design Inventory

Successfully pitched building a design system. Conducted an inventory of organizational digital application design.

Client
Argo Group
When
Winter – Spring 2020
Company Profile
Argo Group is a large international business insurance conglomerate. The group consists of twenty-five individual Insurance “business units” (separate corporate entities which specialize in specific sets of coverage types in different countries), eighteen of which are US based.
Role
UX/UI Design, Visual Design
Work Type
Full-time
UX Design,UI Design,Visual Design,Information Architecture,Design Systems

TLDR: When I joined Argo Digital in June 2019 there was barely a Design System in place. I was tasked with strategizing, roadmapping and seeing a revamped Design System through to fruition. I began this process with a detailed design inventory of our major active applications and extracting what parts required design team alignment to move forward.

Preface

This is the first of a three part series documenting the development of Argo Digital’s Design System, also known as Argo Product Language (APL). Building APL has been a massive undertaking with many moving parts, phases and loads of intensive collaboration. While APL has been a multi-team effort with many incredible contributions from hard working teammates, I have had my personal 2020 and 2021 annual OKR’s tied to it’s progress and delivery and hence have been most responsible for seeing it through.

In this first part, I’ll discuss the background context and exploratory phase of APL’s development. This consisted of assessing the state of Argo Digital Design: a design inventory of each of the department’s major applications and an analysis of what we needed alignment on for a robust design system.

For an in-depth look at the actual design phase of APL’s development, skip to Part II: Design System Sprint + APL Figma Library.

And finally, for a look into the final phase, bridging the gap from design to development, see Part III: CSS Library .

Argo Group is a large international business insurance conglomerate. The group consists of twenty-five individual Insurance “business units” (separate corporate entities which specialize in specific sets of coverage types in different countries), eighteen of which are based in the US.

Argo’s Digital department builds (primarily web) products to improve various aspects of an individual business unit’s operations. Examples include Argo Pro Predictive Insights (APPI) – a data visualization dashboard which leverages data dynamically pulled from SEC annual and quarterly filings. The APPI dashboard helps Underwriters of Management Liability policies use a more consistent and data-driven approach in their risk analyses and pricing.

Or Wrapper Intake, a tool to help Argo’s offshore operations units extract data from hand-written scanned submission forms (and hence building out our database of historical risk indicators).

When I joined Argo in June 2019, Digital consisted of six “squads,” each of which owned different products servicing a specific phase of an individual Business Unit’s operations. The department had been around for roughly four years and had built about ten products, some of which had been handed off to IT or retired.

Digital had a rough skeleton of a Design System but it was neither robust enough to cover each squad’s needs nor well documented enough for an easy user experience. Adoption amongst the squads was low, with only one product using components from the system.

I embarked on an analysis for the primary reasons for the existing design system’s shortcomings. This consisted of interviews and meetings with various stakeholders throughout the department and attempting to use and understand the system myself. The primary reasons for its current state were:

1.) Lack of dedicated resources

The system had mainly been contributed to by two designers (and various short-term freelancers) who were overstretched by their shared duties of working on most of the department’s other products.

2.) Lack of institutional commitment or personal ownership

The system had been treated mostly as a pet project by the two full-time designers but was never officially stated as a departmental goal, nor was it tied to any individual’s performance reviews. Hence neither the department leadership nor any individuals prioritized it. Instead, it received contributions whenever there was time available.

3.) Lack of collaboration, team communication or feedback

Because of the void of individual responsibility, there wasn’t sufficient collaboration or communication for a system each squad could understand and use. Many of the developers were vaguely aware of the existence of a system but didn’t know where they could look to find any documentation or how to use it. There hadn’t been any formal departmental presentations, announcements or updates on the system’s goals, rollout or development. Though the designers knew much work needed to be done, they didn’t have the bandwidth to establish a feedback channel.

4.) Disparate and inaccessible pieces

Much of the system existed in various Sketch files that relied on a host of other applications and plugins to access (Abstract, Sketch plugins, InVision, Craft, etc.). The designers were the only members that even had Sketch on their machines.

Even then, if one loaded up the Abstract repo without the necessary suite of plugins, the system’s components wouldn’t render properly. The individual Sketch symbols were built on a legacy system of mix-ins that were complex and unwieldy to understand or edit. As a new designer, I often felt it was more time efficient to just create a brand new symbol rather than try to find the right symbol or mix-in combination.

The primary design documentation was constructed in Zeplin (which most of the developers didn’t have).

Finally, there was an early version of a UI Toolkit, essentially converting the Sketch assets into React components (most of Digital’s applications are built on React). But it was built quickly by a contract developer who hadn’t included much documentation for usage, variable use-cases or context.

Fortunately, Digital was on the brink of a transitional period which allowed for a revamp and formalization of the Design System initiative. Shortly after my hiring, the design team expanded from two to five full-time members.

Additionally, a reshuffle of the department’s leadership and team structure allowed for cross-functional squads. Now, in addition to designers’ quarterly and annual goals being tied to product release initiatives, they would also have goals specific to Design team initiatives (including the Design System, the Research Library, Unmoderated testing tools, etc.).

My personal goals were around planning and owning the development and release of the new design system.

Another key development was the Design team’s shift from Sketch to Figma after assessing it would improve team and departmental collaboration (Figma allows for sharing design canvases via URL vs. Sketch’s desktop app and mac requirements). This change quickly proved extremely fortuitous given that it was just before the pandemic and work-from-home. I’m not confident we would have been able to collaborate sufficiently had we stuck with Sketch. More on this topic in Part II: Design System Sprint + APL Figma Library.

I was tasked with mapping out the macro pieces of the system as well as roadmaps and timelines for each one.

High level, I determined the major necessary parts the system needed were:

  • Design artifacts with a well-documented style guide, components and templates (in our case in Figma) including:
    • Core base styles (eg. color palette, typography, icon library, etc.)
    • Reusable components from basic atoms to more complex organisms and page sections (borrowing heavily from Brad Frost’s Atomic Design Concepts)
    • Out-of-the-box page layout templates with consistent responsive container and grid structures
  • A coded UI-toolkit (mapped one-to-one to our design documentation) that developers could use for out-of-the-box styling
  • A governance system allowing for feedback, additions or change requests from various members from the design or development teams

In order to build each part, I determined the following development phases:

  1. A design inventory of our most actively used applications, the current design system and Argo branding guidelines (done by myself)
    • Noting inconsistencies in designs of each (from base styles through to page layouts)
    • Compiling a generalized list of recurring component types
  2. A collaborative design phase (the entire design team)
    • I would present my findings of each component’s different use-cases and designs to the design team
    • All five members of the design team would collaboratively assess, rethink and ultimately vote on new designs for each component
  3. A documentation and design artifact building phase (managed by myself; collaboratively built by each team member)
  4. A UI-toolkit development phase (coded by myself; discussed frequently with development and design teams)

I made a project in JIRA to help track and share the progress of each phase of development. I broke each phase into micro-steps, estimated time needs for each and developed the roadmap accordingly.

Just as a functional product team needs to consistently seek feedback for improvement of an application, we would also need to consistently ensure the system was sufficiently meeting the needs of our teams. We established that we would do this via a combination of:

  • Bi-annual surveys to the department to measure:
    • Awareness of the system
    • Understanding of the system’s capabilities
    • Adoption/usage or lack thereof
    • Frustrations with the system
  • Bi-quarterly departmental presentations of the system’s progress with Q&A portions
  • Bi-weekly meetings including the Design and front-end development teams known as the Frontend-UX Guild – focusing on specific issues we were working on in the system
  • A dedicated Slack channel for the Frontend-UX Guild for A-sync announcements and dialogues

The first step was a detailed inventory of the designs of seven of the department’s most active applications. The purpose of this was to analyze and document the variety of design decisions used across our applications as well as identifying the gaps in the existing system. The desired output was a list of generalized base styles, components (from basic atoms to complex organisms) and page types that would cover most if not all of our application needs.

This list would later be the basis for the collaborative design phase of the system.

For each application, I did an exhaustive exploration of potential user flows, micro-interactions and pages, taking screenshots as I went along. I built separate sketch files for each application and assorted the screenshots of each page together.

Then I inspected each individual element and compiled a list of:

  • All colors used
  • text styles
  • layout widths and any grid usage (if applicable)

I then broke down each page into its smallest parts and compiled images of each.

After having looked at each application’s individual pages, I was able to categorize and group almost every one into a couple of broad flow types and page types. I found that almost all of our applications followed two major flow types which I’ve (creatively) named:

  1. Search-Display
    • Just as it sounds – a user searches and sees a list of results
  2. Create-Thing
    • A user creates a new entry of some sort (eg. a submission, claim, risk entry or rating worksheet)

On a level below flow types, I found almost every page fit within six page type categories:

  • Listings (or collections)
  • Forms
  • Overview/Details Review
  • Search-home
  • Search-listings
  • Account-listing

Once each page was categorized and grouped, patterns of repeatable page sections and components emerged. For example, each Search-Home page had a prominently displayed primary searchbar and button. Similarly, the corresponding Search-listings page utilized a section with a set of components I would later term Listing-card-rows followed by a pagination component.

After reviewing, categorizing and annotating each page, component and base style of each application, I had a list of roughly twenty components we’d need alignment on.

The next phase would be organizing and facilitating collaborative design and voting sessions with the team. That is documented in Part II: Design System Sprint + APL Figma Library.