Episode 036 Raw Data

Thanks for your interest in The Question!

Sign up to participate in future questions here.

This file is the raw data from Episode 36, deep dive hosted on October 31, 2024 with Ben Callahan and Dan Mall.

There are 114 answers. The question this week was:

-----

Hello Curious People!

I’ve been thinking about how amazing the Earth is—giving us everything we need to sustain human life. But I’ve also been thinking about how our proximity to the Sun is just as important. Without that, the Earth would be nothing more than a frozen (or molten) sphere. Similarly, the human brain is an amazingly complex organ that controls our thoughts, movements, memory, and emotions. But without lungs, we couldn’t survive.

By now I’m sure you’re wondering why I’m telling you about this stuff. 😆

Well, the same is true for digital interfaces. A perfectly accessible form is a thing of beauty. But without a usable “submit” button, the form itself is much less useful. A brilliant navigation is key to users finding what they want. But without well-written content, they will still struggle to accomplish their goals.

Here’s what I’m getting at…the space between the components of your design system is more important than the components themselves. How they work together to enable a user to accomplish their goals—that’s what we’re after!

For this week, my co host Dan Mall and I are curious to hear how you handle the space between the pieces and parts your design system offers.

Let’s dive in!

Do you believe it should be the job of the design system team to offer assets and education around how to compose components into more robust experiences?

Does your design system offer assets and education around how to compose components into more robust experiences?

How are consuming teams composing experiences using your design system?

Question 1: Do you believe it should be the job of the design system team to offer assets and education around how to compose components into more robust experiences?

Question 2: Does your design system offer assets and education around how to compose components into more robust experiences?

Question 3: How are consuming teams composing experiences using your design system?

Yes

not_great_bob dot jpeg

Yes

They look at example pages in Figma and the documentation for each of the components in Github. If during a design review there are misunderstandings or improvements, those are rolled into the design system in the next release.

Yes

May answer to the second question is more of a “we are working on providing more to our users” than a flat “no”. We have teams that like to follow the guidance we provide, while others that push the boundaries of the system and the guidelines provided. Personally, I struggle with the level of guidance to provide to teams as the vision of the system was frankly, inherited on my part.

We are currently exploring an evolution of the system and this will likely put my stamp on it as Director of Design, so this is timely to say the least. I hope to strike the right balance of guidance to spark design inspiration while keeping teams within a certain threshold so as to maintain consistency across our suite of products. I may need a new espresso machine before I get there.

Yes

They use building blocks

Yes

We offer a sections called 'guides', 'showroom' and 'recipes' in our design systems.

Guides covers things like how to approach page setup, loading, validation, errors - anything that covers general principles.

The showroom is like an IKEA showroom, it demos fully functional pages of different common types for inspiration.

Recipes covers smaller parts of pages that demo common component interactions.

Yes

We have a lot of business analysts and developers working without a dedicated designer, and the results are mixed at best.

Yes

They are trying their best to make existing existing or new content fit the components and often end up pushing the limits or misusing components.

Yes

They're doing ok. Most of the issues they’re experiencing with those components are general UI challenges and aren’t related to the components’ composability.

Yes

They come up with compositions themselves. Many teams would like to have templates and more guidelines. Teams with more creative designers don’t like the idea to be guided on how to compose pages and flows. I personally believe this is a question on how much should the design system team lead the design and how much freedom should the designers have in composing experiences. Having templates for flows is often seen as restriction by UI deaigners that want to do those flows and compositions differently.

Yes

What we offer is not particularly fleshed out or robust, and so consequently a lot is left to the initiative of individual designers to know what can be achieved and try to realise it. Some complex things have been attempted (a progress stepper within a progress stepper?!?) but this is probably one aspect of the system amongst many that designers will understand or use with wildly varying success levels.

Some teams that we have worked with particularly closely have started doing this more robustly, so we know its possible with the right materials and outreach, but it is very labour/time intensive to support people with this.

Yes

N/A

Yes

On the Figma side, we provide a handful of core patterns and encourage the teams to work off of those, but do not hesitate to tell them if they need something different to detach (eek!) -- we do, however, beforehand, show them what will be affected by the attachment and continually stress that detached components will no longer update with the system standards.

