ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Thanks for your interest in The Question!

Sign up to participate in future questions
here.

This file is the raw data from Episode 10, deep dive hosted on Feb 9, 2024 with Kristi Bryden.

There are 48 answers. The question this week was:

-----

Kristi and I were chatting the other day about how design systems can be a way to rapidly distribute standards across a digital product organization. Off the cuff, we listed a handful of standards a design system is well-positioned to enable:

• Usability standards
• Performance standards
• Engagement standards
• Accessibility standards
• Sustainability standards

…and I’m sure there are many more!

While this seems logical and reasonable, it’s also not as easy as it seems. Those standards need to be clarified, distributed, tracked, and monitored.

And this brings us to our question for the week:

Does your system confidently clarify and distribute these kinds of standards across those working on digital interfaces inside your organization?

If so, share what standards your system prioritizes, how you distribute them, and how they are tracked and monitored. If not, share why or what you hope to accomplish in this area in the future.

2
Question 1: Does your system confidently clarify and distribute these kinds of standards across those working on digital interfaces inside your organization? Question 2: If so, share what standards your system prioritizes, how you distribute them, and how they are tracked and monitored. If not, share why or what you hope to accomplish in this area in the future.
3
Noincrease awareness of some of the standards
4
YesYes they do.
We have a 1 year old design system that covers use cases across more than 30 products and 4 business sectors. Behemoth tasks, but the design system looks at what unites these products in terms of UX, visual language and front end code standards. We also claim that the individual components meet the toughest a11y standards (Ontario, Canada). We have design ambassadors that ensure the DS is well followed.
5
YesMoreso yes than no. We attempt to have usability guidelines (not standards, it's flexible at this point), implementation notes, and accessibility standards. However, they are not tracked.
6
NoClearly not, as we unfortunately don't have a dev source of truth. Long story, but we have Storybook, but a lot of component building/styling was already done in React on a large important project, and we don't have enough resources to dedicated moving and fine-tuning everything over, so we have bespoke styling on pretty much the same components that are used. As a designer, def having a hard time COPE'ng (Create Once Publish Everywhere).
7
YesGeneral design and a11y standards are documented both in Figma and in Confluence. Usage is tracked via Figma. They are further encoded into the GitHub-based libraries for React and web components we distribute and track via GitHub's search and Sourcegraph.

We are still new enough that in a large org we are still refining our tracking processes to set reliable expectations. We are also looking into ways to further collaborate with teams.
8
YesOne of the definition we use for the DS is "a collection of standards", so we better be doing it!
I can confidently say "confidently" because the DS is the first place our users look at, and if they don't find defined standards, they sure complain!
We look at "usage" as the main umbrella for the standards the DS defines, and it refers to everything you need to know in order to design and build digital products in the company: usability, content, coding, colour use strategy, overriding tokens, etc.
Many of those standards were either contributed by the community (e.g. content and accessibility), or brought up by representatives from the community and discussed together, before introduced into the DS.
All our guidelines/standards are defined in our documentation site on Storybook, available for all DS users.
9
We're still building those standard, but are well on our way. Accessibility is a big focus as we build our standards.
10
NoGetting adoption from the leadership in this climate has been challenging. But my strategy has been to highlight one of those standards and put the rest on Storybook or the design system website, i.e. drive eyeballs to the rest of the material.
11
YesI've prioritized performance, engagement, and accessibility standards throughout my career. These standards need to be researched, defined, and agreed through documentation for all cross-functional teams to understand the expectations for our product. I usually do this through clarifying research followed by a workshop series with involved teams. This will help clarify the standards while also getting buy-in right away.
The team will then work on distributing the standards by training teams on why they are important to both the user and the business. Then how to use the standards in their workflows.
We usually collaborate with engineering and data to establish clear tracking systems. This usually requires understanding the goals of the business, the pain points in the user journey, and the needs of the marketing team.
Monitoring takes dedicated cross-functional team members to make sure that we’ve met our goals. I’ve used google analytics, various dashboards, and user interviews to do a check on our standards. I am still not satisfied with how I’ve done this though. I want to be able to show value to the business that this time and effort has had an impact.
12
YesI wish there was a middle answer! Some aspects we are, some we aren't.

If we're talking about the reuse ecosystem, we do publish design language, code standards, design best practices, accessibility practice, content standards and general process.

If we look at just the design system, we have to support multiple brands and business lines, so we work to make the core system as agnostic of themes and business logic as possible. We intentionally make space for individual portfolios to set their own standards and methods of governance. And we work to make our system support that variety.

Across the ecosystem, which is owned by many different experts and teams (federated), these things are covered. Within the core design system, which is owned by a single dedicated team (centralized), we intentionally leave them out and ensure our system supports the right things like WCAG compliance and flexible themeing.
13
Its far too much weight and pressure to put on ONE tool (a design system) to push the needle on these very large initiatives that, arguably, warrant their own teams, funding, process, etc.

I understand the desire to centralize, but the risk of bloat and boiling the ocean--or at worst case, dooming an effort to fail--is far too high. Especially when teams/orgs are already having enough of a hard time getting funding/headcount for the more foundational aspects of what we define design systems as today.
Usage, accessibility, and usability guidelines of ONLY the resources we ship. Mandating, standardizing, and migrating to those standards is a responsibility of the Director+ leadership group, supported and made "real" by the system (not the other way around).
14
NoOur team really prioritizes standards around component usage and interaction patterns. Also learnings from usability tests that come back as patterns.

We usualy prioritize based on if there’s any big projects that our design system can deliver a lot of value by delivering these standards or when multiple teams would benefit from a standard.

Distributing has been our biggest roadblock. We haven’t developed a great communication strategy that works for our organization yet. We lack engagement from and with our users.
15
NoMy design system prioritizes consistency, but it has been lacking as we've introduced other UI components and the application has grown beyond the original goals of the design system. My design system needs to be revamped in several key areas, but will probably stagnate as I don't have a bunch of time to work on it.
16
I am interested in learning more about design systems. N/A
17
NoStill very much a work in progress at the company I work for.
18
YesWe are aiming for all the ones that you have mentioned but have a trouble getting to them all!
19
NoIn my current project, the design system is bifurcated into two aspects, UX Design System and UI Design System. Even though the intent is to progress towards a comprehensive design system, currently it exists at the stage of a distributed component library.

The aim is to focus on building a design system that has its foundations established in the brand and product’s core pillars. Building ground up, the function of the design system is to comprehensively unite ux, ui, development, tone of voice, etc. Because the product needs to ensure user’s safety in a physical and dynamic environment, accessibility should therefore be at the forefront of each design decision.
20
NoJust so much inconsistency between what components design and engineering are
21
NoWe feel confident that our components pass basic a11y, but we aren't doing anything to educate or surface those standards. We don't have org-wide perf or usability or front-end code standards defined at all!
22
Currently working an agency gig with one designer, one developer, and small-scope projects.In the past, I’ve given prioritization to indicating design / API maturity of individual components; color / spacing; guidance on use cases (e.g. severity of errors / warnings).
23
I'm currently in search of an organization where I can apply these concepts to their design system needs.Applying a design system mindset to ALL systems in an organization (not just digital interface design). Defining standards and having a shared reference makes for a more cohesive and focused team in any aspect of the organization's goals.
24
YesWe share usability and accessibility standards via our written guidelines and try to convey them through design reviews as well. We don't track them actively.
25
We’re still in early stages of designing the product. But I believe once it has been established it would clarify and distribute these kinds of standards. Currently mainly focused on color, type scale, and spacing. Eventually it would include UI components and accessibility. We prioritise getting a handle on consistency of type usage, color, and spacing. Including some forms of accessibility. But the product is not established enough yet to include more constraints yet.
26
Yesits a bit of yes and no :)
We have been working to distribute accessibility, performance, and usability standards by way of embedding them into our component builds. Following the principle of making it hard to do the wrong thing, and easy to do right, we are trying to build in a way that wouldnt require reading or consuming best practices in order for the system to support them. For example, tokens are paired in a way that makes accessible color pairing a no brainer for most cases - no knowledge of the ratios required (though always encouraged ofc). For something like performance, were making decisions about when components should be separated vs supported as variants based sometimes on the performance factors around creating components that have too many rabbit holes - the goal is that the system is architected in a way that gives optimal performance. then we can share out those decision making principles more broadly once we know they work.

