A focus on community and communication
Through a couple of acquisitions, use of various libraries, and some false starts the Integrate app was a fragmented user experience and badly needed to fresh start.
We have multiple versions of the design system, each with multiple versions of the same component in some cases, and nothing was documented.
Lead Product Designer
Product Manager
Figma, Storybook, EightShapes, Design Lint
Product designers, front-end development team, product managers, feature teams
Strategy, process, management, research, governance, components, support, user testing
Communication gaps previously led to duplicative components, increased design and development time, delays, and missed goals.
By adhering to our operating principle of "people over components," we've reduced misunderstandings, minimized duplicative components, and fostered productive collaboration.
Teams have been creating inconsistent designs leading to a fragmented user experience.
The design system provides a single source of truth and standards ensuring consistency across all product areas.
Development teams often forego building accessible experiences in favor of fast delivery.
With accessibility baked into the components, teams comply with accessibility standards without having to change anything.
Before, the design system existed as a component library, at best.
Working with developers and designers, we created a self-serve documentation template that provides design guidelines, decision trees for when to use which component.
Before designers and developers spent excessive time recreating the same functionality, often with minor differences to the detriment of customers.
Reusable components means significantly less time and effort to design and develop new features.
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.
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.
Ensure that we adhere to the roadmap, but allow for some ad-hoc requests that doesn’t distract us too much from our goals.
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.
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 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.
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.
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.
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.
Gaps
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.
Solution
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
We now have better data to properly prioritize the design system backlog.
Communication Channels
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
We receive questions in an open forum over direct messages, which increases tribal knowledge. Also, we have a much better history log of conversations to feed FAQs and other documentation.
How it works
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.
Deliver at scale
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 deliver components that provide the highest business value and outcomes for customers with less bias.
Addressing skills gaps
We operate under a federated team model where all designers research and build new components. However, not all designers had experience building components, which requires a systems mindset and the skills to create Figma components closely aligned with their coded counterparts.
Figma training
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.
Research-backed use cases
The assigned designer completes desk research that are aligned to product use cases and presents them to the team during weekly meetings.
One potato, two potato…
The design system team works closely with their developer counterparts, who provide feedback and technical considerations. We iterate until we’re happy we’ve met all requirements of the use case.
Outcome and impact
Teams are starting to row in the same direction and we're building a consistent and coherent product experience. Designers are becoming more systems minded. As a result, their feature work has been higher quality with less revisions.
Creating templates
The design and development teams collaborated to create documentation templates that provides self-serve design guidelines and specifications for consumers.
Three potato more
Designers and developers work hand-in-hand to create documentation and user stories that are then decomposed during refinement.
Outcome and impact
We have seen improved team efficiency, alignment, adherence to design standards, and a higher-quality user experience. Design system leadership is fielding a lot less questions. We continue to improve the documenation.
From 30 minute demos to async just-in-time training
30 minute demos are commonplace for feature teams, except that they are often the only ones who attend them. It was critical that we get more eyeballs. I asked our front-end team if they would be open to creating demos that were two minutes or less for each new component and to share it out highly-trafficked communication channels.
Outcome and impact
Feature teams know not only when new components are available, but have digestible videos of the specific component they're implementing. We’ve seen lots of comments and reactions to the videos. Additionally, we’ve also created a Slack channel with an integration that automatically posts whenever there’s a new Storybook release.
Click the expand button to see the image full size.