Design Systems and Agility (Part 2 of 2)
Extended from my recent talk at UX Australia Conference #UX2018, part two of Design Systems and Agility
This is the second of a two part series of articles created to support my thinking on Design Systems and Agility, as presented in my talk at UX Australia this year. The purpose of this Part Two is to discuss and show the results of a survey live the weekend prior to #UX2018. This is a long article so I’ve added in an ‘Abstract’ in the next section to summarise key findings.
There is a great deal of excitement around design systems in the design community. Everyone is saying we need a design system, but why do we? What is the value for designers, teams and organisations?
I felt it would be valuable to create a preliminary survey to industry to help establish a light-touch benchmark on the current state of design systems. People who contributed to the survey included members of the design community, as well as other adjacent functions who help designers build systems as well as endorse and collaborate with us, including as product and engineering team members.
The survey, titled “How do you interact with design systems?”, was set up to establish some evidence around the use of design systems in industry, to share stories of other people sharing the same challenges, as many designers are now, and to help focus us as a community on next steps for discussion.
Even though I have had my own experience with creating, maintaining and interacting with design systems in various scenarios and contexts, as a design practitioner, researcher and humanist, I couldn’t resist asking others about their thinking, too. As most of us would agree, one participant isn’t enough to create deductions and most organisations are organised and operate differently on a case by case basis.
The focus of the survey questions is across design systems development in design, product and technology teams. Or things happening around the design system itself. I sought to understand how these design systems relate to individuals, teams and organisations.
Abstract: Key Takeaways from the Design Systems Survey
In case you don’t have time to read this entire article, here’s a wrap up of key takeaways. Design systems:
- Increase team productivity significantly, aiding speed to value and first in market approaches;
- Provide designers and their teams time to problem solve;
- Benchmark usable, accessible interfaces and interactions with reusable components if supported with best-practice front-end engineering and design practices;
- Should be incepted by running an experiment or service design approach first (research, discovery and testing) to understand use-cases, risks and opportunities in their development;
- Are aided by an associated style guide and playbook for users of the system within teams in the organisation;
- Ensure consistency, which is perceived as king and is considered essential for teams and improving the user experience of products and services;
- Originated with a service design approach, aids in originating, maintaining and increasing user adoption of the system itself;
- Decrease rework and waste, as well as mitigating unnecessary design system effort and legacy;
- Need support as inception, maintenance and adoption is a pain point;
- Have the power to be user and human-centered;
- Require teams to be flexible and allow co-ownership of the system across functions and teams in a way that makes sense for your organisation;
- Are valuable to teams both in Agile and Waterfall delivery contexts; and
- Aid collaboration and reduce friction in team decision making.
The Survey, Recruitment and Participation
The survey consisted of twenty questions about design systems, the people who use them and their teams. The objective of the survey was to gather a sample of data to understand the current state of use, expectations and perceptions of design systems in industry today. The survey statement inferred my intention to understand how design systems are currently interacting with people in companies with both established and emergent design systems. The supporting explainer of the survey was:
“A short survey to help us understand your experience of design systems in your working life.”
Survey recruitment was conveniently sampled via the my social networks, via Slack communities, LinkedIn and Twitter. The data collection was live for two weeks, for one week before and one week after #UX2018 but promoted over twenty-four hours. Thank you to any connections who retweeted the survey link, truly appreciated.
At the #UX2018 conference, a sample of the data was presented and had been through a first round of synthesis. The presented information was based on a population of twenty six participants. When finished, the survey data consisted of a total of thirty four responses, from a range of people in the design and technology industry with a range of role titles.
Organisations Represented and Geographic Regions
I received a range of responses from different regions including Australia and possibly New Zealand, as well as the United States and Europe. Some really amazing and well known businesses were represented, some with publicly applauded with established design systems as well as younger emergent ones. Data has been de-identified and will not be disclosed though due to an agreement provided to those who submitted their information.
Thank you to any friends who helped with this survey, and those who I don’t know super well, I’m truly grateful for your participation.
Role Titles
Titles of people who participated in the survey included; Visual Designer; UX Designer; UI Designer; UX Engineer; Front End Engineer; User Researcher; Product Designer; Product Manager; UX Manager; Design Systems Lead; Interaction Designer; Director, UX; Engineering Lead; UX Specialist (UX researcher, designer); and UX Strategist.
52.9% of participants who contributed to the survey said their role title was ‘UX Designer’ (18 participants). The second largest group, at 14.7% of participants, said their role was ‘Product Designer’ (5 participants).
Although UX and Product Design were the roles most represented in the survey at approximately 68% of the 34 participants, functions were represented across many facets of design, as well as engineering, product management and design leadership roles.
Responsibility Sets
Participants were then asked, “Are you responsible for design, user research and/or user testing in your role? Choose the options that apply.”
The answers to the survey showed that of most of the participants, in their roles they had multiple responsibilities. Individually their responsibilities were distributed across the main UX and Product Design discipline ‘verticals.’
These verticals were consistent with the dominant ‘trifecta’ of UX deeper T skill categories, including:
- Design (execution): 91.2% (31 responses)
- User Testing: 88.2% (30 responses)
- User Research: 85.3% (29 responses)
Remaining single participant feedback came in at the following individual sets of responsibilities, as specified by the participants themselves under the alternate ‘Other’ category:
- I do participate in them but am not responsible: 2.9% (1 response)
- Development: 2.9% (1 response)
- Design team documentation: 2.9% (1 response)
This information showed, overall, that the many individual participants who contributed information in this survey undertake at least two specialist areas of responsibility within their roles, if not three, as part of their day job.
The dominant case is that for at least 31 of 34 participants their primary responsibility is design (execution), combined with user testing and/or user research. For most of the 31 participants who undertake design execution in their day jobs, 29 are responsible for all three types of tasks, including user testing and user research.
Let’s not jump the gun, but it looks like our designer participants are potentially quite busy with more than one focus. Not only this but they need to juggle these focuses across a day, a sprint or initiative.
How might design systems make it better for all of us, to give us the space do all the things necessary to create better experiences for both ourselves as team collaborators and the users of our products, systems and services?
What is the Purpose of a Design System?
In the next section of the survey, participants were asked, “What do you believe a design system should do?”
Key themes that emerged were as follows:
- Collaboration, Efficiency and Alignment
- Focus Time for Bigger Problems
- Interaction Design over Visual Design
- Consistency, Scale and a Source of Truth
- Ease of Use, for All
Collaboration, Efficiency and Alignment
Collaboration between team members was mentioned as a focus for many of the designers who participated in the survey. Many felt this was a positive or aspirational effect of what a design system should do.
Design Systems should: “Enable our teams to move faster through the design & development process. With a design system in place, our designers can spend energy solving bigger problems than creating new design patterns. Additionally, Product Managers should be able to graph wireframes, knowing that we have patterns already for how certain features or interactions work. This allows them to move faster.”
In the above scenario, wireframes are no longer the exclusive domain of UX Designers but anyone in the team. Other use cases for collaboration and alignment being important via design systems being established included; “Consistent design patterns and informing appropriate usage,” “Provide a framework for collaboration and consistency” and “Establish quality and create a unified voice and point of view.” Quality was considered by some participants as part of the creation of standards and best practices in not only the system itself and interaction design but also accessibility and usability.
Design Systems should: “Align best practices incorporating accessibility factors, usability and align teams to produce high quality, cohesive products.”
Participants also talked about scaling the system based on collaborative decision making; “Set global styles and patterns on shelf for your product to grab when designing anything new. It should also be extendable so when new or nuanced scenarios arrive, your team can add to the guide.”
Focus Time for Bigger Problems
For designers, managing their tasks and efficiency, economy and ease of use in relation to a design system being implemented was raised as an important factor: “With a design system in place, our designers can spend energy solving bigger problems than creating new design patterns,” and, “They should aid a designer’s creativity, as the focus of their work shifts to Design Thinking instead of pixel-pushing.”
Design Systems should: “Provide designers with a set of validated & well thought out components and guidelines they can use to solve diverse problems across product(s), in a consistent way.”
Additionally, design systems, many participants concur, can only be defined as ‘good’ if they have been user tested.
In my experience, design system ownership, once productionised into code, is only powerful if the ownership of the design of the system itself makes a case for human or user-centered design approaches and continuous improvement methods. For something new or for a change to be inducted into system requiring additions and/or innovation an experimentation cycle must occur. For example, a new pattern should be usability tested in situ to all affected contexts, or a a new flow or user journey should be fully prototyped and tested for down stream system effects and dependencies before being inducted into the system.
Interaction Design over Visual Design
Interaction design in software is set in the context of complex adaptive systems (CAS) eg. considering states, conditions and variables. Design systems are perhaps the answer designers in technology have to deal with the complexities of multiple CAS, their actors and their environments. Responses to what design systems should do indicated that interaction design has a bigger part to play than visual design alone.
A priority of focus on Interaction Design over Visual Design makes absolute sense in the context of moving parts and complexity. Participant comments included; “Less focus on cosmetics, more focus on interactions,” and, “A grouping of elements together to create a greater whole. Gestalt, the whole before the parts.”
Consistency, Scale and A Source of Truth
For some participants, the perception of a design system was as an enabler to teams and efficiency. Additionally design systems are perceived as an enabler of consistency in the interface and user experience. With reference to patterns, scale and team conversations, the design system is an enabler and aa source of truth for the following reasons, because it:
- “Establishes consistency in design patterns, both design and front-end wise”
- “Creates a scalable system that is maintainable”
- “Guides better conversations between design and development”
The latter point was fascinating, given traditional tensions in engineering around design decisions in the interface and feasibility versus perceived desirability. Additionally, in relation to the prior commentary on best practices and validation this forces the point. Nothing can be admitted into the design system without the due protocols. However there is a risk here around ownership, and who owns the design system. Is it design, product, engineering or all actors in the team that interacts with the system?
Design Systems should: “Give structure to ambiguity.”
Ease of Use, for All
Making interfaces more learnable for users and easier for the designer, and their teams, to execute design efficiently and easily sounds like win, win, no?
Participant responses on this occasion covered both sides of the system image; from process, “Make things easier — speed up the process of development,” to the job of the designer, “Make my job easier,” to the perceived benefit for users additionally, “Easier for the user to learn and use.”
The above comments do not infer that the designers or participants in the survey regardless of role wish to loosen their grip on great interface design. Let’s be sure about that. Their responses are about improving the process of delivering great products and services via standardisation.
Read Part 1 of Design Systems and Agility for more information around the setting for design systems, CAS and why design systems appear to be so important in our current state of work, particularly in design operations, technology delivery and team collaboration.
The first questions in the survey relate to perceptions of design systems in industry.
The subsequent questions relate to experience and evidence based responses regarding how design systems interact with teams in participant environments.
Does your Team Need a Design System?
In the next section of the survey, participants were asked, “Do you believe your team needs a design system?”
Overwhelmingly, the answer was, “Yes.”
In a similar vein to the prior question around what design systems should do, key themes that emerged were as follows, to support why participants felt their teams needed a design system:
- Consistency and Coherence
- Better Communication Between Functions
- Adaptability
- Maturity as a Dependency (of the Design System Itself)
- Increased Efficiency and Speed to Market
Details of each of the above, in relation to why participants felt their teams needed a design system, are listed below:
Consistency and Coherence
The value of a design system, for a team, is the system as an enabler for clear, thoughtful decision making in the interface and experience.
Why my team needs a design system: “Not only for consistency of experience across the product, but to help ensure product teams are thoughtful about what new components they introduce and the scalable value they bring.”
Better Communication Between Functions
Functional ‘bumps,’ as some might put it, happen often in teams with cross-functional members. As users of systems we are designing with, it makes sense to improve the communication around as many decisions as possible. After all, many rituals via Agile and Lean approaches are instated in teams to help minimise duplication, improve communication and collaboration. Therefore design systems are considered by some participants as a communication tool:
Why my team needs a design system:“There is a bit of friction between design and dev, and a design system would help guide conversations “
Additionally, the system itself presents a benchmark to the team around how to articulate information in the interface more efficiently, eg. How might we display this information, with an existing pattern, view or flow, or is a new interface/interaction required to be tested in order to validate user responses prior to funding work in production/in the code base/in the service/in the real life experience?
Why my team needs a design system: “It will help inform every design iteration we work on”
Adaptability
Not every team or team member enters an organisation with context and for many designers and/or teams this can create pain points.
For external agency teams, for example, or freelancers, the non-existence of a style guide can hold up productivity and prevent the team from running from day one. This is not a dissimilar problem for designers in in-house teams either, who I often have observed peddling double speed to create a design system in parallel to the initiatives that they are running.
A design system can be a great way to onboard new team members into the eco-system they are serving and set them up, as users, to run fast, rather than to move slowly.
On the bright side for agencies, but perhaps not so much for the organisations or in-house teams they are serving, a business opportunity might present itself in the creation of a style guide in addition to the design system it supports.
Why my team needs a design system:“We are consultants that must adapt to different client needs/ style guides”
A pain point here for the organisation is that creating a new style guide to support a design system a) costs more money and b)may happen in isolation away from in-house teams or create duplication across the business. Sometimes however , if you are an in-house design entity, this may be the best way to spin up a design system quickly with a third party vendor, rather than your own team that may be struggling to get the support and time to do it in-house. The point being you need a dedicated way of creating a design system if you are considering working on this in-house eg. create a team or custodians of the system. This can be done via dedicated resources or a guild.
Maturity as a Dependency (of the Design System Itself)
A point made by some participants regarding design system maturity as an indicator of teams and design maturity in the organisations the systems themselves serve was particularly interesting! The nature of software delivery and many teams means that if there is a universal system, naturally things will be in and out of sync. Teams will be faster and slower, adoption will be higher or lower depending on who’s in the mix and how the design system has been rolled out.
Part of this might be to do with the nature of the system and how the organisation ‘gets it’ which is why I mentioned, very hurriedly in my ‘tiny talk’ at #UX2018 that if you have a design system, it’s highly likely you may also need a playbook. Additionally you will need a community around the design system and eventually, it may be that you will need to scale work systems processes around the system to get it to work.
Why my team needs a design system: “Because we have different levels of maturity and a flexible design system can provide some clues. As long as it doesn’t become design by numbers”
Increased Efficiency and Speed to Market
Consistency was repeated frequently by participants in the survey. However, the causation of the mention is not just about the interface. Commentary form participants related to the impact of researched, benchmarked and tested interface decisions within the design system on the decision making for the teams themselves. For many participants, it’s about the system as translator and the universality of the system. Let’s not forget consistency around interfaces though too and the impact of system ubiquity eg. omni-channel experiences and the problem of parity across multi-device contexts.
Why my team needs a design system:“We are terrible in delivering consistent experiences. Our products doesn’t feel like the same company built them” “Consistency is key to ensure the user doesn’t see the internal silos of your company :)”
One can understand why ‘bootstrapping’ with Lean Startup approaches and off the shelf open sourced frameworks such as Twitter Bootstrap has been so popular for startups. Not only is there a way to do ‘design’ quickly but the out of the box framework provides a means for a small entity to maintain consistency, increase efficiency and speed to market once value is established in market. And this works for enterprises too.
Why my team needs a design system: “I worked in an enterprise software company for 6 years. A design system completely revolutionised my team’s ability to focus more time on innovation and less on reinventing the wheel every project.”
Design Systems as an Enabler to Better Working Approaches for Designers and Their Teams
Participants were asked, “How do you believe a design system might help you in your work?”
The participant responses were affirmative that design systems are perceived to be helpful. Participants explained various value that could be derived for teams from a design system:
- Improved Team Interactions
- Work Efficiency, Lessened Cognitive Load
- Benchmarked Standards and Visibility
- Onboarding of New Team Members
Improved Team Interactions
Participants mentioned that a design systems could lower friction in their team’s communication and working practices. An orderly design system might help engineers understand the logic of the front-end relating to interface and interaction design decisions. Team members could have the freedom to effect change in the system in a way that collaborative decision making is necessary creating consistent guidance to the team on patterns and interactions. Additionally other functions such as marketing or sales can interpret the design system into their own conversion and purchase funnels if peripheral to areas such as the core product engineering technology stack, service engagement verticals in the broader system.
Why are design systems helpful? “It has made us faster, more consistent and shifted the focus of conversations to be more objective”
Work Efficiency, Lessened Cognitive Load
Survey participants frequently return to time as a benefit as well as attention to problem solving, as a helpful effect of establishing a design system with consistently used patterns. They also considered the users’ cognitive load with comments relating to the consistency of the experience and less unnecessary differentiation in the design across the front end.
The benefits also extend to process efficiency, in that high fidelity prototypes and experiments might be created in code with system components already created in front-end service architecture. The barrier to communication is lowered for team members such as engineers inheriting design specifications in that the design system may also have a representative style guide that can be used to communicate decisions around what to use and in which context to use it to afford quicker design decisions within the team, then enabling faster execution by engineering team members.
Why are design systems helpful? “I can spend less time designing smaller parts of the experiences and reuse existing design decisions, which allows me to focus on the bigger problems our customers are facing.”
Benchmarked Standards and Visibility
Visibility is important in many contexts, from Agile walls to Design Systems. How might a design system be visible? Visibility of a design system, if productionised in front-end architecture, may not be enabled to all team members without a style guide. An alternative might be to create the component visibility in the design software library using ‘symbols’ in Sketch or other devices based on the ‘source of truth’ for a design system. An early stage design system could simply be an audit in the form of a paste up, where all design system components are grouped on print-outs on screens on a wall.
Why are design systems helpful? “Design systems help reconcile our interfaces, make design frameworks visible, components visible”
So there is a dependency on design system fidelity, in how a system can be made visible. Therefore, for many participants in the survey, a design system is standards made visible and benchmarked across system interactions and visual components presented in a single artefact group that can be consumed by users, the team, to make better design decisions.
Why are design systems helpful? “Collaboration tool, consistency, provide structure and a tool to scale with”
Onboarding of New Team Members
Participants mentioned it was helpful to have a design system to get started more quickly and provide a catalyst for design decisions in teams. Onboarding team members or new people into the design environment was a significant benefit. Automation of process around how team members access the system, contribute, push to and pull from the system presents additional opportunity, to enable better get up and go for anyone using the system for the first time.
Why are design systems helpful? “So we are not always starting from scratch but following a previously laid out path”
Overall, Design Systems are about enablement, communication and scale. Not reinventing the wheel over and over again.
Another interesting outcome was around design community alignment. Participants touched on the ability to utilise a design system within the community of designers to create a benchmark and align other design team members to a process of agreement. Potentially, additionally, design systems can be used to layer constraints and identify opportunities across practice for design system development.
Why are design systems helpful? “To align practices”
We know that as design systems mature, there is a chance that artificial intelligence might help us evolve them or even suggest suitable interactions and design patterns for new use cases as well as relatable ones, providing us with more opportunity to query the way we define problems and the solutions we deliver.
Teams and Design Systems
In the next section of the survey, participants were asked, “Does your team have a design system?”
While almost half of participants said they do, a quarter said they didn’t have a design system. The answers in the ‘other’ category, that also consisted of one quarter of participants, were quite revealing.
Answers to ‘Other’ included the following themes.
It’s in progress
- “It’s in progress. Parts are usable as is others aren’t and can hold up development if used”
- “It’s in the making”
- “Working on it”
Needs funding or support
- “Nearly there a half created one that needs more buy in and resources to work together on”
- “Sort of. It’s rudimentary at this point, but we’re working on it”
Not exactly a ‘design system’
- “We use a modified version of an existing design system that came with our platform”
- “Yes but it’s a living style guide — more developer focused”
- “Kind of. I won’t call it design system because the process of creating it was based on one product”
Many ‘other’ answers related to information in the next section, talking about the challenges of design system persistence. As you can see from above, the comments relate to an emergent design maturity. Many organisations either have a design system or are starting to build them. However what a design system should be, why is best for their practices, organisations and teams, and how the the design system should co-exist and be utilised is still being matured. No doubt participants who said ‘yes’ to having a design system share a similar status. Maturity and knowledge is still being established in the design system space to articulate these ideas more clearly.
Design Systems Present Challenges
After being asked if their teams have design systems, they were then asked, “What has your experience been in starting/maintaining the design system?”
The general consensus is design system inception and management is challenging, difficult and requires wrangling to get it right. The themes here from participants are:
- Getting a Design System Started, Adopted and Maintained is Hard
- Design Systems Need Service Design
- Ownership Needs to be Defined
- Every Organisation is Different
- The Threat or Opportunity of Automation
- Documentation and Support is Needed
These themes are explained below, in the next few sections. I’ve included many verbatim quotes here as the information on learning will be useful to many in industry who are reflecting on how to solve for the ‘Design System Adoption Problem’ now.
Getting a Design System Started, Adopted and Maintained is Hard
Some participants said getting a design system up and running wasn’t difficult which demonstrates some maturation in design system adoption across businesses. Positive news for all advocates of design systems out there and great for anyone who is struggling to find time, funding or support for the inception of a design system in their organisation.
Starting/maintaining a design system: “It took considerable effort to establish, but has got its own momentum now and buy in across the team”
However the data of the survey shows serious pain points for many participants. These pain points are oriented in the culture and maturity of the organisation, the use of the design system and the culture around the design system itself.
Starting/maintaining a design system: “Easy to start when the team is immature. Difficult to maintain flexibility in it as the team advances — can become a bit of a cult”
The reference to cult-ism is reasonable. Aforesaid friction around ownership and the ‘source of truth’ was raised in the survey data. The emergence of design ops is a new movement and is now providing designers with the leverage to operate not as a creative peripheral function but a business unit that does things of value. However cult-ism in ownership is something different else, and we may need to resolve it to enable design systems to succeed and benefit our teams.
Return on investment is difficult to establish in a business case without retrospective findings as mentioned by some participants as well, which also supports the rise of design ops and business orientation in design functions; “Trying to get it started has been hard amongst the business they can’t see immediate return.”
The solution to this ROI problem might be via surveying/interviewing the users of the system eg. the teams and organisation. In order to work out the way productivity might be enhanced, a suggestion would be to treat the design system like any other initiative. Perhaps run a lean experiment with a system for one initiative etc to establish value rather than move forward with no data or learnings to support.
Starting/maintaining a design system: “Starting and maintaining systems is life, it is hard”
The next verbatim participant feedback demonstrates again that while the decision to start a design system may not present huge difficulty, the reality of building and owning a design system product and service requires much more attention. Much like a product or service initiative, with design systems there are trade-offs too:
Starting/maintaining a design system: “Pain. We tried to incorporate the design system in our project but as it wasn’t mature enough and didn’t have all the elements we required, we were having to go through the process of getting them signed off which slowed us down massively. As we were time poor we ended up moving away from depending on the design system and will be looking to integrate some of the additional components post-launch.”
Process is needed but slow processes, logically, cause dependent systems and teams to slow down as well. And if other teams rely on a design system, being slow can be a critical interdependency risk to adoption of the system across products and services.
Which brings me to the next section, about design systems and service design.
Design Systems Need Service Design
Another participant mentioned the ‘service design around’ the design system which brought a twinkle to my eye, because this is, I feel, a key to getting design systems solved for designers, teams and organisations.
Starting/maintaining a design system: “I worked at a client beforehand that had a huge design system across brands and it was a maintenance nightmare — mainly because the service design around HOW teams use it wasn’t thought out. For a design system to succeed, it must be driven by the organisation structure and culture. If the business isn’t set up to support the system as a product, it will 100% fail.”
This comment mirrors my experiences to date. Having resuscitated one design system, pitched another, incepted two and observed an amazing design system that’s ready to go and not adopted… as well as other cases of change and issues with definition around launch and rollout to users, isn’t it terrible that as design teams now we might have ‘permission’ to build these systems, we can’t get the systems to work for us, or our teams.
Not only for us, as individuals but other users too. Think of the beneficiaries of these systems if the service is considered eg. the users on the other side of the system we design. In order to not fail everyone, we must understand the needs of the organisation, the needs of the users in teams as well as the outcomes for the people who experience the effects of the design system in our products, systems and services. Then, we must design for them both in the product, the design system, and the service it is delivering to it’s users.
Ownership Needs to be Defined
Part of the service design of design systems is defining owners. At the Melbourne Web Meetup last year I talked about design systems in relation to experiences we are designing for and the source of truth. I hadn’t fully synthesised my ideas at the time and was thinking about consistency and system ubiquity (all systems we design for in an ecosystem) in relation to design systems and letting go of execution.
How might we still design if we don’t execute the design at pixel level? We problem solve, improve and innovate around and with the design system
This letting go was in relation to our self-identification of designers in what we do as practitioners. The audience at the Melbourne Web Meetup consisted of designers and engineers.
Starting/maintaining a design system: “Difficult! Our UI team has grown and then diminished so maintaining a process has been difficult. Gaining consensus on which ‘system’ is the right one within engineering is also been a struggle”
At the time, my opinion was that the best place for designers, embedded in engineering teams, who had an interest in creating better space for problem solving and UX, would be to take a position of advocacy for design systems. This advocacy would be to empower engineering to hold the source of truth, the design system artefact, which is in many cases (unless the service is different) a technology artefact.
Tools are an additional pain point for some participants as our product and service eco-systems become more complex. As designers, we need to behave like engineers or product/creative technologists. While these challenges create learning opportunities, they also embody frustration for many designers who are not equally equipped for the task. Space for learning also needs to be afforded to designers if faced with additional challenges outside of their knowledge set. Likewise, designers need to collaborate with people skilled in the areas they are interacting with, such as engineering, to succeed.
Starting/maintaining a design system: “Frustrating, there are no mature tools for this task, only hacks with react or sketch, abstract. This isn’t the first design system I create though, so it’s easier this time around but the company is a lot more complex than before where I had just three apps on three separate platforms”
The challenges of new terrain, in my mind, creates the case for passing ownership of the artefact to the team rather than the individual. The high fidelity artefact being the production code or the end-state prototype, rather than the working Sketch files or lower fidelity designs, means that the design system exists independently and requires many hands to ‘ship it’.
In a team I worked with on native apps we sought to reflect the production code in Sketch via regular version control and merge rituals. However this was highly manual and time intensive. We didn’t have the Sketch and React integrations web teams benefit from, technically we couldn’t make our system universal to the web system or present it in the same setting. We hacked responsive design principles into our approach with device widths and landscape versus portrait orientation for various devices (iOS and Android) in our design system views. Due to system constraints and integration restrictions, we could only react back into the work stack manually rather than automate easily with two different kinds of production code (Swift and Android/Java) like we can now with React and Sketch. The ability to reverse this manual flow to high fidelity is an opportunity in the native app environment, however in the web environment we are still improving on this across all technologies and system stacks, so we still have a way to go.
Starting/maintaining a design system: “Difficult to have a source of truth and keep track of divergence. Difficult to maintain once design system between designers, and between design / FED”
The desire to push production code as the source of truth has been the often unarticulated agenda for many human-centered designers, including UX-ers, I have worked with to date. This is not to say that system ownership should not exist with design, but that UX-ers wish to be relinquished of the execution load, the pixel pushing, to help them have time to problem solve, particularly if participating in Agile cross-functional teams.
Starting/maintaining a design system: “HARD. We are on to our second version of the system. It’s hard to get the components structured well, named well, and designed well. We learnt a lot in the first go of it, and believe our second pass is better suited for the company. It takes way longer than you expect, and must be done well by detail- and abstracted-orientated people”
Saying this, interaction and visual design is intrinsic to the user experience of products and services and we cannot ignore it. The UI and product design focus, of part of our community, is equally important and informs the way we design for usability and accessibility. Challenges around consensus also exist.
Starting/maintaining a design system: “Hard to get consensus.. and it is constantly evolving/ living set of guidelines”
As a profession we have fractures between UX, service design, UI and product design. Our agendas are similar and different. Design systems can serve an objective to solve this design culture alignment issue with something visible to refer to, in order to help us all do our best work and prevent factional disparity in the way we deliver value to our customers and users.
Perhaps working out the best service provision and work system approach to a design system is the way to go, in order to align design community team members as well as other functions
For me, working with engineering or other functions is non-negotiable in the approach to design system creation. While it may be faster and useful to spin up the first phase or slice of a system independently, over time the community ownership of the system with rituals built around it in a cross-functional guild oriented approach has been the best way to execute and manage the design system, to keep it living, that I’ve seen to date.
Every Organisation is Different
Processes are different in every organisation as are how we are organised. While we might establish standards in design systems, the strategies we use to approach how we might organise around the design system and provide a service strategy to support one/many in our design operations might vary.
I’ve talked quite briefly about using playbooks to support a design system at #UX2018, however a playbook can only be supported by understanding your users and system constraints/dependencies first. Running a discovery and vision approach for a design system could be hugely useful to take it beyond an experiment that has a likelihood of failure if strategies to system adoption aren’t understood early and reviewed often.
Stories from participants in this survey were quite telling of different approaches to design system organisation. This detailed story from one participant describes a participant’s approach to the complexities of an organisation with mixed adoption of a design system and a team that owns the system itself:
“I typically pull from the existing design system to craft mockups.
Since all our design and front-end development teams are at different stages of fully embracing the system, I am also responsible for lobbying for updates to be made in order to be compliant with the system. These arguments typically don’t end at “Because we need to be consistent”, as my stakeholders are wary of doing things simply for the sake of falling in line.
So oftentimes I craft arguments based on UX principles (which sometimes includes running studies of people using a mockup with our “old system”, which really is a hodge-podge, versus the new system).
I also have conversations with the team heading up the design system creation, so that I can ask questions or point out aspects of the experience that have yet to be addressed.”
This story retells an approach of a user, a UX Designer, interacting with the system, using user-centered arguments to provide the right approach to her team. There is a load on the designer to justify similarity and change in execution it seems. Everyone wants to make an impact, don’t they, but perhaps not at the users’ expense ie. the customer.
The Threat or Opportunity of Automation
Design systems present a threat or opportunity depending on one’s position and approach to design. The dominant attitude from participants is that design systems help us design better and problem solve more. However we, as a community may still maintain a social conscience and awareness of the effects of opportunities for our colleagues who are user interface focused.
Starting/maintaining a design system: “I wasn’t responsible for creating or maintaining it, but having recently started to use it I can see its benefits in terms of efficiencies, although I wonder if it would make some of our in-house UI designer roles redundant.”
Often what I also see is a defence of creativity in relation to the use and maintenance of the design system, and the perception of the design system as creativity’s rival. However, once the usability and user experience is established as ‘good’, there is great opportunity for optimisation and emotional design to delight end-users. However, even then the design system establishes visual design as a theming and optimisation function. Although not much was said about this by survey participants, it’s definitely a frustration I’ve heard vocalised by creatives, visual or UI designers despite their support and belief in consistency.
My thinking is optimistic, because a design system might only accelerate our approach to better interaction design and more beautiful visual interactions. If some design decision making is benchmarked, in flexible architecture, we may have better ways to optimise these interfaces for our users. Don’t forget we might mimic these paradigms of systematisation in other design execution areas such as service, voice, touch, mixed reality contexts too.
Design systems present a threat or opportunity depending on one’s position and approach to design. What is your design mindset?
As long as design systems do not infiltrate in to the dark side, rather with the right service and user interaction around them, and correct automation, they will help us use the force for good. The disclaimer to this is as long as we use them ethically and responsibly, with the right community ownership, attention and problem identification, before solutions in the design system are realised.
Documentation and Support is Needed
The repeated friction between system and use is clear from participant feedback, in that maturity is not established around design system behaviour with teams and organisations, yet. We have many opportunities to improve this, however these opportunities warrant a deep breath and view of the vision for the system and how people and teams should use it.
Starting/maintaining a design system: “It is a living, breathing organism that must evolve as we grow/change/need it to. Also, documentation — a central documentation area — is crucial.”
The next sections will discuss Agile approaches, team focuses and user centered design in relation to design systems.
Is your team ‘Agile’?
Participants were asked about starting and maintaining design systems in the previous question, then they were asked, “Do you work in an agile team?”
Answers overwhelmingly “Yes” to working in an agile team, with three quarters of participants answering this option. Almost ten percent of participants said “No,” and fifteen percent said “Other.”
Answers to ‘Other’ included the following themes. Participants with a consultancy focus talked to the variety of methods and approaches taken in market with customers who are organisations. Others talked about projects, quasi-Agile approaches, waterfall and then some natural cynicism about whether Agile is ever done well crept in too.
It’s Mixed
- “Multiple clients with multiple methodologies”
- “In namesake, yes, but in my perspective we often roll out in waves”
- “Projects some of which are agile”
- “Not true Agile, it’s leaning toward waterfall”
- “Hahahahahaha no one does Agile,…”
So while teams might be cross-functional and multi-disciplinary, Agile mindsets and approaches appear to be disputed or non-existent for approximately a quarter of the participants who responded to the survey.
Design Systems and Agile Teams
Participants were asked about starting and maintaining design systems in the previous question, then they were asked, “If yes, how important do you believe a design system is for a designer working in an agile team?”
The question presented a five point likert scale to participants with a range from Not at all Important (1) to Highly Important (5):
- #5: 58.1% (18 responses)
- #4: 29% (9 responses)
- #3: 12.9% (4 responses)
- #2: 0% (0 responses)
- #1: 0% (0 responses)
The answers from the ‘Yes’ group, including some who didn’t answer ‘Yes’ specifically, given there were thirty-one responses in total, not thirty-four, indicating that the perception of importance of a design system for designers in an agile team was considered to be of moderate to high importance by most survey participants.
In agile teams, design systems are important
In light of their answer to whether design systems are important for designers in agile teams, participants were then asked, “Why do you feel this way?”
Themes that came through were around quality, iterative process, speed to market, ability and also the idea that agile doesn’t matter, that design systems also operate well in waterfall project delivery settings:
- Benchmark Consistency and Increase Speed
- Designing the Experience, not Just the Interface
- Design Ops Enable Iterative Design Processes to Happen
- Shared Design Context with Delivery Teams and Functions
- Also, The Team Doesn’t Need to be Agile
These themes are further elaborated on below:
Benchmark Consistency and Increase Speed
Many participants mention speed to market as a key benefit of a design system, in aiding them to be more efficient and consistent in their practice.
The importance of design systems for designers in agile teams: “It enables the designers to prototype at speed using existing components”
Interestingly when speed is a focus, and team capability isn’t perceived to be as important, a design system may help to maintain design quality, which might otherwise be undermined without one.
The importance of design systems for designers in agile teams: “Speed of delivery, team capability isn’t under scrutiny”
Interestingly participants seem to have misread the goal of “Agile” which is speed to value for the customer, not speed to market. It seems the teams or organisations they serve may have this ‘first in market’ mandate at the expense of value.
Perhaps the value of a design system for an agile team is better expressed as a ‘speed to value’ enabler, in that designers and their teams have more time to problem solve than to re-invent the interface wheel repeatedly
The importance of design systems for designers in agile teams: “Speed is crucial in agile, and easily reference-able design systems help you move quickly”
While speed is important, what is also important is the experience. The design system may create risk in enabling quick ‘solutions’ which, if not treated as experiments, may cause inherent risk in the speed to market race many of us seem to be participating in. I‘d advocate that it’s ok to slow down or have space to think with your team.
Let’s not follow a predictable road, avoid fatalities, and have the agency to correct course with our design systems as an enabler. Good suggestion, if we can afford the time and space to do so. While design systems answer and efficiency and time constraint on our work approaches they could also enable poor behaviours in the execution of invaluable solutions for users. Hence the designer is still needed, even if some actions are automated over time.
Designing the Experience, not Just the Interface
In this light, survey participants again returned to the value of problem solving enablement in light of the use of design systems:
“Teams want to be able to work quickly, validate their experiences as soon as possible. Having a system that enables agile teams to focus on the customer problem, and not deciding what shade of green to use on a button”
The benefit of a design system is focus. While the process and execution are important, having something that is reliable to help create conventions in the use of patterns and interactions as well as information design can have tangible benefits for the product and service end-user. For the user of the design system, the designers and their teams, including for many engineering and product team members, all of a sudden there may be less discussions on the visual presentation of a call to action and more conversation around the why users should interact with it in the first place.
The importance of design systems for designers in agile teams: “Less spec work makes it easier to talk about the whys rather than hows”
Design Ops Enable Iterative Design Processes to Happen
Just like the systems we create, whether they be product or service oriented, we need to provision around use and allow the systems to be living and evolvable. Many of us are working in continuous delivery and continuous improvement environments and it makes sense to systematise parts of the architecture that touch other parts in order to make that part of the system relatable and flexible to work with.
Designers naturally iterate on ideas and solutions, hence it makes sense to enable a tool that creates systemic efficiency for many people interacting with it as users in an eco-system not unlike engineers do already.
The importance of design systems for designers in agile teams: “Design is by a nature inherently agile as it should be optimal for a specific experience and should be flexible to extend always”
System architecture is a term that is often applied to the engineering code and technology services, and not necessarily to the design decision layer that applies to a user experience. However the execution of design decisions have the potential to affect the system technology architecture just like any other change to a service, API, warehouse or repository.
Designers are working in engineering environments frequently, creating a state where design and engineering interact, together with other functions, to change, improve, innovate or depreciate a system are frequently interchangeable in intent with different kinds of execution methodologies. Therefore, in a technology context, design, though inherently considered ‘creative’ is very much technical and vice versa.
The task of design is now to make the best decisions we can for the people who are our end-users of design systems, by improving our own team efficiencies as users of these systems also, so enters the age of Design Ops.
The importance of design systems for designers in agile teams: “library maintenance enables continuity and extensibility of evolving design decisions”
Given the shared context with engineering, in delivery we are all actors, working together to deliver something to an audience of our products and services. We just need time, as the participants in the survey are telling us, to spend more time on the why and less on the how.
Shared Design Context with Delivery Teams and Functions
By sharing design execution in a systemic way that anyone can use it, we create focus for efficient design process when things need to be built with production code. The ability to sketch something, reuse patterns, whiteboard with our colleagues and prototype quickly are all benefits of establishing a design system with core components that are reusable.
The importance of design systems for designers in agile teams: “In my company we are months ahead of the engineering team in terms of work so it is difficult for us to be part of that sprint, however we have to work with the engineers and help with the work they are doing continuously”
Having the ability to create a shared understanding via a system has multiple benefits, especially if it is well adopted and scaled appropriately, adapting to changes. No person is an island, and certainly this is the case in organisations delivering products and services to customers.
The importance of design systems for designers in agile teams: “Helps designers keep their work consistent across the product, across time, instead of falling into the trap of myopically designing one screen in isolation”
The gathering of the interface into a fidelity that helps more than one function or specialisation in a team or organisation create a mutual understanding is a win. Having the ability to create rituals around system maintenance, in order to enable the ability to sync users of the system with decisions being made in a vast organism that is an organisation, can only help progress, a shared understanding for design system users and efficiency in decision making.
The importance of design systems for designers in agile teams: “Helps to sync our design and engineering efforts all the while keeping other teams informed”
Having a single source of truth for design and engineering diminishes tensions and helps alignment in teams in order to progress team collaboration and focus.
The importance of design systems for designers in agile teams: “So we can focus on delivering things. Not slide decks, but real outcomes. Working in the same methodology as devs helps bring alignment of focus and maintain view of the deliverable”
Also, The Team Doesn’t Need to be Agile
While agility is important to many participants in this survey, possibly given many are working in agile teams already, it is also important to acknowledge that design systems have value for waterfall and project delivery teams too.
The importance of design systems for designers in agile teams: “I think it’s important for all teams, so I don’t feel the “agile” nature impacts my viewpoint. I’ve worked on very agile teams previously and think a design system there would be just as beneficial as it is to a more waterfall style”
While the benefits of design systems clearly exist for teams working with an agile approach to delivery, waterfall oriented project teams might still benefit from the ability to create, maintain and evolve a design system too.
The importance of design systems for designers in agile teams: “I don’t see how an Agile work environment changes anything about the design system, or vice versa”
All in all design systems clearly have value for many reasons in agile and waterfall delivery settings.
Who is responsible for the Design System?
Participants were then asked, “Who in your team is responsible for the design system, if you have one?”
Participants were able to answer multiple times. Most people answered across three functions including; design, engineering and product.
The most roles nominated as responsible for design systems were, in order of frequency of mention:
- UX Design (13 votes)
- Front-end Engineering (12 votes)
- UI Design (10 votes)
- Product Design and Visual Design (7 votes each)
- Product Manager (4 votes)
- UX Engineering and User Research (2 votes each)
- UX Manager, Product Owner, Service Designer, Whole Team (1 vote each)
While more regular delivery roles dominate the mentions and UX and Design have majority ownership in this survey’s findings, we now have what appear to be perceived business oriented and strategic roles (product managers, UX managers and service designers) entering the area of design system ownership. Delightfully, ‘whole team’ was mentioned as well.
Are Design Systems and User Centered Design a Thing?
After this the survey was flipped to thinking about end-beneficiaries, the users of the systems and products we design for, “In general, how important do you believe a design system is to user-centered design?”
The question presented a five point likert scale to participants with a range from Not at all Important (1) to Highly Important (5):
- #5: 47.1% (16 responses)
- #4: 23.5% (8 responses)
- #3: 23.5% (8 responses)
- #2: 5.9% (2 responses)
- #1: 0% (0 responses)
Almost half of participants voted for option five, ‘highly important,’ in response to the question, “In general, how important do you believe a design system is to user-centered design?”
Slightly less than this number voted for neutral to moderately important and a low percentage of participants, less than six percent, voted for slightly important on the scale.
All in all, allowing for the number of votes in moderate to high on the scale, almost seventy-one percent of participants consider design systems moderately to highly important to user-centered design.
Why should design systems be user-centered?
In light of their answers to whether design systems are important to user-centered design, participants were then asked, “Why do you feel this way?”
Themes that came through were around interdependencies of approach versus systems, learning and cognitive load, user needs and stakeholder feedback or interactions:
- User-centered Design (UCD) Can Happen With or Without a Design System
- Design Systems May Not Cover All User Needs
- Learning is Improved, Cognitive Load is Lessened
- Helps with Mitigating Effects Highest Paid Person’s Opinion (HiPPO) Syndrome
- Ultimately the Team is Enabled to Become More User Centred, Too
These themes are further elaborated on below:
UCD Can Happen With or Without a Design System
Some participants commented that user-centered design can happen independent of design systems, which is absolutely true, it can. UCD is not interdependent on design systems, however design systems can enable UCD, enhance and improve it via the volition of the teams who make system changes or create system components.
Why should design systems be user-centered? “Helps guide the process, but you can be user-centered (whatever that means lately) without a design system”
Just like UCD it depends on the team and the approach. And remember, approached and built correctly, a design system can afford better accessibility enablement too.
Supporting this conjecture around the need of design systems, a related question came up regarding the need for a design system, particularly with finite, non-continuous projects:
Why should design systems be user-centered? “I think it depends on the work. Some projects don’t require ongoing maintenance in the same way that enterprise products do, for example, so a design system might be too much”
Decisions regarding effort and value of design system investment must be made to warrant a systemic approach to implementation. However a user-centered approach to the design of anything can never be awful and is always better for the user.
Design Systems May Not Cover All User Needs
Despite the sense that many survey participants felt, “You can be user focused with anything,” there was still conjecture that a design system may not always be user-centred due to the constraints of consistency.
It seems that the following comment, below, relates to frustrations around the maintenance of consistency as a trade off for user value, in favour towards the value of continuity. It may be an edge-case but it is a useful point to consider.
Why should design systems be user-centered? “Design systems are an important ingredient in creating continuous experiences. Continuity builds trust and confidence, which are fundamental aspects of user-centric design. That said, I don’t rate it 5/5 because I believe there are other elements of user-centered design that are also highly important. For instance, I wouldn’t sacrifice a niche user need for a certain type of interaction simply because it isn’t embraced by a design system”
This commentary signals a frustration with systems and generic ubiquity. It could be that as design team owners, while we should act as gatekeepers to ensure the quality and adoption of the design system is maintained, we should be open to new scenarios, needs cases and improvements for users.
Learning is Improved, Cognitive Load is Lessened
Interestingly, overall the use of ‘user’ is interchangeable in some of the participant feedback. Users are both the individuals and teams who collaborate and use the design system internal to the organisation. But, also, users are the people who use products, systems and services.
Why should design systems be user-centered? “Continuity of components makes for a more learnable experience; efficiency of code makes for a faster experience”
It is fair to conclude, after understanding previous commentary and themes, that design systems have benefits for multiple user roles.
Why should design systems be user-centered? “For larger sites and organisations, a design system helps to create cohesive interfaces, which are easier for the user to learn and use. Eases cognitive load”
Helps with Mitigating Effects of HiPPO Syndrome
We all understand the frustration, as designers, that we experience in this scenario; we’ve done the due diligence on problem solving, ideation, prototyping and testing and an influential stakeholder comes along and wants to change the interface design or user experience. Design systems present the opportunity for user-centred validation (or invalidation) to occur in a way that is absolutely scientific and unarguable, if we as teams enable feedback loops into our design system services.
Why should design systems be user-centered? “Cuts down on ambiguity when using proven (patterns) influential stakeholders can’t argue with it”
Ultimately the Team is Enabled to Become More User Centred, Too
Overall, many participants felt positive about user-centred approaches to design systems given it is their job to advocate for the customer/users. So not only is the design system user-centred by enabling better team practices and capability, the team inherits the benefits of user-centred design as well:
- “User centered design feeds back into the system, so it is always relevant for our customers”
- “It just helps use tried and tested patterns but if the patterns aren’t good it’s not user-centred”
- “A design system is only valuable to a user if it helps her reach her goals”
- “I think it’s context specific”
- “Everything should be user, value centered to ensure success and sustainability”
- “it aligns with best practices and validated principles of creating easy to use products for all user segments”
Why should design systems be user-centered? “I’m a uxer…”
Some participants felt a this was a complex question to answer, though, due to the constraints of the way their own teams were organised. For example, in this participant’s case:
- “This is a confusing question. For digital products: Design is a bucket that encompasses interaction and visual design. The Interaction practice has the user as king, the visual practice only needs To be in good graces with the user”
However, consistency wins from a user-centred design and value approach. For many participants this is the explicit value of a design system, to create consistency and modularity from which better, user-centred design experiences might be created:
- I think if the design team feels less cluttered we can spend more time on the user and that is what really matters
- A framework for consistency of approach
- Consistency cross-products
- Consistency! And forces you to consider different states & scenarios for each component, which can’t be done when working with full screen mockups.
- because consistency really matter for user, it will really help them to understand our product
Overall, without a user-centred, consistent approach, participants feel not only teams might be misaligned, but the user experience of other systems, products and services may be less user-friendly too.
A Brief Note about Unicorns
In conclusion, it is valid to hypothesise that design systems may be the solution to provide designers and their teams more space, and time, to do the work that’s needed for the best outcome for our users, as well as their teams and themselves.
I often hear revulsion in the voices of designers who vocalise around having to do the ‘full stack’ of UX in agile cross-functional product and service delivery teams. It seems that revulsion stems from the fact that our responsibilities cater for three jobs in one eg. interface design, user research, user testing. And this is just the second or third diamond, not the first. Nor might this approach actually be human-centered, as teams may progress down a path that has predefined parameters that may be within and outside of our control as designers additionally.
In a cross-functional team of one designer, how might the designer get ahead with research, undertake design experimentation and execution as well as test and learn, rinse and repeat? Let’s not forget the problem of vision and design ops responsibilities. Just like Engineers and Product we need to do our housekeeping too.
We all know that Agile and UX has presented the ‘unicornisation’ of the designer. Lean UX has presented an antidote to the unicorn, however with Lean we need a systemic approach, as with Lean, we are moving towards process efficiency on the factory floor. Enter, The Design System.
Any discipline practitioner presents a T-shape to their team and cross-functionally, making us all a bit dissimilar. What this means in multi-disciplinary teams, is that the team collaboration we are establishing as we get to know each other, as we share competencies, skills and knowledge, will always have a different ‘flavour.’ This isn’t any different in design, as many designers are different, yet may present with a similar job title.
This doesn’t account for the introduction of Lean in Agile UX and product design, which suggests helpfully, that we should draw first. However the constraints of a draw first, and draw to execute, approach favoured in agile relies on a system that allows our colleagues to execute design solutions on our behalf, especially if, as designers, we are moving to the next set of problems to solve.
A Note: Thank You to Participants
I’d like to thank everyone who participated in the survey. Your time and participation was hugely appreciated and I hope you find the information in this article valuable for your team. For anyone creating, establishing or maintaining a design system, I hope this is useful in your day to day work. There is more information to share and synthesise, but perhaps I’ll publish that next time in a separate article.
Ciao for now, folks!