For other things that require more knowledge sharing and reading of docs like engagement standard and more UX standards, we plan on incorporating them into documentation, communication, and office hours once we have the technical side of the system stood up - were just not really there yet!
27
NoA11y, I18n, usabilty and design guidelines are the ones that we are really focused on right now. But to me is just a reflection of our maturity. We have a lot to figure it out.
28
NoWe have loose standards which are embedded into the ways we work — but not widely documented or shared; standards, especially for things such as accessibility are something that should be widely documented and available for others to see.

It's the one part of design system documentation that often gets forgotten — people tend to see documentation as a means to educate others on how to use system components, not to define ways of working, processes and standards.
29
YesI said yes, but we are still in the process. we have a starting point but struggling to get buy-in because we think development first and design last. As for what we prioritize, i'd say...
- Usability standards
- Performance standards
- Accessibility standards
30
YesAccessiblity
31
YesCurrently the only standard we prioritize is accessibility, and this is baked into all our components and they not released as full components (instead we call them Beta components) until a full A11y review has been performed by our Principle Accessibility Engineer, who is part of the Design System team.

This standard is also distributed through the provision of documentation which states the best practice and guidelines to achieve accessibility standards (WCAG 2.2 AA) when using that component in both design and development.
Our design system team is also responsible (as subject matter experts) for educating the wider design community on this standard, which is delivered in workshop format. The current workshop offering is on accessibility annotations in designs (which they have also used as an opportunity to promote the use of our component library).

