A Design Guild to a Design Council.
How teams who kept reinventing the same button became one practice with shared ownership. The button was never really the problem.
Company: Fidelity · Domain: design systems · Scope: 30+ teams · Role: Co-founder and Co-lead, Senior Product Designer · Status: Guild founded, Council in progress
January 2026 to present · Active
A COMMUNITY. A SHARED PRACTICE.
Design Guild
Founded · connection first
Rapport
Best practices
Shared resources
A place to align.
Design Council
In progress · ownership next
Shared decisions
Focused initiative guilds
Clear start. Clear stop. Named owners.
A path to sustain what we build.
Design Intake Toolkit
From community to shared ownership. The toolkit provides the front door; the contribution model provides the path.
Why this matters for a design systems team
Cross-product consistency needs shared decisions, not just shared files. A useful front door helps designers adopt the process and take ownership of what comes next.
Details are generalized to protect confidentiality.
From Guild to Council
30+ product teams
Bring needs, context, and reuse opportunities.
Design Council · in progress
Me, a design system designer, a governance designer, and another UX designer. Partner: the product area leader who owns the design system.
Initiative guilds · illustrative efforts
Start: named problem and committed owners. Stop: agreed outcome and handoff to a maintainer.
Component initiative · Start: scope agreed · Stop: outcome handed over
Pattern initiative · Start: scope agreed · Stop: outcome handed over
Figma and Storybook parity initiative · Start: scope agreed · Stop: outcome handed over
Shared Design System
Figma library and Storybook stay aligned through shared ownership and versioning.
Diagram: teams bring needs to a Council, which assembles time-boxed initiative guilds around shared outcomes.
60-second summary
Problem: 30+ teams interpreted shared patterns differently. The platform felt like separate applications, not one product.
What I did: I co-founded the Guild, co-lead the Council’s evolution, and designed and built the Design Intake Toolkit.
Result so far: All 5 teams in my product area use the toolkit. Multiple Council designers use it. About 10 to 15 of 30 to 40 chapter designers have adopted it.
What is next: Put the documented contribution model into practice and measure what reaches sustained use.
5 of 5
Teams in my product area use the Intake Toolkit.
About 10 to 15
Of 30 to 40 chapter designers have adopted it. Used on a real project.
Real work, not just a process deck
Documented
Propose to Sustain
The path from an idea to a maintained component.
Live prototype
Design Intake Toolkit
A working front door that exports shareable briefs.
Live site
Operations case study
Unified dashboards and standardized reports for system health visibility.
Generalized toolkit visuals below explain the design decisions. The live prototype is available above.
A community became a practice
I co-founded the Design Guild to build rapport, best practices, and shared resources. We are now evolving it into a Design Council that prioritizes work and gives designers ownership of it.
One platform. Too many interpretations.
Many components are hard coded and do not scale. When the pattern is open to interpretation, every team makes a reasonable decision that adds up to an inconsistent product.
User cost: people have to relearn familiar actions. Team cost: designers and engineers solve the same problem again. Business cost: inconsistency makes change harder to coordinate.
If we do nothing, the next feature inherits the same ambiguity. The library grows. The shared language does not.
Continue · Filled action: stronger emphasis
Continue · Outlined action: different emphasis
Continue · Text action: weak discoverability
Illustration, not research evidence: the same action acquires different meaning when every team chooses its own treatment.
Co-founder and Co-lead, Senior Product Designer
I remain an active Co-founder and Co-lead. This practice began in January 2026 and is still active.
I owned the toolkit’s design and working prototype. I co-founded the Guild and help shape the Council’s operating model and contribution path.
I influence shared priorities, not reporting lines. My partners are a design system designer, a governance designer, another UX designer, and the product area leader who owns the design system.
The platform spans 30+ teams. That is the scope of the challenge, not a claim that every team has adopted the Council model.
Proposed RACI, confirm before publication
Council priorities: Council leads Responsible; product area leader Accountable; contributing designers Consulted; product teams Informed.
Toolkit: me Responsible; [CONFIRM: accountable owner]; Council designers Consulted; product teams Informed.
Component delivery: initiative designers and engineers Responsible; [CONFIRM: accountable maintainer]; Council Consulted; consuming teams Informed.
The constraints are part of the design
Figma and Storybook drift. Teams release at different rhythms. The process has to fit the work, rather than become another reason it cannot move.
January 2026 to present. Participation is voluntary, with dedicated headcount. The operating model still has to fit different teams’ release rhythms.
Research that should change a decision
The evidence below is a collection plan, not a claim that these studies are complete. Each method answers a different question.
Component audit
Evidence to collect: an audit of hard-coded components and repeated local implementations.
Insight to validate: local implementations are making the same pattern diverge.
Design decision to test: shared tokens and reuse criteria. An audit makes the fragmentation visible.
Designer interviews or survey
Evidence to collect: designers’ friction with contribution, ownership, and starting a project.
Insight to validate: contributors need a clearer starting point and owner.
Design decision to test: intake and tier-based routing. Conversations reveal where the process breaks down.
Figma and Storybook comparison
Evidence to collect: paired Figma and Storybook examples showing where design and code disagree.
Insight to validate: design and code cannot act as one reference while they disagree.
Design decision to test: parity initiative and semantic version freeze. A paired comparison checks the handoff itself.
The decisions that make this an operation
Evolve the Guild into a Council
Options: Keep a community forum or add a decision-making body.
Why: The Guild built relationships. The Council gives shared decisions a home.
Tradeoff: More accountability means clearer boundaries and more coordination.
Time-box initiative guilds
Options: Permanent committees or focused efforts with a start and stop.
Why: A named effort gives designers ownership and room to build depth.
Tradeoff: Someone must still own maintenance after the effort ends.
Make Core earn its place
Options: Promote a local request immediately or require reuse evidence.
Why: At least 3 more use cases and committed designers protect the shared library from one-off needs.
Tradeoff: A useful emerging pattern may wait while its reuse evidence develops.
Use tiers and lanes
Options: One approval path or Local, Shared, Core with Fast, Standard, Strategic lanes.
Why: Small changes should not carry the same coordination cost as strategic ones.
Tradeoff: The routing rules need clear examples so teams do not game the lane.
Start with Figma and Storybook parity
Options: Add new patterns first or align design and code first.
Why: A shared system is harder to trust when its two representations disagree.
Tradeoff: Parity work can be less visible than new features. [CONFIRM: this is the first prioritized initiative.]
Make accessibility a gate
Options: Check at the end or require evidence before release.
Why: Accessibility belongs in the acceptance path, not a cleanup sprint.
Tradeoff: The gate needs reviewers and a documented path to resolve failures.
Build an intake front door
Options: Ask people to read the process or help them start using it.
Why: Exportable briefs turn a conversation into something the next owner can act on.
Tradeoff: A toolkit needs its own maintenance and usability work.
What we chose not to do
[CONFIRM: no top-down mandate]
[CONFIRM: no big-bang rewrite]
[CONFIRM: no central team deciding everything]
Propose to Sustain
Documented: Local, Shared, and Core contribution tiers. Fast, Standard, and Strategic lanes. A Core component needs at least 3 more use cases and designers committed to help.
The model includes an Accessibility Gate, a semantic version freeze to keep design and code in sync, a Definition of Done, and an adoption check after release.
Proposed flow for review: the sequence and owner assignments below are a draft, not a reproduction of the documented model.
0 · Define
Proposed owner: Requester and designer
Output or gate: Project Brief or Opportunity Brief
1 · Propose
Proposed owner: Contributing designer
Output or gate: Problem, existing patterns, and reuse evidence
2 · Route
Proposed owner: Council
Output or gate: Choose Local, Shared, or Core and a lane
3 · Commit
Proposed owner: Initiative guild
Output or gate: Name contributors, owner, start, and stop
4 · Design
Proposed owner: Designers and engineers
Output or gate: Align the Figma pattern with implementation
5 · Validate
Proposed owner: Accessibility and design reviewers
Output or gate: Accessibility Gate and design review
6 · Freeze
Proposed owner: Design system owner and engineer
Output or gate: Align semantic versions across design and code
7 · Release
Proposed owner: Maintainer
Output or gate: Definition of Done and release guidance
8 · Sustain
Proposed owner: Maintainer and consuming designers
Output or gate: Adoption check and ongoing ownership
Read left to right, then down. On phone, stages follow the same order vertically. This sequence remains proposed until matched to the documented model.
Accessibility Gate, proposed checklist
Keyboard operation and logical focus order.
Visible focus and meaningful labels.
Contrast, zoom, and non-color status cues.
Screen reader names, roles, states, and error guidance.
Record issues and resolve failures before release.
Definition of Done, proposed checklist
Figma and Storybook match the agreed behavior and version.
Accessibility evidence and design review recorded.
Usage guidance, constraints, and examples documented.
Maintainer named and adoption check scheduled.
The Design Intake Toolkit
The toolkit is the front door. Project Intake turns a product owner conversation into a Project Brief. UX Brainstorm creates an Opportunity Brief. Design Review creates a Review Report. Every tool exports its output.
In the proposed flow, Stage 0 captures the problem and Stage 1 turns it into a contribution proposal. The toolkit makes that handoff easier to share and review.
I designed and directed the toolkit in Figma Make. Figma Make generated the implementation. My contribution was the design and direction, not a claim of hand-written code.
Project Intake
10 sections produce a Project Brief.
Project Intake · Define
Project name
Customer Portal Redesign
Team
Operations Team
Problem framing
I am · trying to · but · because · which makes me feel
Cost of inaction
What happens if nothing changes?
Output: Project Brief
Generalized redraw of Project Intake. The problem comes before a solution; the cost of inaction makes urgency explicit.
What to look for
Project Overview; The Problem; Goals; Users; Scope and Requirements; Resources and References; People and Dependencies; Open Questions; Priority; UX Assessment.
Design decision: The structured statement starts with “I am, trying to, but, because, which makes me feel.” It keeps the problem user-centered.
Design decision: “What happens if nothing changes?” makes inaction visible. Section navigation and a progress counter support returning to the work.
UX Brainstorm
8 sections produce an Opportunity Brief.
UX Brainstorm · Ideate
Opportunity
Describe the opportunity
Facts and evidence
Separate what is known from what is assumed
Ideas
Explore directions within the constraints
Recommendation
Explain the direction and why
Output: Opportunity Brief
Generalized diagram of UX Brainstorm, not a captured screen. Evidence, ideas, and recommendation remain separate so the output is useful to the next owner.
What to look for
Opportunity; Problem Statements; Goals; Facts and Evidence; Open Questions; Constraints; Ideas; Recommendation.
Design decision: Use this when the problem is understood but the direction is not. Separate evidence from ideas.
Design decision: Export a shareable recommendation so the discussion survives the meeting.
Design Review
7 sections produce a Review Report.
Design Review · Review
Usability
Nielsen’s 10 heuristics
Accessibility
Keyboard, labels, contrast, and focus
Content
Clear language and useful guidance
Design System
Consistency with shared patterns
Output: Review Report
Generalized diagram of Design Review, not a captured screen. Explicit review criteria replace subjective feedback; the report preserves the review.
What to look for
Nielsen’s 10 heuristics, plus Accessibility, Content, and Design System checks.
Design decision: Review against explicit criteria, not personal taste. Accessibility is part of the review, not a separate afterthought.
Design decision: The exported report gives the next owner a record of the review.
Tool Guide
Choose by situation, not by tool name.
Tool Guide · Choose a starting point
Need to define a project?
Project Intake · Define
Know the problem, not the direction?
UX Brainstorm · Ideate
Have a design to evaluate?
Design Review · Review
Output: Choose the tool by situation
Generalized diagram of the Tool Guide, not a captured screen. Situations lead to tools; Research and Ship remain planned gaps.
What to look for
Maps tools to Define, Ideate, and Review.
Design decision: “Where do you want to start?” helps someone choose from the problem they have.
Design decision: Research and Ship are current gaps in the process map, not shipped coverage.
Useful enough to use on real work
Results so far: All 5 teams in my product area use the Design Intake Toolkit. Multiple Council designers use it. About 10 to 15 of 30 to 40 chapter designers have adopted it.
Adoption, with the uncertainty left in
Product area · 5 of 5 teams
Chapter · about 10 to 15 of 30 to 40 designers
Blue interval: estimated adopted count, 10 to 15 designers.
Dark interval: estimated chapter size, 30 to 40 designers. Both rows use the same designer-count scale ending at 40. These are ranges, not a percentage or a growth curve.
Source: reported toolkit use. Adopted means used on a real project. Multiple Council designers also use it; their count is not specified.
Adopted means used on a real project. The chapter count is approximate. It is not a percentage and it does not imply chapter-wide adoption.
Use across the Council and one product area suggests a possible path outward. It does not yet prove a diffusion curve or a causal effect on delivery.
Council leading indicators are separate from toolkit adoption. The contribution model is documented; its adoption outcomes remain unmeasured.
Measurement plan: record accepted requests, named owners, release versions, actual use, and export counts. Compare time to a usable brief before and after with the same definition of “usable.”
What the evidence can support
Delivered · Guild founded. Toolkit built. Propose to Sustain documented.
Adopted · All 5 teams in my product area use the toolkit. About 10 to 15 of 30 to 40 chapter designers have used it on a real project.
Not yet demonstrated · Faster briefing, greater design-code parity, and sustained Council contributions. These need baseline and follow-up evidence, not optimistic estimates.
Community opens the door. Ownership keeps it open.
Draft reflection for review: I would set the measurement baseline earlier. A community gives people somewhere to belong; governance gives decisions somewhere to land.
An honest risk is volunteer fatigue. Time-boxed initiative guilds help bound the commitment, but somebody still has to sustain the result.
I want the next designer to spend less time asking which button is right, and more time making the right thing.
Planned v2
Add accessibility and inclusion to Project Intake.
Put success metrics and a baseline beside every goal.
Merge duplicate problem entry fields.
Cover Research and Ship in the Tool Guide.
Send an accepted intake into a component proposal.
Improve placeholder contrast and use one term: user group or persona.
Documented
Propose to Sustain
The path from an idea to a maintained component.
Live prototype
Design Intake Toolkit
A working front door that exports shareable briefs.
Live site
Operations case study
Unified dashboards and standardized reports for system health visibility.