On the code side, we have a developer styleguide that showcases how the different pieces of code can fit together to form an experience. Eventually we'd like to introduce a sandbox for devs to play directly in the space with less setup on their end, but for now we have this. (Our system is still fairly infantile.)

For both, we try to have frequent touchpoints with the consuming teams to review any changes to the components they've made or any experiences they're proud to share. From there, we determine if any of the changes should become part of the larger system.

Yes

I think we have tried to do this, but not sure we have succeeded in communicating well.

I think we do okay with this, but we probably rely too much on individual designers and developers to remember how the components are supposed to be used. As people have left, some of the knowledge has left with them.

could you explain what you mean by "consuming teams" and "composing experiences"

Yes

They aren;t yet

Yes

Our design system is new and being redone, so no. But I believe we should offer these assets and documentation.

They're not (yet?).

Yes

Typically, separate product teams can host their own library of composed patterns. Even before our DS team reached it's current maturity, teams have been hosting components and patterns in isolation. Lately, there's been a growing assumption that the DS team should be doing that, and are often disappointed that we don't have more complex components and patterns. Some mature teams have collaborated with our DS team enough that they're able to recognize which components are agnostic and mass reusable, and which are patterns specific to their product.

Yes

Consuming teams are gradually adopting the new composable components, with some still mixing old and new components as they transition. Feedback has been positive, with teams highlighting the system’s flexibility and ease of use. However, they’ve requested more examples of composed components to help streamline implementation. We’re working on providing these resources to support teams in composing experiences more effectively.

Yes

It's mixed. Some folks have requested more guidance for how to compose - and have even requested that we built more of this within Figma (as opposed to our doc site, where this guidance currently lives) but others want more flexibility. As we've matured, we've grown away from building specific spacing or combinations into the components and have instead tried to make them more composable -- but we offer patterns and guidelines to follow within our docs. We also rely on design leads within a given product/application space to codify the patterns for their specific space.

Yes

Guidance around patterns, and how to put together simple components into more complex experiences, is a vital part of creating a vibrant community around a design system. Equally important as the design system team indexing and presenting some existing best practices, is the encouragement to the community that the experiences they compose can be shared and scaled using the resources within the design system.

Yes

It's a mixed bag but we are doing things to help teams do better. We have hundreds of internal applications that use our design system and some of those are built by backend engineers who have no UX support. We have to do many things (documentation, office hours, training sessions, etc.) to bring teams along on the DS journey toward building better experiences.

I'm on the fence. I do see the efficiency gain but I'm concerned it might limit innovation

To me, composing components translate into patterns, and in a way robust experiences into collections of patterns that we may think of as templates.

We only offer guidelines to compose UIs from a rhythm, spacing, layout perspective but is very minimal, and we leave the rest to the designers that are the experts on their products because they have way more context to decide what would work best for their products and the users of their products.

Short answer is, not great.

I say this because the starting basis for our products is already composed, so it is very difficult for a designer to "re-arrange the furniture" because the current state is an accumulation of decisions over time.

This is a real struggle for any designer that is willing to innovate but gets limited in teir ability to make significant changes; which often results in designers shifting focus too narrowly to work on "micro improvements" at the component level.

For example, considering if a checkbox should better be a toggle switch, will never fix significant and perhaps more necessary experience related issues.

Yes

They create subsystems

Yes

We have an atomic system that is meant to offer the accessible components to compose an experience in both design and code. We offer examples, popular or complex to educate but also provide ready to use patterns as a great jump start for users. But gosh do our users find use cases we never thought of and that’s great but often breaks our components.

Yes

Sorry, using this space to clarify answers above because it's a complicated answer. Not explicitly a "yes" or a "no", but also clearer than an "I don't know".

Our team has had a designer working on designing of components, a developer (or two, at times) working on building those components in code, and everyone pitches in on writing documentation. We then have a parallel team that assists product designers in design and implementation. How is the best way to attack design for your product and what offerings from the system would best work given any specific instance or situation.

There's a bit more color, but I'll leave it at that for this context.

Mostly (and thankfully) by following design guidelines (aka wireframes) since the way components are used (at least on our team), is more of the designer's AOR (area of responsibility).

