🛠️ Scaling Systems & Processes

Overview

This use case relates to scaling the processes that designers use to support Business.NJ.gov.

  • My Role: Design Team Lead
  • My Responsibilities: I led the creation, documentation, and rollout of a scalable design process, ensuring it integrated seamlessly into sprint workflows and supported cross-team adoption.
  • Timeline: 4 weeks or 2 full sprints to develop the process. Ongoing maintenance was then embedded into sprints.
  • The Team: 4 designers, 1 product manager, 4 engineers. This was a sub-team of the main Business.NJ.gov project.
  • Tools Used: Figma, Figjam, Atomic design, Azure DevOps, Google Docs, Hemingway Editor

Framing the Challenge

Problem

The team was growing, and our processes needed to scale with it. Designers needed to use one design system while on different teams. There was no process to funnel new designs from each team as the sprints progressed. This made keeping the design system updated difficult.

Pain point #1

Inconsistent and outdated components increased cognitive load for designers, slowed down sprint work, and hindered problem-solving.

Pain point #2

Lack of cross-team visibility led to siloed design work, limited collaboration, and prevented the reuse of new components across teams.

Pain point #3

Outdated components created confusion for product managers and developers, resulting in misaligned stories, duplicated work, and reduced delivery speed.

Pain point #4

The user experience suffered from inconsistent patterns, slower feature releases, and a lack of visual and functional polish across the product.

Hypothesis

Creating a process that allows designers to independently contribute and improve the design system ensures consistency across the product, speeds up design and development workflows, fosters a sense of ownership and collaboration within the team, and allows for continuous scaling.

Goal

Write clear documentation outlining the new process for contributing to the design system. Ensure the process is adaptable and a designer can fit it into their current workflow and capacity.

Process & Approach

Key contributions

  • Creator of the implementation strategy, writing tickets for execution, and working with the product manager to align on priority and scope.
  • Strategist behind all process updates. Ensuring that any recommendations would support a designer's current workflow and not hinder it. Balancing new processes while encouraging adoption.
  • Authored all documents and artifacts created to communicate the new process. Focused on clear and concise writing.
  • Ensured the process was flexible and scalable as the team evolved and matured, allowing designers across teams to easily contribute without disrupting their sprint workflows.

Discovery

  • Researched team workflows and adoption pain points by interviewing designers, mapping current-state flows, and identifying where friction or confusion occurred across teams.
  • Audited Figma limitations and usage patterns to understand how libraries, permissions, and publishing controls could support or hinder the new contribution process.
  • Analyzed industry benchmarks through a competitive review of how other teams manage design system contributions, helping to inform a scalable, low-maintenance approach.
  • Aligned with product leadership by drafting a strategy doc, outlining implementation steps, and identifying the need to also document broader team norms, not just design system contributions.

Implmentation

  • Rolling out the new process was intentionally incremental, designed to minimize disruption and ensure it aligned with how designers were already working.
  • Prioritized clarity and adaptability in all documentation. Used plain language, visual examples, and flexible templates so the process felt approachable and useful, not prescriptive.
  • Shared drafts during weekly design team meetings, allowing for feedback in real time. This created a feedback loop that helped refine the documentation as it was authored.
  • Actively gathered input from designers using both synchronous (live discussion) and asynchronous (comments in shared docs) channels to accommodate different working styles.
  • Used feedback to inform immediate iterations, building trust and fostering a sense of ownership among the team.
  • Embedded reminders and prompts into sprint rituals, like standup and design critiques, to support long-term adoption without adding overhead.
A flow chart showing the process for design teams to funnel new components and updates to the design system.
A screenshot of a planning and strategy document. Used to facilitate a priority conversation with the product manager.
A screenshot of the table of contents of the final documentation that was created and delivered.

Challenges & Solutions

Challenge #1

There was no designated point person to manage contributions or ensure process consistency.

Solution #1

Collaborated with stakeholders to define and formalize this role on the project. Ensuring someone was accountable for oversight, updates, and cross-team coordination.

Challenge #2

Designers worked on different teams, with different sprint goals and needs. A rigid or overly complex process would fail.

Solution #2

I intentionally designed the process to plug into existing team rituals and touchpoints. This made adoption as lightweight and low-lift as possible to integrate into each designer’s day-to-day.

Challenge #3

Without a sustainable process, new components would pile up and out-of-date ones would linger.

Solution #3

By embedding this process into each sprint, the system is now maintained in real time. New components are added, and legacy ones are updated or deprecated regularly, keeping the system fresh without extra overhead.

Challenge #4

Convincing stakeholders to prioritize internal design operations work, especially when user impact isn’t immediate, was a hurdle.

Solution #4

Emphasized long-term value in strategy and planning calls by showing how small process investments now would prevent costly rework later. I stayed flexible with timelines and designed the process to be self-sustaining, making it easier to justify and maintain.

Outcomes

Deliverables

  1. 10+ pages of extensive documentation
  2. Ticket strategy and content document
  3. Flow charts

Results & Future

Improved cross-team confidence and autonomy by embedding a lightweight, scalable contribution process. Reducing duplication, streamlining collaboration, and enabling designers to focus on solving real user problems. Continue evolving the process by incorporating designer feedback and staying aligned with new Figma capabilities.

Key Takeaways & Learnings

Lightweight processes drive adoption

Designers are more likely to adopt and sustain new workflows when they’re built to align with existing sprint rituals and require minimal overhead.

Process ownership is critical

Defining a clear point of accountability ensured the design system remained up-to-date, reducing ambiguity and creating a reliable feedback loop for continuous improvement.

Cross-team collaboration needs structure

Without a shared contribution process, silos form quickly, even among strong teams. A centralized, yet flexible model enabled collaboration without slowing down delivery.

Design operations work must be framed as product strategy

Internal infrastructure work often lacks immediate user-facing value. Reframing the conversation around future efficiency, consistency, and scalability helped gain stakeholder buy-in.

Documentation should evolve in real-time

Publishing process updates incrementally and actively incorporating team feedback ensured the solution stayed relevant and usable throughout implementation.

Sustainable design systems require constant maintenance

By embedding upkeep into each sprint, technical debt can be avoided and the system kept functional, trusted, and scalable as the product and teams grow.