Episode 046 Raw Data

	A	B	C
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 46, deep dive hosted on February 20, 2025 with Ben Callahan and Brian Alfaro. There are 60 answers. The question this week was: ----- Hello System Thinkers! Welcome to The Question. This week I’m joined by Brian Alfaro as co host. In our conversations over the past few months, Brian shared with me that he has a background in architecture. As I asked more questions about how he applies the lessons of architecture to our work in design systems, he had some great ideas—one of which he calls, Vernacular Design Systems. Here’s how he explained it in writing: “...a design system should be a carefully crafted framework that addresses the unique challenges and opportunities of its product and its users. If we default to a one-size-fits-all approach—reducing our creative work to a series of adjustable levers—we risk producing digital experiences that are generic and devoid of character.” So, a Vernacular Design System is one that is intentionally crafted to meet the unique needs of the products it supports. This week, we’re going to pull at the threads of fully custom vs 3rd party design systems. Where is the value and how does the answer to that change depending on the organization within which you’re operating? Let’s jump in! Is your design system built from a 3rd party foundation? How often does your design system team collaborate with your brand team? In your experience, what elements make a design system feel truly 'local' to its product and user community?
2	Question 1: Is your design system built from a 3rd party foundation?	Question 2: How often does your design system team collaborate with your brand team?	Question 3: In your experience, what elements make a design system feel truly 'local' to its product and user community?
3	No	A lot of the time	It’s addressing the needs of the product instead of being full of what we think are “typical” components that a system needs. It means not starting your system designing a button but instead designing the highest usage and impact things that the products your system service can benefit from. It’s a mentality shift from owning a design system to providing a service that just so happens to be called a design system.
4	No	Never	Purpose built components already have an edge over off the shelf components in the fact that the features you do choose to add (if you are careful) will stem from direct user/customer needs. I'm working in the word of Enterprise software where sameness is a feature because it requires less training for the users to understand. There is a tradeoff between a UI being unique and being immediately understood. But this desire to not require any local training is also pushing toward all things looking the same.
5	No	A lot of the time	Matching the brand is an obvious one. For an enterprise company, consideration- not strict adherence- to its many users and having a "universal" foundation as guided patterns while allowing some flexibility to adapt and customize as needed.
6	No	Some of the time	I guess a design system feels truly local when it translates the brand visual language into a practical implementation of the design strategy of the company. If the system removes the friction between design and implementation aligning designers and developers together with business then it provides a common language that is local to the company.
7	No	Some of the time	Elements that feel 'local' are ones that are specific to our company or market use. Examples are things that are meant to be retail-specific (retail calendar) or product portfolio-specific (tech tools, properties or vendor experience).
8	Yes	Never	I think theming is the biggest connection point between design systems and adopting product(s). Allowing components to adapt to the visual aesthetic of various given products through design tokens, driven by Tokens Studio's theming capabilities. Starting in Tokens Studio allows automated export to Figma Variables, allowing designers to apply themes to different layers and literally drag components across and watch the magic. In code, its a simple toggle in Storybook to swap a reference to a single CSS file containing CSS custom properties with different values per theme that pulls off the same feat for engineers.
9	Some have, most haven't. But even for systems 'built from scratch', there has been, at minimum, a learning of best to move forward	A lot of the time	Ease of use (as determined by correct use and satisfaction by users) and the ability to adjust (and in many cases test) alignment to brand standards
10	No	Almost never	Unsure
11	Yes	Some of the time	Customization to the destination of its use.
12	Yes	Some of the time	There are a lot of implicit assumptions in the first two questions… Our code library’s foundation is Microsoft FAST, but only as scaffolding and testing foundation. Everything else, especially the design of the system was done with the input and partnership of our product design teams. Anyway, to the question itself - any element of the design system that answers a requirement raised by a specific product use case, is a “local” one. From a visual perspective it’s usually brand-influenced. From an interaction/usage perspective it’s usually patterns and templates, because those encapsulates functionally that’s unique to a product.
13	Yes	Almost never	UX patterns and foundations are often "mushier" than UI components-more room for interpretation. How this gets documented often parallels the questions that arise and repeat among a group.
14	No	Some of the time	Aside from talking to your consumers and collaborating with them: Being willing to lay aside what "other design systems do" and look at the problem through a product designer lens. Training yourself to every once and a while "forget about the system" and look at the problems your product teams are trying to solve. Ask yourself, "How would I design a solution for this problem from scratch?" Perhaps it results in doing what you would have done anyway, but many times I find I adjust my strategy to architect around the product's unique needs.
15	Yes	Some of the time	Infusion of brand via type, color tokens, and unique UI details.
16	No	Almost never	Input from the teams who own those decisions! (Like brand and consuming product teams) A design system CANNOT be the sole party responsible for experiences being perceived as on brand or "local".
17	Yes	All the time	Components that are unique to that product
18	Overall the system wasn't built from a 3d party foundation. However, our Eng team has struggled to define when they should build in-house from scratch vs. relying on an open source solution for specific problems or use cases. Within the front-end platform, 3d party solutions are repackaged, meaning everyone is on the same version. However, that has come at a price in the past where, the repackage falls behind the public version, especially when ingesting a new public version would create a breaking change. The solution become a proverbial fly in amber. Additionally, the thinking around when to rely on external solutions vs. when to build probably has been as consistent or evenly applied as maybe it could have been.	Some of the time	Writing style and tone, color palette and shape language are some of the universal elements that can make a system feel "localized." There could also be "sub-systems" that exist for a specific moment in the customer's journey, like the onboarding flow and first time set journey. These moments can be consistently tailored and iterated to meet the needs of users within that moment, rather than being owned by the more universal, less-opinionated federated design system team. Keeping these experiences with the domain experts who know these customers best, can help to maintain a personalized and responsive experience.
19	Yes	I say 'other' because we work with multiple brands with their own teams, not a singular 'brand team'. We work with each very closely and with brand consultants	No idea 'what elements', but I know we need to do more work to create a singular system that is capable of making a unique brand experience. Something not just 'skinned' but alive in its bones as different.
20	Yes	Almost never	Tooling that matches what consumers need from their components. Branding and content guidelines that are easy to follow.
21	We originally built it from scratch, but are now trying to incorporate MUI into our system. This MUI pivot was pushed on us by the tech director. I think it would have been fine to have started with MUI, but I think this is absolutely the wrong time to be switching to this. I think the tech director thinks this will be an easy way to solve our problems, but I think he is not understanding the level of effort to switch this out, and how much focusing on this is going to undermine our attempts at fixing bigger problems with our system.	We don't really have a brand team. We have a marketing person who occasionally works on branding with us, the design team. But she has a lot of other stuff on her plate.	In my experience working with my product teams, the biggest issues have come from our system not being able to accommodate what they want to build. When they want something, and we show them something similar but not as flexible as they want, they rarely go along with it. This has led to us both building way too many components, and trying to make components a lot more flexible. I think our team could have handled this better, but I think I've also learned the limitations of out-of-the-box, one size fits all components. Not sure that's exactly the question you were asking, but that's been my experience with this.
22	No	Almost never	A strong connection to brand elements like color and typography, components built specifically for the tasks users are completing, and bespoke design elements that make the site and applications unique to the organization, while still be familiar enough to other sites your users frequent.
23	Yes	Some of the time	In my case, a consistently updated Design System guideline could make this happen.
24	No	Some of the time	Core tokens, components and accessibility basic feel like boilerplate elements that most system share and could probably be done once I like when specific use cases for your product influence naming conventions for components and patterns. This can be some connection to the brand at the least and at best based on user voice and archetypes As technology changes and teams are growing and onboarding, it feels like they benefit from cutting their teeth developing a new language with their own design system. Frameworks usually contain elements that too general or rigid and teams build culture by creating something that aligns with their shared values.
25	No	A lot of the time	content, tone, color, patterns that formulate the right/specific user experience
26	Yes	Almost never	1. Signature components that the non-DS non-technical part of the business would immediately be able to name. E.g in a restaurant review website, the "Restaurant" component containing a hero image, some score, title, and metadata. 2. Loading states and transition styles are the easiest place to go "vernacular". While the static elements users read and interact with are driven by function and accessibility, transitional styles can prioritize the brand aesthetic.
27	Yes	Never	For me "local" is when people actually engage with it—when they ask questions, request components, and see their input shaping what gets built. Right now, the most natural way this happens is when teams come to us with requests or challenges, and we work through solutions together. That kind of back-and-forth makes Zest feel like a part of the process rather than something separate.
28	No	A lot of the time	2things for me 1. Where I sit, i am no longer under Product, I now sit under Digital Design direction which is our umbrella for content, marketing and, Product. This means I am closer to brand and some other users as well. 2. My org is a retail fashion brand, the brand feel and ethos is championed at every level. In the design system I speak the brand language that the users (product and content) need to be successful for their applications and have feedback loops about brand standards. The (ds) outreach and community aspect of support and operations become an aspect of the brand culture (or at least thats how i position it for peeps).
29	No	We have a branding team member who we collaborate with frequently but an external brand team that we don't collaborate with and instead get approval from.	Color and typography have the biggest impact for me.
30	No	Some of the time	Specific content recommendations for components
31	No	Some of the time	Though we have created many standard components (e.g., buttons, inputs, etc.), we have also created components that are tailored to our products' specific needs. In this way, our design system feels truly "local." These components were requested by our UX and product team members via an internal ideas portal and determined to be enhancements that would benefit multiple products within our company.
32	Not technically but we do lean on a lot of 3rd party foundations and principles with the intention of just getting something up and running- we can fine tune later	Almost never	motion, illustration, font choices, voice and tone, overall style assignments like colors, radius, iconography. I think basic components are fine to keep generic. I dont want to be reinventing a button, alerts or inputs. To me those are utilities that make the experience easy to use and help users achieve their goals. But there are things like motion and other custom visual elements that bring a brand to life that i think we should be focusing on like the ones listed above. The design system shouldnt be so far reaching that unique product or UI outputs can only be achieved through it - standardize what makes sense to from a systemic visual, efficiency, and consistency POV but leave creativity open to happen outside of it. Ive been in tax mode lol so going to use Turbotax as an example. Turbotax feels like turbotax and was so popular when it came out imo not because of the design system, but because their features make taxes easy to file, their copy is in plain language, and the product has elements that really support me along the way like the progress bars and refund estimates. The brand comes through via the overall color palette and style choices, but from a larger system level, the components arent "special". Theres others out there like H&R that now look super similar to be fair but i think thats largely because they mirror the product. Financial apps all look the same now too, but when cashapp came out, they stood out because of the simple UI, bold style and illo choices The design system to me is one of many levers to pull to make a product feel unique and vernacular. A special design system with unique components put into a product thats designed like one of the wordpress templates will still look boring. But if you can find a way to make sure the design system supports a creative and unique product vision, thats where you create more beautiful and non uniform outputs. its a push and pull collaborative effort between systems and products!
33	No	Some of the time	Align with the brand's energy and image. Custom interactions/animations can add character to a component that stand it out from other more generic systems.
34	No	Almost never	Tbh, I don't understand the question. What is local in this context and is "user" the consumer of the DS or the end user of the product? The problem with this framing, is i don't know if I'm supposed to answer from a DS perspective of "elements" that we've created that are unique to our product. Or if we're supposed to answer based on experiences interacting woth other products and inferring where the DS was involved.
35	Yes	Some of the time	The use of color and style. I think that when you can see the consistent use of shape, color and expression across different products and they look like they belong together then you start to get a sense that they feel local or related.
36	Yes	All the time	- How it came to life. Our new components come from specific use cases, and are made by brands who need them, and willing to share with other brands. - How it's been used/adopted by brands. Some brands modify our components a little, others a lot. The flexibility of customization allow brands to localized our components.
37	It was originally built on Bootstrap and BootstrapVue, but we've mostly moved away from that. It's been reskinned or vendored, but there are still connections to the past.	Some of the time	I think there are many things: - Visually, by being connected to a larger design language where the system is the brand expressed in the context of the product for a particular audience. - Leveraging and leaning in to particular design fundamentals that serve the content and data being presented and interacted with. - A library of things (components, patterns, documentation, et al.) that address specific needs rather than looking like a larger catalogue of everything that's possible or has ever been created. - Code that is tailored to the technical delivery/constraints and not just off-the-shelf. - Process that reflects how the "locals" will use it, not just how anyone might use it. A particular challenge though is having a product that is used globally and by users with a wide variety of roles and skill levels. Each workflow, feature, and technical implementation may require its own degree of localization and scalability. Maybe this is where a system of systems is sometimes needed? I'm not sure that's always the solution though, and instead a system can seem to feel less "local," but in reality it operates like a "choose your own adventure," having localized paths through it.
38	No	A lot of the time	Not only does the language within a system need to feel familiar to our user's, but so does the functionality and interactions of the components. For example, if I'm buying an average Subaru, giving it butterfly doors like a Lamborghini would be jarring and out of place. The same can be said about color; a chartreuse green Toyota Camry will turn heads, but likely out of confusion. The mental models set forth by the design system should be familiar and in line with the audience of a particular product. Adjacently speaking, similar arguments occur when it comes to the character of neighborhoods and vernacular building codes. Something that bisects the 'local norm' standards set forth by that community, tends to become an impediment to it's occupants. And when this occurs, complaints arise such as hedges that are too high blocking views, overgrown trees interfering with powerlines or simply the ugly color of a home that isn't in line with the neighborhood theme. The standards set in place are designed to create harmony and make a neighborhood feel like a whole. When it doesn't feel local, management must step in to correct the outlier. Home Owners Associations are the design system managers of a neighborhood. Their job is to listen and make informed decisions based off of the desires of it's occupants, which will continue to evolve as needs, resources and generations change. The same can be said about design systems. As user behaviors, trends and interests shift, so should design systems.
39	Sometimes, but it’s something we evaluate on a per case basis. We’ve used foundations from iOS and Material in our native components/frameworks, and we’ve used a few open source systems as starting points for our React components.	Some of the time	The phrasing here makes me assume we’re talking about monolith design systems? As many of us move to systems of systems approaches, or even simply a monolith that supports a handful of products/user flows/sides of a marketplace, it’s the recognition that each one of those experiences have different needs. Does the booking funnel reflect user expectations of e-commerce experiences across the industry? Are customer service agent experiences dense, and with an eye towards efficiency and task completion? Do our marketing landing pages employ more whitespace and vivid imagery? A great system should recognize those differences and provide the flexible glue that allows those distinct needs to family well together and adapt (as in the cases of multi-brands or white labeled experiences), and then feel unique to the brand.
40	No	All the time	A design system feels local when it aligns with user behaviors, reflects brand identity, and supports localization and accessibility. Flexible components and cross-functional collaboration ensure it evolves based on real needs, making it intuitive and deeply integrated with the product.
41	No	Some of the time	All of it. We are serving white label platform, so all our components need to support theming. In addition due to the ways our feature teams are set up, we need to produce components with aligned properties, property names etc to allow for quicker design work and easier conversions within feature teams
42	My organization has disjointed component libraries. Some are built with MUI or heavily influenced by it. But excitingly we’re at the start of an effort to build out a single cohesive DS	Product teams own their own assets and rarely collaborate. Hopefully will be able to change following adoption of the new DS	A combination of brand elements for the aesthetic look and feel (color, type, copy, etc) and design patterns. A button for instance isn’t going to create a memorable, unique impression, but the experience of interacting with that button within a larger pattern, like completing a task, onboarding, etc will.. or that’s the hope :)
43	No	Some of the time	Having examples or documentation that is relevant to your content and use cases.
44	No	All the time	Underlying visual language principles that feel conceptually connected to the product experience, needs, or business value
45	No	Almost never	Our teams have worked in silos for years—the graphic designers sit with the brand team, while UI and UX designers are elsewhere. But as the brand evolves, we're making a conscious effort to collaborate. It’s early days, but I believe better communication will be key to ensuring our design system truly resonates with the community.
46	I've built/worked on both use cases	As an engineer in our company I have had little insight into this	I find the uniqueness come out on more robust or complex molecular components that are at or approaching the recipe level in the ecosystem. Lower level components are where I see less diversity from other systems
47	No	Some of the time	By involving everyone is the creation and naming process and how to use the design system
48	No	Almost never	The design systems I've worked on never truly became 'local' until we bent the curve of "UI library". While we were designing and building foundational components, it felt just like any other design system. As soo as we started working on case specific, bespoke components, we all felt like we had proper ownership of our system.
49	No	Some of the time	Unique components that support your product's needs and reflect your users' expectations.
50	No	Our design system is separate from our company brand, so the Design System team takes care of consistent typography, colors, etc. The design system is used for many applications that aren't necessarily related, so logos tend to depend on the company we're working with.	Customized for the users of that particular product and for particular roles within that product. Some of the standards for that product will be determined based on the user base's familiarity (date and time formats, terminology, work flows).
51	No	A lot of the time	My initial reaction goes to theming or webcomponents.
52	Yes	I'm not sure; it's not totally clear because I actually don't get to be close enough to it anymore. The system based on Material is a power play.	It's complicated. You could totally make a case for the fact that it's a stylesheet or set of tokens, but creating and owning your own code base feels pretty essential to me (as not a developer...).
53	No	A lot of the time	A engaged and stable commons community library.
54	Yes	I'm currently working on an 8 week project for a nonprofit that doesn't have a brand team, but has a co-founder with a background in web design. Separately as part of the volunteer effort there is a product strategy team that has been working on branding with them but none of the vision strategy seems to be reflected in the design feedback my team has received from the co-founder	Matching the voice of the community. Occasionally I've been asked to drastically change the overall feeling of a system, for example when a 75 year old bank wanted to be fun and chose the same brand font as a makeup company targeted to teenagers and young adults. As I applied this new font throughout, it and the other fun, modern changes (colors and patterns) just felt like a mask. In my current project, the client is insisting on a New Brutalism style for an organic, sustainability service while using a palette that doesn't match Brutalism or sustainability and clashes. Everything about it feels mismatched for the audience.
55	No		How things are structured in the files, naming of things and the docsite can be a personal spin on a system.
56	Not for design, but in code there are some component-specific dependencies under the hood.	A lot of the time	Shared art direction across brand, product, and systems teams.
57	No	A lot of the time	Styling like typography, color, imagery, illustration, iconography, copywriting, spacing, and any unique interactions or controls that are core to the product experience.
58	No	Almost never	I think its just the specificity of what our products need and how our designs need to be flexible to meet their needs. Our products are very data heavy so we need to be very careful with how we handle hierarchy in our system.
59	No	A lot of the time	A design system extends beyond brand alignment and scalable componentry—it embodies the organization's culture, principles, and the character of the community it serves. When a design system genuinely feels “local,” it reflects distinctive nuances that generic, off-the-shelf libraries simply can't capture.
60	3rd party? Like Material? Its a mix. Custom components for brandable moments and cross platform consistency. Theming of iOS and Android to fill in the gaps.	All the time	Brandable moments. Identify the key attributes, interactions, key moment that are key the product and brand experience. For PayPal, the currency input for example ( Did the current live version nail it? No. But there is extensive internal ideation of ideas.)
61	No	All the time	The design guidance given is usually specific to the products it serves. Examples should reflect common things that the teams using the system are trying to support. The system team needs to understand which products they should prioritize as the main users as its important for how you communicate out about the system.
62	Yes	Some of the time	Design System that reflects specific behaviors that users perform within the product. Elements that are common in the product for users to interact with.
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