Yes

Our implementers often fall back to what is easiest for them to implement or use patterns that they are familiar with (either things they've done in the past or things they see in other applications) unless we explicitly provide components or patterns. It is a constant battle as new teams and designers are onboarded to our projects.

Yes

Historically we've been more focused on components, and individual teams are responsible for assembling things in their part of the product. As product complexity (and features) have increased, it has been a challenge to keep things consistent and we are thinking more about patterns (recipes) and page templates. One thing we've encountered early on is that it quickly shifts from a UI conversation to one of UX, and we aren't as close to the users as the product teams so it becomes more challenging for things to be owned by the design system when we don't have the insight to how things are being used or the specific problem a team is solving. The same components and composition can be used differently by different teams and for different user flows. We can do abstraction, but we're also trying to determine how we can uncover all of the patterns initially to do so. Shared patterns we have defined thus far are empty states, dashboards, and a settings view, but there are many others we know exist.

We offer web assessments that provide findings of current websites and provide recommendations that incorporate design system components. This helps to bridge the gap, but admittedly, the gap does not close completely with a web assessment.

Yes

Haphazardly having wildly variable results ranging from good to bad and expected to unexpected. IMO a composable system with good docs should steer people towards good and embrace the unexpected good while proactively trying to steer consumers away from the expected bad.

Yes

TBD

Yes

variably!

It lives in a separate, very detailed documentation, where we collect principles, good practices (we call them 'sayings') about how to compose experiences. It should be the foundation of the UX designer job to know these. Some very fundamental or very frequent can be duplicated and shown in zeroheight as a short guide (for example: use only one accent colored button on a dialog, not two or more')', but the detailed collection of our principles are licing elsewhere: and the ones who are writing it are experienced designers in that specific product and its functions.

Yes

They look at existing patterns or just use it in their designs. If it’s an incorrect usage, we will point out in design crit

Yes

prior experience - it usually worked well, and when it didn't issues often weren't communicated (ie make do, workarounds)

Yes

One off, on their own. We also have a separate library that is owned by another team and holds a bunch of “pattern” components, or compositions of our DS components

Yes

Currently they post in our support forum when they need help. For instance they use our base list components in react and Figma to develop custom list types.

Yes

Too often they do it each team for their own and in silos. There are a few examples where teams have collaborated and created their own shared storybooks with some light documentation on things like page headers. I’m encouraging others to follow suit and create a culture of systematic product building, documentation and collaboration. I’m hoping one day my team will have time to assist and build this culture. So far we haven’t.

Yes

They are currently making their own in what we call "expansion packs"

Yes

They aren't. After two years of advocating, our design system never made it to a staging environment for anyone outside of the engineering team to consume. In the past six months efforts to maintain and contribute to the system were deprioritized resulting in the decision to remove Storybook from the codebase. 🏳️😭🏴‍☠️

Yes

We've been starting to think about it but have no definitive answer yet.

Yes

By referencing our Storybook or finding other examples of how to use the component in our codebase.

Yes

We are transitioning to composable architecture and not all of our legacy components have been rebuilt yet, so some teams are actually composing basic components like selects/dropdowns while they wait for ours to be available. We are providing composition examples in our figma library/storybook for common compositions that we don’t want to maintain as components. We don’t yet have plans to provide more complex composition examples like forms, although some product teams are making them available in their figma libraries/storybooks for others to use. We do have legacy pattern/layout documentation and figma assets that are getting a little stale but teams still use them.

Yes

They’re using the atomic pieces from the design system, but using their own frameworks for composition. It definitely leads to some non ideal fragmentation and unnecessary duplication.

Yes

We handle the generic components and some of the global components like headers, footers, etc. It is up to the feature designers to compose those components in to composites for their features. Those are managed via separate libraries and UI kits. How they structure them is up to those designers.

Yes

We are just kicking off on providing more education and documentation on how to best utilize.

Yes

We offer a LOT of composability, but not all that much education around how to do it. I love that we have both a plain input and a pre-composed input-with-label-and-a11y-and-helper-text-etc component. This is one of the areas I think "design systems are just how we build UI now" is most clear: developers expect elements of various sizes that they can use to put together the feature they're building.

Interestingly, our dev teams very rarely use the atomic components and tend to default to the pre-composed ones. Usually this is fine, but I'd actually like to offer more education on how to decide (e.g. I'd rather see a composed UI than a bunch of style overrides on a pre-built component.)

It could be, depending on the needs and the maturity of the company and the DS.

Yes

Basically consuming some high level patterns with guidance and usage standards.

Yes

I believe the role of the design system—and by extension, the design system team—should align closely with the needs of the broader design team. For example, a team of senior designers may need less direct guidance, benefiting instead from having successful patterns documented in a central location. However, if the team includes more junior designers or a mix of experience levels, more structured guidance around patterns and best practices can be invaluable.

I realize this doesn’t fully answer your question, but I hope it adds another angle to consider.

Yes

n/a yet

It depends on how complex the component is but at a minimum, it shouldn't require synchronous meetings. Loom videos can help with education and successful distribution for consumption teams.

Yes

By consuming the component library and applying those components to their product experiences. In many cases, newer components or updated components are harder to remember.

Yes

They are expected to support their work in design tool or code editor with the documentation and guidelines of the components. We have tried to include there information where and how to use them.

But that is kind of a wrong place: You would need to know the first an ingredient to go to read how to use it, instead of knowing a problem/goal and read what ingredients to use to solve/achieve it. And from a component documentation page perspective, it just can't cover everything without becoming a total mess.

We do have some patterns/recipes but way too little.

Yes

Haphazardly.

Yes

Kind of haphazardly. Since there isn't education.

Yes

We provide patterns file that provide guidance around layout grids, spacing rules, sample templates, accessibility guidelines and responsive behavior.

Yes

Thus far, mostly only at the level of existing components. We do provide design tokens to hopefully assist in the creation of anything net-new.

Yes

We have some patterns to help but there is a lot more needed still.

Yes

We've developed a solid framework for how our teams are composing experiences with our design system. First, we provide comprehensive documentation through our zeroheight site, which helps everyone understand and effectively use the system.

We also hold regular office hours and record training sessions, allowing teams to get hands-on support and ask questions. After our monthly demos, we gather feedback through a one-question survey to gain insights into user experiences and identify areas for improvement.

Looking ahead, we’re excited to introduce template examples in Code Connect. This will create a sandbox environment where teams can experiment and build confidently with our design system.

On one side, no. I think a huge part of being a designer is learning how to design robust experiences to solve problems - design systems teams can't and shouldn't be teaching teams what makes good design and good experiences - that's a huge job that will definitely go badly if owned by any 1 team.

On the other hand, yes. Particularly in the space of patterns. Helping teams to create accessible, reusable experiences by leveraging common patterns or workflows feels like a fundamental part of a design system. Even the best design system if not understood or used properly can create awful outcomes, so a level of education is key to the systems success.

There's a lot of room for improvement. The system is newish, and has been adopted by a few verticals of the business to begin with. The business is 'well established' (old) and has outdated processes around design and development which we're slowly trying to unfurl. Designers have a very literal out of the box approach with the design system, and sometimes UX is impacted as a result. There's a huge amount of space for education both around UX and design systems.

Pretty much every company I've been in could benefit from a lo-fi wire framing stage to understand the core UX and navigation etc before moving to the system.

Yes

As more teams are adopting the design system and running into issues of composability, we add guidelines and instructions in our documentation to address those.

Yes

Different teams or designers will compose experiences differently based on their own research or usability testing. This creates inconsistent flows throughout our product today. It's a top priority of the Design System team to capture and document these patterns to ensure all teams are implementing matching experiences.

Yes

We have some rough guidelines around swapping nested instances inside of component / transclusion / interpolation.

Yes

It’s still a bit hard to gauge since only a few teams have been using our components so far. From what I’m seeing, though, they’re really looking for plug-and-play patterns they can drop in, rather than building things out themselves.

Yes

Honestly, I have no idea how they are doing it. I've had little exposure to watching teams using the system, instead I mostly just see the end result.

Yes

We, the system, provide several things:
- Showcase/Case studies - examples of layouts in our biggest products using the system
- extensive content guidelines for how to formulate content in experiences
- regular training on a variety of things - complex component construction how-tos, theming and variables, how to leverage guidance, etc.
- DOs/DONTs with visuals

However, through some ride-along research and years of anecdotal knowledge, we know our users still struggle with using Figma and therefore the system. So, we're looking to adjust our approach...
- do more team-based trainings
- host more video tutorials for self-service
- curate a list of best Figma tutorials

We also believe in more localized systems (pattern libraries, starter kits) that can provide patterns and templates for our products (leveraging the system to compose them), making that their source of ideal composition based on the product they work on.

None of the above has been seen through to completion though - lots of sticks on the fire right now, but no full flame...or some such analogy.

Yes

About 50% adopters use our grids

About 30% use tokens outside components, which we think are our biggest assets to offer standardized composability.

Less than 20% use our spacers, typography styles, datavis palettes, etc.

Only 10% use the DS fully in all their designs - and they make fantastic ones, fully themeable and cross-product integration friendly from the start.

Yes

We are trying to have people adopt and also learn how to use our system! Right now we are working on making an education strategy for sharing out information and training in both design/Figma and also designing with our system.

Yes

Nobody is using our system yet - we're about to hit our first release and start documenting how to compose patterns, like a site footer, built from a whole bunch of system components.

Yes

A lot of our consumers are trying to fit square shaped blocks into triangle shaped holes. A lot of our components are strictly made for certain use cases and not iterated upon.

There is next to no pattern documentation so there are no records on which combinations of components and foundational elements actually craft useful and meaningful experiences for our end-users. It basically means that the elements of the system can be interpreted in a lot of ways. Most of the time not the way the design system team intended it to be.

Yes

Designers and engineers are most often trying to solve legacy product problems by trying to "skin" or use the ds components 1:1. If they are building new products, it tends to be less DS-focused at first. Compositions / demos / recipes are often made as the DS team hears about teams struggling with implementation, or not understanding the UX of a component without more context.

Yes

Not sure really

Dont know

Yes

It's hard to know exactly - I'm curious to know how other teams monitor this as part of scaling effectively.

Yes

In a limited capacity currently as we are still building and releasing the first set of basic components. Teams are finding creative ways to mix the new design system assets with the legacy UI library to get the job done.

Yes

Based on guidelines, experience is designed

Yes

It's still a work in progress, but I think this is essential - it doesn't mean fhat we need to have everything made in modules and templates ready to use for every use case, because we might not even know all of them 100% well or we don't have them available yet, but I would like to educate designers to use our visual principles so they can made clear choices (ex: they know by heart that the spacement between the form and the button would be 24px).

Yes

Sorry, answered this already and forgot to register for the zoom

Yes

Some teams have formed local extensions of the design system that provide additional components, patterns, and documentation to help their teams build consistently. The more successful versions of this exist in large platforms where coordination of many teams is required to deliver a product. Without clear guidance and governance, these teams would struggle to create a cohesive experience for their users.

Where this maturity doesn’t exist, teams are often looking for guidance from the design system team. I believe this is where our universal truths can come into play—design patterns and usage guidance that is generic enough to be broadly applicable but also valid against a variety of experiences.

Yes

Right now, teams consume our DS as more of a component library. Picking what component they want and dragging them into their work. This is due to early stages of our DS but we have plans to offer more patterns and foundations to allow for more guidance as they consume our DS loving forward.

Yes

This is a really good question which I am eager to find out more about. I am new to not only my team, but also to working in design systems.

We are providing components with detailed documentation regarding best practices. I will try to look into how that is then taken by users.

Yes

Using their own per-product conventions. Some spacing design tokens are also available but it's not clear if or how they're using them. They're not properly documented.

Yes

Asset-wise, iconography is pretty clearly in a design system's remit but imagery and other campaign collateral is in the consuming team's control for me. Component combination guidance is an interesting one, I've often delivered guidance for what other, essentially similar, components could be used as an alternative but combination ideas have been limited to 'Frankenstein' page layouts. Where a wide range of related components that could be used in combinations all sit together on a page but would never or very rarely ALL be used together (often due to overlapping functionality).

Yes

Through the use of a pattern library - documentation outlining how components should behave and interact with other elements of the interface. An example being a modal sheet on mobile - how should it move in, can they be stacked, or should they be replaced by new modals etc - all requires consistency.

Yes

Currently subscribers rely on word of mouth for finer spacing decisions. Think the space between components like cards. This is a gap we are working on closing with the introduction of organisms. For larger spacing guidance, we do have page templates that encapsulate those decisions. This is great for net new work but can fall short when adopting older apps.

Yes

I typically consider the components as the engineers' toolbox and patterns for the designers. We've leaned into this by having insertable Figma components that are templates of a common pattern. Whether that's a specific dropdown menu, a confirmation modal, or an entire page layout. These are setup specifically to be detachable, but the goal is to start the designer with a common use case and proper configuration. The components are nested within, so any modifications they make should still be achievable in code.

We also have lots of documentation on general patterns with easy to follow dos/don'ts that folks can dive into if they want to learn more.

Yes

We provide page patterns for commonly used screens. Clients will replicate these or use them for inspiration when drafting new pages on their site. We also provide a list of most used component variations (including layout/bg colors) as the website evolves. A full user guide with video tutorials are handed over at site launch.

Yes

Drag and dropping elements on canvas, and detaching components if they don't know how to use it properly or overwriting the props thats they need to.
All of that is because of a lack of education on the tool (aka Figma), a lack of experience on the Design System (because of a lack of guidance/coaching) and ultimately, a lack of pair designing !

Yes

We offer insight into how teams compose experiences in things like correct spacing between components, accessibility guidelines, typography usage, and design patterns (such as composing forms or email templates).

Yes

We are pre-launching phase

Yes

We're in the Early stages but we are looking to offer configurations of components, especially more complex and content related ones as well as a set of patterns. These patterns will be a collection of common ways to reuse components based on larger UI themes like navigation or filtering. We also are looking to start the offerings of templates that can be copied and pasted for a quick starter design but ideally would like each of the product teams to own their own templates so that they can be empowered to maintain them as they see fit

Yes

Using utility and layout components, in combination with guidelines around patterns for specific layouts and types of compositions (e.g. forms). We try to provide just enough to be helpful but not overly prescriptive.

Yes

Because we’re a fledgling team, downstream product teams are doing more to inform good composition than the DS team itself.

Yes

We offer a combination of documented, guidance, office hours, and design

Yes

We are building out a patterns section, which is what I'm considering a "robust" experience--things like messaging, search, forms, filtering. We are constantly sending links to designers on the patterns guidance, even if they don't actually consume design system components, because there is still helpful information (like spacing, flow, labeling) they can use to create a more cohesive or robust experience.

Yes

We offer several types of support:
- content guidelines for experiences w/ focused topics for particular product-types or customer groups
- case studies/showcase - we put together sample flows/designs of our biggest products for examples
- visual DOs/DONTs as guidance
- ongoing training at different scales - from variables and theming, to how to compose complex components/patterns (e.g., card or carousel)

We find ourselves at odds on whether its our responsibility to train designers, in particular, on how to use Figma. They need to know or else they don't understand how to use a Design System and detach and blame the system for issues that are really their knowledge gap. However, we don't offer tool training to our engineers like that - its expected they should know that for their job. Interesting pickle to be in w/ very differing opinions.

The reality of how many designers put together compositions is leveraging old files and updating. Most folks work on an existing app, not a lot of start from scratch work. So, that can mean they are picking up legacy/deprecated/unsupported components in those old files.

We are going through a brand refresh, so our biggest apps will get an updated look. To support that we are gearing up to do a lot more sample work to guide folks on how to implement the new look and feel, since there won't be anything historic to work from.

Yes

We start from the outside in. So we tend to teach and help consumers understand pages and other “larger” or more “complex” receipts and once the higher-level concepts are known, we dive deeper into variations and available options through a suite of individual components.

Yes

Only a week into a new gig with a new design system so I have yet to find out; but hopefully I'll have clarity soon in this regard.

100

Yes

Consuming teams look to us for guidance when it comes to building experiences. My organization lacks designers so consumers, usually product owners or developers, are building rough wireframes and creating user stories before getting started building experiences. They rely heavily on the design system for things like templates and patterns that they can then incorporate into their application.