Day 2-The Design System Rollercoaster: From Enabler and Bottleneck to Catalyst for Change
— Hi everyone and thanks for joining me today and I’m tuning in from Berlin, Germany
-
Thrilled to be with you riding roller-coaster called the design system
— Why the roller coaster metaphor?
-
Thinking on journey with design system (DS) of team under 10, for 300 people
-
It captures feelings, dynamics, unpredictability of building such a system
— I joined company in transition to be product-led org, focused on predictive maintenance for industrial equipment
— This meant standardizing offerings through early customer projects in 5-7 years and consolidating them to two distinct verticals for the Product IoT platform
-
Needed design systems to serve as a shared baseline
-
Above is a key screen built with it
— On top of baseline, built local library with custom components and patterns, with specific unique use cases like dark mode
— We needed the right process in place for teams during this transition
-
Promise this will be last product page, and we will look beyond tangible parts like UI components, patterns, tokens
— We can define a set of principles guidelines, resources and principles to guide design and development effort for a design system
-
But this leaves out the people and culture around them
— As companies grow with more people functions, silos start to form
— Silos form own tool and collaboration with others
-
Consequence of technical debt and design debt
-
Fragmented experiences
— Frustration builds to point where people give up on using product and services
— But customers rarely ask to fix inconsistencies in the design
-
Focus on indirect indicators, like activation rates, and confusion to people
-
Designers can make surface fixes, but can also stop manifesting deeply rooted issues
— Design systems can help us foster common language across silos and define how groups of people work together
-
This can be done through operational internal comms, collaboration culture, and design and dev process
— More than 65% invested in design system as of 2020, as all companies recognized common language fundamental to collaboration for different teams across countries working for common outcome
— But if benefits of design systems are obvious, why do they keep failing?
— So let’s look at what makes/breaks design system
-
Managing the deisgn system
-
Commons strategies to apply
-
Articulating the value of DS and how it impacts design org
— Four forces pull in their own direction for success
-
Clear objective on why we need a design system in first place
-
A system is not goal in itself, but helps enable things like improving workflows and inceasing a competitive edge
-
Each case is unique
-
— Need sponsorships from senior stakeholders for efforts and initiatives
-
Without commitment, efforts will go in vain
— Even with top blessing, you need buy-in from all corners of company impacted by a design system
— To earn the support we need all impacted parties to see change as beneficial and alignment for high-level goals
— We need to be prepared and learn what peers care about and let’s not forget stakeholders are people with fears and doubts, along with their on goals
-
To read between the lines, we need to build trust and connect on the human level
— Create a master stakeholder map listing out direct and indirect stakeholders and any friction we have to bridge gaps
-
See above the example of this map for product managers
— To get product manager buy-in for our products, we had to create own efficiency case studies for merit of Design Systems
-
Best shot to present with facts
-
Numbers looked better than words
— Finally to function, and help stakeholders. Formalize product and practice with dedicated resources, and a dedicated DS team
-
There is a but to do this
-
For a design system to be a success need equilibrium between all four forces
— As design system lead, you wear many hats from diplomat, architect, facilitator, and everything in between to keep everyone on board and keep the ride going, while staying motivated
-
No one tells you this about the role
— So how do we run the process, or co-create it with others
— DS is continuous process to manage, not a one-time thing
-
Three pillars to keep in mind for this management
— 1. Product: A product to develop and maintain content within
— 2. Service: For consistent experience you need to educate and support internal users, designers and developers
— 3: Adoption and Contribution: Continuous infusion of product use cases, as product evolves
— To do this, we need a dedicated team with enough bandwidth to make this happen
— See example of DS team from maintenance
-
Needed team commitment and centralized team
— We also need to focus on aligning siloed teams into a common goal, by guiding and empowering them
— Design Systems have a unique overview of what each team is doing, and has view of all platforms team is shipping
-
Shown here as colorful shapes
— Keep track of ongoing product requirements and office hours with teams, regular roadmap syncs, couple of weeks and months for now
— Outline all requirements, figure out which ones are limited in time and resources, and implement and co-design outcome with users for these requirements
-
Consolidate mutual needs
-
Make sure people heard
— That way you can prioritize recurring use cases
— Guide teams by promoting shared baseline and vocabulary for consistent interfaces and crafting artifacts from design files to documentation
— Also, it’s a great time to learn what works for users and make processes as usable and flexible as possible, to allow users to modify while staying in boundraries of shared system
— Finally infuse the system with real-life components and patterns and empower users to be contributors themselves
-
You are not builders, but librarians and facilitators
— Hope you now had view of design systems can collaborate with others
-
You can’t inject into process what we don’t have for selves
— Three things for successful implementation culture
-
Chemistry and collaboration between devs and designers
-
Focus on incremental improvements with the system and retrospectives
-
Shared ownership emerges from previous two elements
— So let’s cover what common challenges are and what to do about it
— We are creating conditions to keep it up to data and all forces mentioned
-
Main challenge is lack of knowledge from design systems comes as no surprise
— We can increase adoption through
-
Loud and frequent DS communication by showing all new components and changes made on storybook and platform of choice
-
Can always have dedicated channel for updates
-
-
I recommend road shows for broad audience with regular users
-
Keep sponsors and senior stakeholders up to date
-
Don’t just come to them when you need something
-
— Provide proper onboarding to users or entire teams via workshops or bite-size lessons through internal newsletter or Slack channel
-
We hosted a design system hackathon for good results
— Sometimes things don’t work as expected, so be creative
-
Technical part of team had only one engineer and two interns, with serious consequences for team
— Came up with the design system bootcamp to borrow engineers who could contribute efforts
-
Avoiding being bottlenecks or burning out engineers
-
Great strategy to increase contribution and preserve institutional knowledge
-
Infused teams with our ways of work and collaboration
-
— Finally, see how DS fits into big picture and how it shapes design in organization, and has the ability to trigger positive change
— The nature of the design system’s impact is specific to audience, company, and problem space in question
-
Impact realized through cross-functional work, as impact of design system through adoption, which comes from cross-functional collaboration
— Use captured metrics like
-
Adoption insights
-
User satisfaction
-
Level of system utilization
— Take all insights with grain of salt
— Remember, product success lies in value delivered to users
-
While we focus on metrics, people can still be disconnected from user problem and reality
-
Great design doesn’t happen in isolation and is subject to power dynamics
-
— For design to be valuable, you need outcomes for people to focus on interacting with product to save money
- Marry user needs with business outcomes
— Understand design value and maturity and put on systemic lenses and focus on entire cohort of metrics of the design system itself like
-
How design is integrated in product, or how designer insights influence product strategy
-
Design systems should back the business value of design
— Perhaps, the focus on design’s value is what holds innovation back
-
Reward value means more than monetized value of capitalism
— So how about we focus from financial gains to what drives change and powers excellence and the world itself?
— Let’s start by designing how work and collaboration happen, and what we value
-
Let’s figure out how we connect our dots
— That said, it’s constant change management, of building bridges, raising awareness, and creating space for meaningful conversations
— Can create new paradigms for excellence at multiple levels
— We transcend our individual roles by becoming advocates for higher values, one component, visual element, or rendered intent at a time
— Thank you! Any questions?
FAQ
-
What process or mechanism evolves the design of system efficiently?
-
Different team rituals can be brought together in same room and in areas that can be better, and think about process of maintenance from technical people and always be on lookout for better ways and methods
-
Key to experiment, iterate, and see what works and brings value
-
-
Best way for designers to adopt emerging design system, when it appears as way of working?
-
Bring the designers into the process, and ask them for their input
-
Show them we are here for them and to make their lives easier and better
-
Find common language in process and figure things out together and show that their well-being will matter in requests
-
-
-
How are you encouraging design system consumers to actively contribute to design system?
-
Struggle, as this is a consequence of company culture and silo mentality from company
-
Encourage hybrid for little push and shared agreement and have DS work be part of the OKRs so people contribute twice in a quarter and where facilitator guides the process
-
Have an overview of what each team is working and used by Team B or C and strong case for contribution
-
Hold people by hand until they are ready to contribute
-
Having OKRs as being part of contribution to design system
-
-