Back to Work Samples

Case Study:

Argo Design System Pt. II: Design System Sprint + APL Figma Library

Organized and managed an intensive two week collaborative design team sprint to reach alignment on all major design system components resulting in the design system Figma library.

Client
Argo Group
When
Summer – Fall 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,Branding

TLDR: Armed with a list of common components gathered from the Design Inventory, the next step was getting Design team alignment on designs for each. With the help of two other team members, I planned, organized and facilitated a series of Design “voting” sessions. In those, we looked at the variety of implementations of each component, focusing each session on a specific component. The goal was to devise an agreed upon list of rules, constraints, attributes and styles for each. These were then codified in an APL documentation Figma file which serves as the core of our design system library.

Preface

This is the second 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 second part, I’ll discuss the collaborative design phase of APL’s development. This consisted of over 80 hours of intensive collaborative design sessions with the ultimate outcome of an agreed upon system of core base styles, components and page layout templates. All of this was codified in an APL figma documentation file which housed the master versions of each component.

For an in-depth explanation of background context and the exploratory phase in which I analyzed and compiled a list of what we needed design alignment on in the first place, refer to Part I: Background, Assessment and the Design Inventory.

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

Having compiled a comprehensive list of the items we needed in our Design System, the next step was achieving alignment from the design team on each of them. We had a relatively small team of five senior designers with a pretty flat structure (although we did have a team lead, she was not dictating design decisions down to us). In order to make the system a success (and to avoid repeating one of the failures of the old system) it was crucial to establish team buy-in and proactive collaboration. This would also make the system more robust generally (different designers could think of different specs and use-cases of any given element based on their unique experience).

I began planning and scheduling collaborative design sessions. Using the roadmap and task list, I focused the first sessions on the most fundamental building block styling decisions: Color, Typography and Container & Grid layout.

The format of each session was:

  • Introduction to a style or component (~5 minutes)
  • Sharing findings of usage of said style or component from the inventory (~10 minutes)
    • Examples of use-cases across applications
    • highlighting inconsistencies across designs
  • Discussion (~25 minutes)
    • Come to alignment on requirements based on the different use-cases presented
    • Add any missed use-cases or requirements if applicable
    • List options based on agreed upon set of requirements
    • Consolidate options into clear format for voting
  • Voting (5 minutes)
  • Determine next steps
    • Determine if more sessions needed for topic
    • Determine if any homework needed

Each session required significant preparation. I built figma files that the team could follow along during the presentation portion and contribute to in the collaborative deliberation portion.

I had an introductory section that would include the findings of the inventory with a list of use-cases and inconsistencies.

I also broke down different pieces of each discussion to hard “decision points” for the team to come to agreement on.

We held 14 (45 minute to one hour) collaborative sessions in which we agreed upon the base styles for the system (colors, typography, basic page layout and grid templates, content boxes and basic text elements) over a couple of months but we weren’t moving fast enough.

Our design team lead had the idea of packing the rest of our components voting sessions into an intensive two-week sprint in which we would be uninterrupted by our product squad work. By successfully lobbying for this with Digital Leadership, aside from carving out the necessary dedicated time for team collaboration, it also solidified a new level of institutional buy-in from management.

With these new magnified stakes, it was more crucial than ever that we made effective use of this time. Our agreed upon goal metrics were to make finalized decisions on the 22 remaining atoms and molecules, and to document and build each of them as components in Figma.

With the help of our team lead and another designer, we carefully planned out every minute of those two weeks, dividing each day into three sessions.

Each session included: a fifteen minute introduction to a component and its use-cases which I would present; an hour in which designers would sign off and design their own versions of the component independently; a presentation period for each designer to quickly share what they’d built; a quiet commenting period and then a discussion, voting and decision period.

Most sessions focused on a single component but amongst every five to six sessions was one slot for collaborative building. In these, the team would test all of the component decisions thus far by assembling them into full page layouts. This allowed the group to check for cohesion and consistency of the system holistically as we went along designing each individual piece. We also included multiple flexible session slots for revisiting components that had proven particularly challenging to come to group alignment on.

We included three opportunities for retros: after the first two days of the sprint, with a day for review to change up strategy if needed; at the end of the first full week (mid-sprint) and finally at the very end of the sprint.

The retros gave team members the ability to comment on what was working and what might need a rethink. Multiple useful ideas came out of the first two retros which we quickly applied, including having one of the facilitators reprise a “builder” role – essentially have someone actively making changes on a design board as members are discussing ideas, hence illustrating and testing concepts for the whole team to see in real time.

Another idea that emerged was having a full-team inventory of all the components on the final day of the sprint – essentially a check that we’d made decisions consistently across the components with regards to styles such as colors, shadows, borders, corner-radiuses, and text treatment among others.

With extensive help from a design teammate, we built out a set of Figma Sprint files:

  • A file with pages for each day’s presentations, homework sharing, deliberation and final voting documentation
  • Homework files for each designer to work on separately

The Sprint Day working file would serve as a collaborative documentation space for each session’s presentations, the team’s experiments and final decisions. By the end of the sprint it was an impressive tribute to intensive team collaboration.

The sprint was wildly successful with finalized decisions on all major components as well as a deeper level of respect from each design team member for the team’s abilities as a group. Sentiment in the end sprint retro was very positive with each member expressing pleasure at the results. The design system was looking slick.

The sprint produced the crucial decisions for the rules of our design system but we still needed to codify the system in a documentation space and a working library of usable design assets. We built out an official Figma file for APL’s documentation and component library. The file included an introductory readme with how-to’s and pages for documentation of each component’s designs, rules and master component. We divided up duties for documenting and building each component between team members.

With the release of the APL library, designers could now drag and drop components from the design system into their respective product squad design files – speeding up their design process and introducing consistency across Argo Digital products.

The final pieces would be introducing a governance system (via which designers could suggest changes and additions to the system) and bridging the gap from design to development. That is documented in Part III: CSS Library.