Design system operating principles
I facilitated workshops to establish design system operating principles prioritizing community and use cases over "snowflakes."
Outcome and impact: This approach led to less rework, streamlined decision-making, greater team alignment, and consistent product experiences.
People over components
Components don’t solve the complex problems that help our users. People do. If your design systems team is not building relationships with the folks using the system, then you can’t ensure that your components and tooling are solving their needs.
Stay focused
Ensure that we adhere to the roadmap, but allow for some ad-hoc requests that doesn’t distract us too much from our goals.
Prioritize the mundane
Design systems are containers for institutional knowledge. Identify the design problems teams confront over and over again. The more common the problem the better. Design systems should prioritize the mundane.
If you look at the stuff that a design system consists of that comes out of the piloting process, it’s all the boring stuff, the elements you don’t ever want to be making over and over again: paragraphs, check boxes, radio buttons, alerts buttons. See source.
Allow for luck: frameworks over processes
Where processes don’t do well, as luck is involved, frameworks are a handy tool instead. A framework gives us a supporting structure that luck can flow through.
Use cases over the abstract
Stop trying to make a design system by making abstract components. Instead, give your team a use case. New components ought to be tied to a verified at least 3 use cases.
When design system work is done in a vacuum and a design system team doesn’t have specific use cases, their strategy seems to be something akin to “let’s provide as many elements as product teams might need at any point,” leading to bloated design systems.
Allow for innovation by following the Pareto principle
Use the Pareto principle—often known as the “80/20 rule”—to set an actionable target for teams: aim for up to 80% of any given page to be made of design system components and leave room for about 20% of the page to be custom. That remaining 20% is where the invention and innovation can happen.
Some organizations seem to strive for an ideal that, once a design system exists, everything in an interface can and should be built with it. Not only is that an unrealistic goal for most enterprises, but it can often be a toxic mindset to think that anything less than 100% coverage is a misuse of a design system at best or an utter failure at worst.
- Effect: Designers are happier and, more importantly, and are capable to solve user needs.
- Measure of success: 80% design system coverage percentage of a page.
See source.
Embrace the hot potato process
Engineers need to spend less time waiting for “the design phase” to end to start building. Designers need to create fewer static comps. Restricting these wasteful activities frees up more time to do many more valuable things.
Document as you design
Every good design system has guidelines, suggestions or rules to follow for how to best use any given design system. Good guidelines tell you what and what not to do. Design system guidelines often take the form of principles or user experience best practices.
The best guidelines help designers and engineers at the point in their work where they need it, often called "just-in-time" documentation.
Governance: a contribution framework for determining if, when, and who should build components
The framework was built after researching several excellent examples from the Web, then layering Integrate’s process along with a new intake process. The design system governance framework outlines design system entry criteria, process for requesting components (or build snowflakes) to foster collaborative efforts to help manage and evolve the design system over time. The primary goal is to streamline communication and collaboration. Finally, we documented who is the decision-maker, depending on the use case for incoming requests.
Outcome and impact: We’ve seen improved team communication, reduced instances of duplicate components.
Click the expand button to see the image full size.
Self-serve service desk and intake process
Implementation teams often recognized that something should be a component but didn't know how to request one, leading to numerous repeated one-on-one conversations in Slack. Additionally, prioritizing the many questions and requests according to need was challenging.
To address this, we built a new Atlassian self-serve service desk and intake process to track system requests. We incorporated triage into our daily standup to discuss bugs and prioritize new requests, then communicated decisions back to the organization.
Outcome and impact: better data to properly prioritize the design system backlog.
Open forum for questions
We also established company-wide Slack channels for the design system and snowflake components, providing a centralized location for team members to ask questions. Frequently asked questions are documented in a Confluence FAQ for easy reference.
Outcome and impact: less 1:1 one-off conversations and more people contributing to design system questions; everyone has a much better idea of incoming requests.
Communicating releases
I asked the design system implementation team if they’d be open to creating quick demos that were two minutes or less for each new component and to share it out on all of our communication channels. They agreed and as a result, we’ve seen lots of comments and reactions to the videos.
Additionally, we’ve also created a Slack channel with an integration that posts whenever there’s a new Storybook release.
Outcome and impact: implementation teams know not only when new components are available, but have digestible videos of the specific component they're implementing.
Backlog and roadmap
Service desk tickets have enabled us to efficiently track multiple requests for the same components within a release cycle, create a prioritized backlog, and develop a roadmap that is in sync with all product roadmaps to build components aligned with the company's strategic priorities, enabling implementation teams to deliver features at scale.
Outcome and impact: we're able to deliver components that provide the highest business value and outcomes for customers with less bias.
Documentation: a single source of truth
I collaborated with our development team to create a design system documentation template that provides self-serve design guidelines and specifications. As a result, we have seen improved team efficiency, alignment, adherence to design standards, and a higher-quality user experience.
Outcome and impact: design system leadership is fielding a lot less questions and we've identified how we can improve the documenation.
Figma training
Given the small size of our design team, we operate under a federated team model where all designers research and build new components. However, not all designers have experience with design system work, which requires a systems mindset and the skills to create Figma components closely aligned with their coded counterparts.
To address this, I drove a series of training sessions that up-skilled designers in design system and Figma best practices that resulted in standardized component architectures and a streamlined designer/developer workflow experience.
Outcome and impact: designers are learning new skills and becoming more systems minded. As a result, their feature has been higher quality with less revisions.
Building components
Integrate recently made a couple of company acquisitions, resulting in multiple codebases. This led to several false starts with the design system, creating multiple versions of several components. To stay competitive in the market, we consult with product and engineering teams when redesigning both old and new components.
A robust design process is essential for consistency and competitiveness. Here’s an example of our typical design process, largely inspired by the great site.
Outcome and impact: teams are starting to row in the same direction and we're building a consistent and coherent product experience.
