Design System Contribution Model – How to Set it Up
Navigating design system contribution can be challenging, often demanding coordinated efforts from multiple stakeholders. This article serves as a comprehensive guide, laying down the structured roadmap of a design system contribution model to standardize practices and ensure quality. From identifying key stakeholders to creating an agile workflow for contributions, it covers every aspect, including how tools can boost your contribution process.
Key takeaways:
- A Design System Contribution Model standardizes how new elements are added to a design system, ensuring quality and consistency.
- Governance, versioning, and documentation are essential elements in controlling and tracking the evolution of a design system.
- UXPin’s Patterns feature accelerates the contribution process, allowing quick iterations and real-world testing of new design system components.
Streamline your design system contribution process while bridging the gap between design and development with UXPin’s Merge technology. Visit our Merge page for more details and how to request access.
What is a Design System Contribution Model?
A design system contribution model is a structured roadmap for adding or modifying new elements in a design system. It outlines:
- Who can contribute
- What qualifies for a contribution
- How to go from proposal to implementation
This model standardizes practices, ensuring that the design system evolves in a consistent and controlled manner.
Why Do You Need a Design System Contribution Model?
Organizations use contribution models to overcome the challenges of decentralized digital product development using distributed teams. Design systems often span multiple teams and departments, from designers to developers to product managers. Without a structured approach to contributions, you risk inconsistencies, duplicated efforts, and the dilution of the design system’s quality.
How a Contribution Model Helps Evolve a Design System
The contribution model safeguards a design system’s integrity. It acts as a quality filter, ensuring that every addition aligns with the system’s goals and standards. Setting clear rules and processes helps coordinate multiple stakeholders, thus streamlining efforts and fostering collaboration. This model keeps the evolving design system coherent and efficient.
Who are the Stakeholders in a Design System Contribution Model?
Here are five typical stakeholders for a design system contribution model:
- Designers
- Developers
- Product Managers
- Quality Assurance Engineers
- Stakeholders
Designers
Designers are the primary creators and curators of the design system. They contribute graphic elements, UI components, and layout templates. Their expertise ensures the design system aligns with user needs, style guide, and design language.
Developers
Developers implement the designs into reusable code. They ensure the design system remains technically feasible and efficient, turning design assets into functional components. Their contributions often include code samples, technical documentation, and updates on platform limitations.
Product Managers
Product Managers are the bridge between business objectives and design goals. They prioritize contributions based on project needs, timelines, and strategic alignment. By defining the scope and setting priorities, they control the rate and direction at which the design system evolves.
Quality Assurance Engineers
QA Engineers ensure that both the design and code meet quality benchmarks. They validate that contributions adhere to defined guidelines and don’t introduce errors or inconsistencies. Their role is critical for maintaining the design system’s reliability and integrity.
Stakeholders
Management includes executives and decision-makers who provide the resources and support for the design system. They may not contribute directly, but their approval often dictates the scope and scale of contributions. The design system team must inform and align management to ensure long-term investment in the system.
Examples of Design System Contribution Models
Example #1: Pluralsight
Pluralsight’s design system contribution model employs a structured approach, facilitating bug reporting through GitHub issues and feature proposals via bi-weekly meetups or GitHub.
Contributing code follows a specific guide and demands adherence to coding conventions, thorough testing, and the use of the design system itself in new components.
Submissions go through Pull Requests (PRs), which require review by the Design System team, often involving multiple rounds of feedback. The Design System team prioritizes the review of submitted PRs within a 7-day window and updates affected packages after merging. The process encourages teams to contribute regularly and real-world testing of the newly implemented features.
Example #2: Atlassian
Atlassian’s design system contribution model emphasizes participation and contribution. Participation includes open communication via Slack channels and bi-weekly Design System sparring sessions for robust feedback.
The design system team only accepts specific contributions: code bug fixes, Figma library corrections, and documentation updates. It does not accept small enhancements or major changes.
The restriction on larger contributions is due to the time needed to consider the system-wide impact, but the company encourages engagement through participation channels for ongoing collaboration and support.
Example #3: GOV.UK
GOV.UK’s Design System has a strict contribution model that ensures high-quality components and patterns. Contributions begin with a proposal demonstrating a new component or pattern’s usefulness and uniqueness. Proposals meeting these criteria undergo a review by the Design System working group.
Before publication, the Design System working group scrutinizes the implementation to ensure it is usable, consistent, and versatile based on defined criteria, including user research, coding standards, and versatility across services.
For community resources or tools linked to the Design System, a set of checks ensures it has a clear owner, aligns with the system’s standards, and meets other requirements, including documentation and support.
Example #4: Zalando
Zalando’s design system relies on a contribution model that balances centralized governance with decentralized contributions.
A central team called ZDS mainly maintains the design system and provides standard components and styles to feature teams.
When these feature teams, which focus on different segments of the customer journey, identify a need for a new component or modification, they reach out to the ZDS team. Teams submit contributions, ranging from light (minor tweaks) to heavy (new components), through a Google Form that updates a GitHub board for tracking.
The contribution process is structured and involves multiple steps, including proposal, kick-off, collaboration, and review. ZDS hosts weekly meetings to review contribution tickets and provides “Open House” sessions for in-depth discussions. Communication and collaboration are essential, with contributors encouraged to document everything on GitHub and involve the right stakeholders for effective decision-making.
After ZDS finalizes a contribution, several steps ensure the update is well-communicated and integrated before merging the Pull Request. These include:
- Updating the design system documentation and design files,
- Showcasing changes in a weekly demo
- Sending out email newsletters to keep both designers and developers in the loop.
This holistic approach ensures that Zalando’s design system is consistent yet flexible to the needs of a large organization.
Example #5: Nord Health
Nord’s contribution model balances centralized governance and community input. Product teams can propose new features or design tweaks that fit their needs, while a central design system team oversees the overall direction, ensuring quality and consistency.
The design system team categorizes contributions into light, medium, and heavy. Teams submit their ideas through a contribution ticket that syncs to an issue tracker backlog for review every Monday.
The contribution process involves multiple steps, starting with an initial conversation to understand the requirement and avoid rework. The design system team schedules a kick-off meeting for medium and heavy contributions to finalize the scope and timelines. Nord values collaboration and often pairs its team members with the contributing product team to focus on specific requirements.
Nord provides a comprehensive set of tools and guidelines for contributors, from a Figma Design file and GitHub repository to Slack channels and various design guidelines. These supporting resources facilitate a smooth contribution process and ensure all new additions align with Nord’s high standards for accessibility, usability, and design consistency.
What do you Need to Create a Design System Contribution Model?
Governance: Who owns the design system?
Ownership determines control and accountability. Designate a core team to govern the design system. This team sets guidelines, approves contributions, and ensures the system meets user needs and business goals. Without clear ownership, you risk creating a fragmented system.
Versioning: How to manage updates?
Control design system updates through a robust versioning strategy by implementing semantic versioning to differentiate between minor tweaks, feature additions, and breaking changes. This approach minimizes disruption while allowing the system to evolve and adapt.
Version control prevents conflicts and keeps everyone on the same page.
Documentation standards: What should be included?
Each component or guideline should have documentation detailing its purpose, usage scenarios, and limitations. A well-documented system accelerates onboarding and encourages consistent implementation across projects.
Read this article to learn more about documenting design systems.
How to Create a Design System Contribution Process
The design system contribution process is a structured workflow that guides how team members propose, develop, review, and integrate new features (components, patterns, guidelines, etc.) into the existing design system.
This process involves initial evaluation based on set criteria, an internal review of proposals, a collaborative phase of design and development, and a final review and approval by designated stakeholders.
Here are five key steps of a typical contribution process or workflow.
Perform initial evaluation
- Decide what you aim to contribute–a new UI component, design pattern, or a set of guidelines. Clearly defining the type of contribution filters out irrelevant or redundant inputs right from the start.
- Set rigid criteria for what makes a valid contribution. Criteria could range from code quality to relevance and usability.
- Create a checklist to evaluate contributions quickly. If a contribution fails the checklist, it doesn’t proceed to the next stage. This step saves time and ensures quality.
Make a plan
- Outline the submission process. Use templates to standardize proposal submissions, ensuring contributors provide all necessary information.
- Describe your internal review process, including automated checks, peer reviews, and reviews from governing teams.
Pitch it in a presentation
- Invite stakeholders for a feedback round. This step ensures the proposal aligns with both user needs and business goals.
Design the contribution model
- Clarify the collaboration process between designers and developers. Pinpoint which tools facilitate effective communication and design handoffs.
- Specify the tools and platforms teams must use in the development and design stages. Uniform tools enhance collaboration and reduce friction.
Seek approval
- Determine how many review cycles a contribution goes through and what each process entails. Multiple rounds can ensure rigor but avoid needless complexity.
- State who decides whether a contribution gets accepted or rejected–typically the governance team or a lead stakeholder, maintaining the system’s integrity.
Streamlining Design System Contribution with UXPin
UXPin’s Patterns streamlines contribution by empowering designers to prototype and test code components in the design process. It eliminates the need to develop new patterns and components before testing, letting designers instantly create, test, and share new patterns by combining existing Merge UI elements.
For example, a team working on an eCommerce platform can quickly assemble a new product card for the homepage with updated micro-interactions, use Patterns to save it, and pass it to developers and other designers for immediate feedback and implementation.
This agile workflow accelerates the contribution process, allowing quick iterations and real-world testing. UXPin’s Patterns feature ensures that all contributions are not just theoretical but immediately usable, bridging the gap between design and development teams. By using Patterns, you’re not just contributing to a design system–you’re making it more dynamic, collaborative, and aligned with the needs of your evolving product.
Evolve your design system with the world’s most advanced UX design tool. Visit our Merge page for more details and how to request access.