However, the achievement of this standard is not something that is centrally tracked or managed by our team, or indeed any other teams at present.
32
YesUsability and accessibility standards are loosely communicated a cross the Design practice. We have the opportunity to operationalize within the Design practice and Product organization as well. I'd be curious on recommendations of how to rapidly distribute.
33
NoUsability and Accessibility standards
34
YesMy system prioritizes usability, performance/engagement, and accessibility standards.

The first step we take is for the UX and Development teams to understand what is needed to ensure this module is robust. This includes current site performance and engagement considerations, systems integrations, regional/global considerations, and overall accessibility and usability considerations.

Once we have that documentation built, we distribute it in a couple of ways. The first is to ensure that it's included in both the Figma DS documentation and storybook documentation. The second is to share with all collaborating teams within a sprint review.

Then, the standards are monitored through UX checks when new marketing assets are requested and designed. They are tracked through CX performance and engagement metrics.

Currently, we are building the design system so sustainability standards are not a priority right now but I would love to integrate that in the future.
35
NoNo, at least not fully. Our design system is coming into it's own by replacing some documentation sources so we are bumping up against change management problems as well as cultural issues. I've had numerous conversations that touched on the topic of someone not knowing something existed and someone else pointing them to it. Tribal knowledge has been a great blessing at our organization but its turning into a bit of curse too. Our teams are building and delivering so quickly that often they miss the latest updates and newest releases of content. Someone can only lead a horse to water if they know where the water is. That's the problem we battling. Also (staying with the watering hole analogy) it's been difficult communicating broadly what source of water has dried up, has gone stale, or is even poisoned! All jokes aside, the content we are curating strives to be clear and distributed effectively but each chunk is on a scale of "correctness" waiting on iteration and review and in it's own spot of completeness waiting on others to provide use cases or other details.
36
NoA lot of guidelines are given to us (or will be given) from sister teams. Patterns we will need support will come from the Common Design team and accessibility requirements come from our accessibility team.
37
YesI'd say the answer is neither a responding yes nor a solid no, it's a 'somewhat'.

Accessibility standards are easy, make sure the DS confirms to WCAG (go above and beyond whenever possible), add further implementation a11y guides in component docs, then monitor the products VPATs for the outcomes.

Performance and security standards are slightly more complicated, but as long as it's a DS which has a coded implementation, you can have it run through all the stress testing, security scans, pen testing and platform testing that your QA leads recommend, sometimes the consuming products themselves recommend certain tests to be passed, it helps. These directly translate to the implementation so not much to do to monitor them, at most keep an eye out for related bugs being submitted by product teams.

Usability is a much more complex issue I'd say it's about 40% DS and 60% implementation, you can have as high standards as possible in design, keep abreast of latest patterns, do your user testing... But consumers will find a way to mess it up in implementation, or just chose wrong elements from the DS. I guess the best you can do is 3 things:

