Top topics to address when working with Design Systems

Design Systems (DS) enhance collaboration between product design and software engineering teams, driving consistency, scalability, and continuous improvement. However, many senior tech leaders grapple with whether their business truly needs one or is ready to implement it.

At YLD, we have been at the forefront of the DS movement since hosting our inaugural Design Systems London (DSL) conference in 2017. Our expertise spans diverse industries, partnering with tech, design and product leadership to create, implement, and refine DS that address unique challenges and align with organisational goals. 

Building on the success of our DSL conferences, we expanded our community efforts by launching DSL meetups, creating an inclusive community where professionals can exchange insights, share best practices, and drive innovation in design and development.

As YLD’s Head of Product Design, I’ve worked on many high-impact projects such as ASAP, NewDay, and Zego just to name a few, where DS drove scalable, impactful solutions. Hosting the DSL meetups since their inception has also given me the opportunity to collaborate with and learn from many forward-thinking design and tech leaders. 

Making Design Systems work

When it comes to successfully adopting a DS in your business, there are a few topics we frequently encounter both with our clients and the DSL community: Leadership, Team setup, Contributions, Accessibility testing, and Documentation. 

Before diving in, it’s important to note that this article offers high-level guidance and doesn’t cover every detail or provide all the answers. The goal is to share useful insights and practical suggestions to help you approach these topics effectively.

Leadership

1. Aligning leadership:
   Whether the DS initiative is coming from the engineering team or from the designers, true buy-in will not happen without Leadership being on board. Ensure you do the groundwork and be clear with any senior stakeholders on the value and impact the DS will have. some text
   • Business case: Present ROI metrics, like reduced design/tech debt or faster time-to-market.
   • Stakeholder engagement: Involve leadership in workshops or progress reviews on a continuous basis. Regularly send out updates such as weekly emails, or DS Newsletters.
   • Quick wins: Demonstrate value early through small successes.
2. Restarting a deprioritised DS:
   This is something that we have seen on a few occasions wherein a team made their first DS initiative which got deprecated. This can be very demotivating for teams, and it can be hard to get sign-off to either start a new DS, or restart an existing one again, but it can be done.some text
   • Root cause analysis: Understand why it was deprioritised (e.g., lack of adoption, unclear value, lack of resources).
   • Propose incremental value: Show how restarting the DS ties directly to solving current team or business challenges.
3. Meeting business needs:
   This is a key factor in securing leadership’s support, ensuring their commitment, and keeping them as advocates for your DS. To achieve this, we must master the art of “speaking business.”some text
   • KPIs: Align DS metrics with business outcomes like efficiency, scalability, or quality.
   • Feedback loop: Gather input from users and stakeholders to refine the DS continually. 
4. Timeline for DS creation:
   “How long will it take to get the DS?” is a frequently asked question, yet a tough one to answer. The timeline of a DS varies from organisation to organisation and team to team. Design maturity, available resources, level of buy-in and senior stakeholder support are some of the things that will impact the timeline. As a general rule, we tend to work on;some text
   • Basic systems: 6 months for initial MVP (core components, guidelines).
   • Mature systems: 12–18 months for more established, robust, and somewhat adopted systems.
5. “When will the DS be finished?”:
   Key stakeholders or people outside the design and engineering teams often ask this question. It’s crucial to address it even before work begins, ensuring everyone understands from day one what they are signing up for.some text
   • Answer: As a DS is a living product/service that evolves with the business and user needs, the short answer is “never.” However, the effort required does decrease over time, especially if the groundwork is done properly.
6. Non-designers in Figma:
   I personally don’t mind non-designers having access to Figma files, as long as it doesn’t become a “free for all” that impedes or blocks the work. Be clear on what they have access to, and consider:some text
   • Controlled access: Provide view-only access or limited editing rights for specific purposes.
   • Sandbox: Create “safe spaces” where non-designers/stakeholders can play around without jeopardising the DS team’s work. 
   • Templates: Create editable templates to avoid misuse.

Team setup

There are several models for managing a DS, but whichever one you choose, ensure it aligns with the organisation’s ways of working, and that everyone understands their role and expectations.

1. Running DS in a distributed model:some text
   • Shared Ownership: Use a central core team for governance, with squad representatives responsible for maintaining components.
   • Clear Guidelines: Define roles, responsibilities, and contribution processes for distributed teams.
2. Managing DS with fully distributed teams:some text
   • Collaboration Tools: Use Slack, Jira, and Figma for communication and coordination.
   • Syncing: Regular sync meetings to align goals and address issues.
   • Documentation: Maintain a robust, easily accessible repository.
3. Collaborative management:some text
   • Shared governance models can work with distributed design teams if there’s a strong central framework.
4. PO/PM collaboration:
   I am a strong advocate for involving POs/PMs from the very start, as they, along with their dev teams and delivery timelines, will eventually be impacted by the DS. The sooner we can get them on board, the better.some text
   • Advocacy: Show how the DS aligns with product goals, how it can help increase velocity and shorten development times. 
   • Decision-Making: Involve PMs in roadmap prioritisation to ensure alignment with business objectives.

Contributions

Imperfect contributions are better than no contributions, as they demonstrate engagement and a willingness to participate. With the right support and guidance, we can easily improve upon them.

1. Ensuring high-quality contributions:some text
   • Contribution guidelines: Create clear, accessible guides outlining standards, processes, and approval criteria.
   • Peer reviews: Establish a system of design reviews for designers and code reviews for developers.
   • Onboarding sessions: Host training sessions on how to contribute to the DS. Record them so others can take part in them later. Also, consider creating short “How to” videos. 
