part 2: patterns

accelerating anaconda with an ai- connected design system

Jump to Part 1: Foundation Library

overview

With foundations shipped, I lead the creation of the pattern library. We wrote our own definition, anchored our work on the one CEO-approved prototype, and built 10 reusable patterns.

Role

Senior UX Designer

product

Pattern Library

collaborators

Project manager, 2 ux designers

timeline

1.5 months

constraints

No industry-standard definition to borrow, mid-acquisition chaos, stakeholder friction

The constraints

No industry standard definition to borrow

When researching how to define and create a pattern, we found no guidebook nor consistent definition across the industry. We had to write our own definition and figure out the patterns our company needed, which took more time than we thought.

no real screens to build from

With three companies merging and products still being redesigned, there were no finished screens to reference — the platforms themselves were still being figured out. How do you define a recurring pattern when the thing it’s supposed to recur across doesn’t exist yet?

Stakeholder friction over ownership

A new senior designer pushed to be included in pattern library creation, although ownership wasn’t assigned to him, slowing down our pace. I resolved this by giving him part ownership over a content-rules work stream, which better suited to his interest.

research & synthesis

What do pattern libraries look like in the industry?

Before creating our pattern library, I conducted a competitive analysis to see which design systems had patterns, how they defined them, and what they included in them. Then, I led a pattern definition workshop using a Miro Board.

Pattern library competitive analysis
Miro board workshop

what we learned from our research

loved IBm’s definition of pattern.

IBM defined a pattern as a solution to common design issues / how a user reaches a goal. They should be reusable combinations of components in which have constraints for the designer - but still leaves room for creativity.

Svelte had to be production-ready by November. Shadcn could do just that.

loved github’s differentiation of patterns

Github differentiated their patterns into two groups: UI patterns (common patterns like tables) and scenario patterns (actionable patterns like “edit” or “delete”). We thought this approach would be beneficial for our products

ShadCN’s accessibility baseline was independently audited (34/48 components passing WCAG 2.2 AA, rest remediable) .

appreciated ant’s inclusion of “global Rules”

Ant approached the design patterns a little differently; it had subcategories of “global rules,” “principles” and “templates.” This approach gave us the idea to include rules

ShadCN’s accessibility baseline was independently audited (34/48 components passing WCAG 2.2 AA, rest remediable) .

define

creating our definition of a pattern & workflow

First, we had to ensure that we had our own definition of a pattern. Once that was established, I was able to create acceptance criteria, set up sprints in Jira, and create the Figma file.

Pattern definition and acceptance criteria

Definition of pattern

Acceptance criteria

setting up figma file and screen references

Figma file set up

screenshots of new platform concepts

creating patterns

let the work begin

First, we had to ensure that we had our own definition of a pattern. Once that was established, I was able to create acceptance criteria, set up sprints in Jira, and create the Figma file.

Example: Header pattern

For each pattern, we wanted to include the component, rule, examples, and screens

COMPONENT

variants / Examples

Rules

Screen examples

foundation library handoff

pattern library in progress, always iterating

From this screenshot, we finished the UI patterns and were still refining global rules and other potential patterns.