1. Make the documentation clear and comprehensive.
2. Have a strong connect with the product team and advocate for judicious implementation.
3. Have a mechanism where implemented screens often come back to the DS team, we've picked up cases of weird implementations which were addressed by further advocacy and sometimes new features.

For engagement, it's more qualitative than quantitative, sure you have component usage analytics and views of your DS docs, but those are just numbers. The DS team needs to regularly meet all consumer teams to promote, maintain and monitor standards of engagement. In the end, if your product teams are happy with you, you're doing well. So apart from the stats in your quarterly presentations, have some quotes too.

Sustainability, is a long term vision question, I've run out of space so maybe later :)
38
YesAccessibility is number one for sure. Next would be around usability and functionality. We also have content standards as well
39
NoWe're open to ideas!
40
NoWe only had conversations about how good it was to have some standards, but there were no real trackers. I think it was because the company was quite small and it was clear that DS was helping, but no one wanted to take the time to figure out the real numbers. Explaining how useful it was was enough.
41
YesOur design system is still nascent. Standards currently include:
- inclusive design
- content strategy
- branding to some extend (our system is built on a robust brand playbook)
42
YesAccessibility, Tech feasibility, Usage Guidelines, and Legal (e.g., how someone can and cannot use a logo) are all included in our documentation. Most have multiple touchpoints - such as our developer style guide, in Figma with an annotations plugin, and throughout our documentation site (ZeroHeight). It seems like this list continues to grow daily.
43
YesThe different roles on the systems team prioritize different standards towards a common purpose. I focus on using design systems to scale accessibility standards.

I distribute them by incorporating as many of these standards “for free” within components, such as target size, and focus indicators, so that consuming teams make some accessible decisions by just being an adopter.

Tracking the adoption of these standards feels impossible. I have no idea when a team successfully meets our accessibility standards, but I can get an idea when I see a team that actually doesn’t meet the standards (through defects and support questions).
44
NoWe prioritize Content standards and publish them through our system's doc site. We refer back to those standards frequently in support channels (slack, office hours, design reviews). This is the only one I feel confident about.

We also prioritize Accessibility. All our system work goes through both design and tech accessibility reviews, so we put out "the standard." And, we partner with accessibility team w/in our Risk department to create documentation and guidelines and push all features to go through their own accessibility review. I feel ok about this standard, but we could share more.

Our doc site has guidance around every component. But our system is not used universally, so that means the guidance isn't used that way. And while our Design team has prioritized this kind of detailed guidance, our tech team has not (due to capacity issues, not for want).

I don't think we even touch on performance standards. And, there is a lot more we could do. Design standards/reviews vary all across the company, and there is a desire to have more universal standards.
45
NoWe share usability and accessibility, but we definitely should be including the others.
46
NoMy organization is working on a few of these standards to serve our users better but we are still working on them. We plan on distributing some of this material through our documentation site but we are still in the planning phase for things such as engagement, sustainability, and performance.
47
NoWe still have a lot of work remaining here. We need to better bridge standards across design and engineering and accessibility. We've started, but with a legacy product, there is a lot of standards to clean up.
48
NoAny time a design system chooses to focus on a set of standards, it increases in value for the organization.

It takes those standards and makes them the source of truth; the place where the organization can point to when they need answers.

But that's not easy to do. It requires a lot of effort to design the best solution for each of these steps: clarifying, distributing, tracking, and monitoring.

But if a design system can figure it out and govern appropriately to their organization, then they go beyond just being a component library, they become a central repository on how the organization makes things.



49
NoPrimarily focuses on UI standards (usage and usability) at the moment, but we'd really like to communicate more higher-order standards, probably in a recipe-level layer.
50
YesMost of our efforts go towards brand, usability, and accessibility standards. In our more corporate environment, our stakeholders sometimes see our team as the "brand enforcement" team, the "make the UI good" team, or the "keep us out of some lawsuits" team. From their perspective, they want the numbers and stories to prove that we do this. We've become internal consultants. We make sure to show and tell them how successful these metrics are (brand and accessibility being the easiest to track).

However, having brand, usability, and accessibility as our key metrics seems to have come at the expense of a more restrictive model for our consumers. If we were tracking engagement, I think we'd have a more "product-forward" mentality because it would be a part of the story we tell our stakeholders.
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100