2. Maintaining standards and consistency:some text
   • Governance framework: Set up a team or working group responsible for governance and quality checks.
   • Tooling: Use linters, style checks, and visual regression tools like Storybook and Chromatic.
   • Component audits: Regularly review and refactor components to maintain standards.
3. Code-related contributions:some text
   • Documentation: Require detailed code comments and updates to DS documentation.
   • Reusability: Ensure components are built with extensibility and scalability in mind.
   • Testing: Include unit tests, accessibility tests, and compatibility checks for all contributions.
4. Managing iteration vs. robustness:
   Success comes with solid foundations and a stable framework, but sometimes the right way in the moment is "quick and dirty”. We need to be sure when taking this approach, we always ensure that we go back and fix any shortcuts when there’s more time. some text
   • Dual track development: Allow for rapid prototyping in a “sandbox” environment while maintaining stricter standards for production-ready components.
   • Versioning: Release iterative updates in stages and deprecate unstable components once mature alternatives exist.
   • Roadmap Clarity: Define which areas demand long-term solutions versus short-term fixes.

Accessibility testing

Testing is incredibly important, and there are many things to consider to ensure it is done correctly. For this blog article, I’ll briefly cover Accessibility as that is something that comes up frequently. 

• Accessibility and Component testing:
  Always make sure that accessibility is a part of the end-to-end process from day one so it doesn’t become an afterthought. some text
  • Practices:some text
    • Include accessibility checks already in the design stage.
    • Incorporate accessibility checks into CI/CD pipelines.
    • Use real-world screen readers during testing.
    • Using AI can Improve accessibility compliance while reducing manual testing efforts, but always make sure to have human sign-off. 
  • Lessons Learned:some text
    • Early involvement of accessibility specialists (where possible) prevents rework.
    • Regular audits ensure long-term compliance.

Surveys

Surveys are a great way to reach out to a lot of people quickly, but it can sometimes be hard to get teams to actually respond to them. 

1. Getting designers and engineers to complete surveys:some text
   • Clear purpose: Make the survey’s purpose clear and tie it to actionable outcomes (e.g., “Your input will shape future DS features”).
   • Personalise invitations: Address them directly to people and explain how their role benefits from participating.
   • Short surveys: Keep surveys concise (5-10 minutes max) with a clear progress indicator.
   • Incentives: Offer small rewards, like a shoutout, early feature previews, or other motivators.
   • Timing: Send surveys during less hectic times and try to avoid product launch periods or major deadlines.
   • Leadership advocacy: Have senior leaders emphasise the importance of participation - ask them to give the survey a shoutout in team meetings or include your link in team communications.
2. Questions in Usability and Discoverability surveys:some text
   • Rating/scale: Use Likert scales (1–5 or 1–7) to assess satisfaction, ease of use, and discoverability.
   • Written feedback: Provide optional open-ended questions for qualitative insights, e.g., “What’s the most challenging aspect of finding components?”
   • Example questions:some text
     • Rate the discoverability of components in the DS repository.
     • On a scale from 1–5, how intuitive do you find the documentation?
     • Are there gaps in the DS? (Yes/No) If yes, describe.
     • How often do you reference the DS weekly newsletter/update etc.?
     • Suggest one improvement you’d like to see in the DS.
3. Avoiding survey fatigue:some text
   • Prioritise surveys: Align surveys with project milestones or specific team needs.
   • Frequency: Limit surveys to once per quarter unless critical.
   • Combine efforts: Consolidate questions into fewer surveys rather than spreading them across multiple ones.
   • Pre-validation: Test surveys with a small group before wider distribution to ensure relevance.
4. Sample size:some text
   • A good sample size depends on the team’s size:some text
     • Small teams: Aim for 70–80% participation.
     • Large organisations: A sample of 20–30% of your total target group can suffice if distributed across roles.
   • Focus on gathering input from key users: power users, occasional users, and contributors.
5. Tools for data collection:some text
   • Survey tools: Google Forms, Typeform, SurveyMonkey or Microsoft Forms are just some example tools to use for surveys.
   • Ongoing metrics: Use tools like Hotjar (user engagement), Amplitude (analytics), or internal dashboards for adoption metrics.
   • Making metrics actionable:some text
     • Trends: Track recurring pain points or drop-offs.
     • Impact: Tie metrics to business or project outcomes (e.g., faster design cycles, fewer support tickets).
     • Feedback loop: Regularly share survey findings and action items with the team.

Documentation

Documentation is a vast topic, and there are many ways to approach it. Whether you use a design tool like Figma, a DS integration tool like Zeroheight, Supernova, or Knapsack, or a developer tool like GitHub or Storybook, the key is to find the tool that works best for your team and organisation and fits with your team’s ways of working.

1. DS Documentation:some text
   • Storybook: Common for developers to view live components.
   • Supplemental tools: Include Notion, Confluence, or markdown-based documentation for higher-level principles.
   • Content: Combine component usage guidelines, design principles, and coding standards.

Design Systems: Building bridges to innovation and scalability

Design Systems are transformative tools that bridge the gap between design and engineering, fostering consistency, scalability, and innovation. Yet, they also require strategic foresight, leadership buy-in, and meticulous execution to deliver their full potential.

Whether you’re starting fresh, restarting a DS initiative, or refining an established Design System, the principles shared here provide a foundation for success.

Bear in mind that a Design System is never “finished.” It’s a living, evolving asset that grows alongside your organisation’s needs and ambitions.

If you’re looking for further guidance and insights on Design Systems, product design, or software engineering, get in touch with us to discuss your project. Additionally, you can dive deeper into our past conversations on all things Design Systems by visiting our YouTube channel.