Unite Us

Design Patterns

Build a Payments domain pattern layer on top of the core design system—so designers can assemble complex flows faster, stay consistent across initiatives, and reduce design-to-dev drift.

ROLE

Design Engineer

  • Designed the Payments domain pattern library in Figma and partnered with engineering to align UI composition and handoff.
IMPACT
  • Reduced time-to-design for Payments screens by standardizing repeatable layouts and interaction patterns
  • Established a single source of truth for Payments UI, decreasing rework caused by inconsistent specs
  • Improved designer–engineer coordination by aligning patterns closer to how the UI is implemented in code

Challenge

Create a reusable Payments pattern layer that keeps screens in sync and reduces repeated “re-assembly” work from primitives.

As the platform grew, teams needed UI that was consistent within their domain, not just at the primitive component level. Payments was especially complex—multiple user roles (payers, CBOs, network leads) and many edge states—so designs drifted easily across initiatives.

Approach

Compose design-system primitives into Payments patterns, then package those patterns into page templates teams can start from.
Payments Team Templates

I created reusable Payments page templates by composing domain patterns from existing design system primitives. These templates gave the team a fast starting point for new work and ensured that repeated sections (headers, action areas, details panels, validation states) stayed consistent across initiatives—especially as requirements changed frequently.

Component Design Patterns

One key pattern was Invoice Details, designed as a reusable composite with clear variants by user role and invoice state. For example, a Disputed Invoice variant includes an additional dispute summary section above the standard invoice fields.By standardizing these variants in one place, we reduced the risk of small spec differences (like a missing field or mismatched label) that can create confusion in implementation and QA.

Design Engineer Alignment

Beyond documentation, the goal was to improve handoff quality by making the pattern library map more directly to how the UI is built in code. With patterns defined as stable, named building blocks, designers and engineers can discuss changes at the pattern level (not per-screen), making reviews faster and reducing ambiguity.Longer-term, this structure sets us up to leverage tools like Code Connect and Figma MCP to tighten design-to-code traceability.

WHAT'S NEXT

Now that the Payments domain pattern system exists, the next step is adoption and governance:

  1. Define a default workflow: “Start from template → adjust with patterns → only drop to primitives when necessary.
  2. ”Run lightweight enablement (examples + office hours) to reduce friction and build trust in the library.
  3. Establish criteria for maintenance and promotion: if a pattern appears across multiple domains, evaluate promoting it to the core design system.
  4. Explore Code Connect / MCP to speed up implementation.