Transcript
Chris Strahl:
Hi, and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code, and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us @TheDSPod. We'd love to hear from you.
Hey everybody. Chris here with the Design Systems podcast. I wanted to let you guys know that we're doing something a little different again this week. We have another two-part episode. This actually started with a conversation on LinkedIn where I was talking with several folks in the design systems community about design tokens. There were so many interesting takes that were happening we decided that we all wanted to get together and sort of do a panel. This is going to culminate in an actual webinar with all four of these folks on April 26th, but we're going to have some exciting announcements about changes in design tokens and some software that we're going to provide for the community with Knapsack. With that in mind, this is the first of the two parts. We're going to be talking with two folks this episode and two folks next episode. So you should be able to start with either one. I hope you enjoy the show.
Hey, Amber, how's it going? I'm here with Amber Stickel. She is over at Intuit. Why don't you explain to me what you do there because it's a bit of a mouthful.
Amber Stickel:
Yeah. So I am the principal design technologist on the Intuit design system team. So essentially, our core design system team that empowers and enables our other design system teams.
Chris Strahl:
That's awesome. So a big part of your role is working with tokens. Talk to me a little bit about how you all use tokens, what that kind of structure exists inside of the Intuit design system landscape.
Amber Stickel:
Yeah, it's a loaded question. So essentially we do have tokens and it's a really core part of what our team does. And so we actually have a product development team of six engineers, web engineers, and they are focused solely right now on building a editor experience for our tokens. And so I would say a lot of what we do is very token-focused, and that can go from working directly with design systems teams. So we are the core design systems team, but there are other design systems teams at Intuit. And so we will partner with those teams to help define the layers of tokens that they want to use in their product. We typically have three layers, primitive, semantic, component tokens. So we'll partner with them on maybe the semantic component tokens and how that relates back to our Intuit theme. But then we also, again, create tools like our Figma plugin, so it's easier for designers to find and discover tokens as well as our VS code extension for developers to find and use tokens.
And then we also, as I mentioned, have this design data management system that is its sole purpose is to kind of help designers contribute to tokens in a more easy way outside of GitHub and then publish that and distribute that to all of our system teams.
Chris Strahl:
Gotcha. So this is what a more mature setup looks like for tokens where you guys have layers of the onion, you have data, you have things that are particular apps that serve engineers, things that are particular apps that serve designers. Tell me a little bit more about what those three levels of tokens really mean.
Amber Stickel:
Yeah, a great question. And so to your point, we are a mature design systems team with, again, other design systems teams that we enable. So our scope is different than just being one soul design system with one product. And with that, a lot of the work that we do is foundational, which is why they're such an emphasis on tokens and those foundational components that are carried across each system or product. We have three distinct layers or tiers of aliases of tokens in our system. And as I mentioned before, there's primitive, semantic, and component. And really we have those layers because it's defined by two different dimensions, like precision and coverage.
So for example, our primitive tokens, we call them literal tokens at Sprout, the team that I was on before Intuit. But those are your blue 700s, your size 4. They're more precise than hard-coded values in the sense that they do at least tell you some relevancy to the system. So instead of 20 pixels for your sizing, this will say size 5 based on a four pixel basis, so 20 and 5. So it does give you a little bit of context in terms of how it relates to the system, but there's really no precision beyond that which enables this large range of coverage, right? But then it's limited in theming, so you're not able to, again, make those quick changes.
And on the inverse of that are our component tokens, which are very precise. It will tell you exactly where to use this token. So you might have a token for button background default, right? That can only be used... Again, the precision is very specific to button components. So the coverage is limited, right? Again, only to those button components. And semantic tokens, we have that layer to really be that sweet spot between the two. That's really to allow our design and development teams to build more quickly with purpose. So it's that balance of precision and coverage. Again, we're telling folks when to use a token or the intent of that token, so like UI primary, but we're not being so specific as like, "You must use it in this component." And so that really allows us for a larger degree of coverage. And so that's kind of how we think of our token tiers on the IDS team.
Chris Strahl:
Yeah, it's interesting. There's all these large scale systems of systems concepts that come into play when you start to think about a mature scalable design system. Oftentimes, the battle is more about "Where do I strategically insert fragmentation into my stack?" versus completely trying to eliminate fragmentation from it? Because you still need to have this idea of, "I have a particular use case for a particular thing. How do I serve that particular need in a way that is specific to that scope, but still provides a systematic approach to that particular problem?"
This is a really interesting idea, I think, applied to tokens too, because very often we think about tokens as being synonymous with brand. And so tokens and brands, they're very, very deeply related, but they aren't necessarily the same thing because that brand expression happens at all different levels inside of your design system. I think it's a really interesting way that you've described with those primitives, those really baseline tokens up to something that is very specific to a component. And that ability to say, "We're taking a systematic approach at every one of these levels" is a cool concept as it relates to that sort of systems of systems thinking and brand. That's something that's not really a very commonly talked about, is when a brand expression happens, what level is it happening at and what is the specificity that I need for that particular moment?
Amber Stickel:
Yeah, absolutely. I think one of the challenges on our team as of now is that again, we are the Intuit design system team. And to your point, that we have multiple brand design systems teams that exist. And so it's even more of a challenge for us to define those tokens because we have to be very cognizant of... Again, we're not even the immediate design system team that a specific product team would be using, right? And so we have to build in that specificity that can apply across all of Intuit, but also be flexible enough for these brand teams to express themselves using our tokens in our system in a really flexible way.
And so yeah, some of the things that we're actively thinking about right now is, "What does theming look like at Intuit? How much of the experience should be based on the Intuit design system system versus how much of it should be tailored to brand expression? Are we a house of brands or a branded house?" And so I think those are some of the questions that we're asking, especially with the fact that we do have companies and products that we've acquired MailChimp that have their own design system. And so for example, their buttons might be traditionally rounded, bordered radius where ours are typically more square, maybe like a 4 pixel border radius. And so if you're only thinking of theming or tokens in color, you have to be flexible enough when defining these levels of tokens to allow for that brand expression and flexibility to change while also still preserving that Intuit experience and those tokens, if that makes sense.
Chris Strahl:
It's funny. You grab the button, which is literally what I was going to talk about. I mean, we're an Intuit customer. We use QuickBooks, we have MailChimp, we have all sorts of things. And so when you think about what is that most primitive experience that represents Intuit across your entire organization and how that ultimately relates to brand systems that represent the TurboTax or QuickBooks or something like that, how do you guys look at that relationship now, or are you defining it? Because what I heard you say is, "Oh, we're a house of brands or a branded house." What relationship does that conversation have to the token strategy that you're working on now?
Amber Stickel:
Such a great question. So again, I think there's this philosophy that we are working on as a design organization all across Intuit of determining are we a branded house or a house of brands? And that would obviously affect both product and marketing. So if MailChimp were to use our typeface or use our branded color palette, that is extensive enough to go across all of these products. So those conversations that are kind of happening at that philosophical fundamental level as a design organization. And then that directly impacts the level of flexibility that we want in our system, which is always a fine balance, right? But when it comes to tokens, one of our principles behind our tokens is being iterative. And so we're constantly evaluating our tokens at each level to make sure that they are flexible enough for all of these use cases. So color is something that we're actively working on. We've released a color 2.0 palette, but we then recognize like, "Okay, is MailChimp being represented here? Credit Karma, all that flexibility there." And so that's something that we're actively working on now.
Chris Strahl:
That's really interesting. I love the idea of a simultaneous strategic conversation about how is design viewed through a strategic lens at an organization level, pairing that with decision making around how you think about that expression in design and code at a very practical level, because systems are innately strategic based on... Like look, if you're defining a system for something, it's going to impact an entire company, an entire brand, an entire organizational unit. Thinking about that relationship of strategy and systems is not necessarily where I thought this conversation was going to go, but it's super cool because what you're basically saying is, "I'm making a balanced decision between my implementation of my brand and what we're going to view brand as a company." And that's super interesting.
Amber Stickel:
Yeah. And we kind of have to, because we do have so many strong cornerstone brands with their own expression. I mean, if you even look at the traditional Intuit cornerstone brands of QuickBooks and TurboTax, they both express themselves very differently. And even organizationally, they operate very independently. We want to promote cohesiveness, but we're not mandating that people have to use our tools and resources. We want to make it so tantalizing, and again, ideally strategically that these brands want to be part of this Intuit experience and use our tools and resources. So I feel like it does play heavily into adoption at least in the context of our system, because if a brand like TurboTax wants to be very independent, then they may not need our design system as much.
Or again, even thinking going back to tokens. We have to then plan, "Okay. How much of our tokens... Again, what level of fidelity do they differentiate on? Or that layer of abstraction. How many different types of properties can they iterate on or expand upon? Are there some things that are, we call durable, that are tried and trued and tested and they're very much part of that Intuit experience?" Whereas if TurboTax is very insistent that, "Okay, it's not just color or color teal or color red. We also want to have these rounded border buttons or this different layout, et cetera," that all can affect again, that implementation because we're not only thinking about the types of tokens or the names of tokens or how many tokens, but we're also thinking about how are those tokens distributed and how do we keep them in sync with the changes that we make to our fundamental design language? It does play a heavy hand in implementation.
Chris Strahl:
Right. Because now if you're having somebody automatically inherit a brand or a set of decisions about their brand, it feels a lot more like a mandate than a choice.
Amber Stickel:
Right. Exactly.
Chris Strahl:
Now, I love the way you think about this sort of big picture idea down to the implementation. You were talking about keeping things in sync. Most of this conversation is centered around the design and strategic decision making when it actually comes to the implementation in product. Talk to me about some of the strategies you all use to keep that in sync, because now we're talking about design to code, the eternal problem of, "How do I take something that looks great in Figma or looks great conceptually?", and that intent is well expressed, and then actually make it so that the thing that shows up in front of users is representative of that intent.
Amber Stickel:
Right. In the context of tokens, something that we are building is our... Well, we've already built, it's called our design data management system. And so that is really our single source of truth for our design tokens and the distribution of our design tokens. And so we actually have a repository that uses Style Dictionary to actually output and distribute these tokens. Each theme has its own directory. They all are based on the Intuit theme. And then each team can then create their own directory and overwrite specific semantic tokens. Those semantic tokens then are mapped to our IDS component tokens. And so if they're using a theme provider or theme wrapper around the IDS tokens and they're declaring again the MailChimp theme, you'll see those semantic overrides within the MailChimp theme apply to our IDS tokens.
The publishing experience, the contribution experience, and the deployed experience, the build experience is something that we're actively reinventing right now. And so as I mentioned before, right now if you wanted to make a change to tokens, you would have to do it in code first. W do have Figma plugins that would then take those token changes and generate Figma styles in a library and then you could publish it there. You could take those tokens that are declared in GitHub, generate those Figma styles using our plugin, and then publish your library with those token changes. But essentially then you're still limiting the token definition or token source of truth to one specific tool of one specific discipline. And so we're actually building an editing experience that is in a GUI, a graphical user interface. That would allow designers, product managers, developers, anyone with a certain permission to change these tokens would be able to do it in a source of truth that's outside of a tool. And that would be then distributed at the same time across Figma as well as our GitHub repository that can go into all the resources our engineers need.
Chris Strahl:
No, that's really cool. I like the implementation idea of very clearly defining what you can change and what you shouldn't change. And then moreover, this idea of how do I create some sort of abstraction that isn't just a JSON file? I mean, I fundamentally... Look, Knapsack's taking the ground. It's definitely, you should edit your design tokens in code because there's a lot of things that are represented as tokens that you can't show as a Figma style. And so when you think about animation tokens for example, or tokens that reflect anything related to state, those are very, very difficult to show in a design tool. But likewise, you as a designer need to be able to understand and manipulate those things. And so what does that UI look like that allows people to change the basic bits of the design system in a way that doesn't require a deep understanding of how one particular tool works? That's democratization and that's super cool.
Amber Stickel:
Yeah. And that's essentially what we're trying to build. And so again, this custom experience would allow users to go into a particular theme, see all of the tokens across those different properties, and then actually see previews for those tokens as part of the experience. And so again, if you change the token color, you'll see that color represented right there. And to your point, we would have examples for motion. So if you change the cubic bezier curve of a specific token, you can see that animated with an example component that we have. So actually, we're very mindful about, "Okay, when you change the token, here's how you're going to actually preview it." And maybe not in a traditional... Again, you're maybe not going to see... Because the experience is very much at the semantic layer or the primitive layer as of right now, so you'll see it in maybe more of a generic component sense. You'll maybe see a little element that will zoom across your screen quickly, right?
Chris Strahl:
Right.
Amber Stickel:
Instead of actually seeing it on an IDS component. But at least to your point, we are using code to visualize the design in a way that is not supported by a design tool. And that's kind of like the goal, is we want to, again, democratize this so it's not specific to just one engineering tool or one design tool because those things change. We want to really make sure that this is an experience that anyone can use without having to limit ourselves to a third party's features.
Chris Strahl:
That's great. Well, hey, Amber, thank you so much for taking the time to chat. Really excited to hear about what you're doing and really appreciate you sharing all that great information with us.
Amber Stickel:
Great. No, thank you so much for having me. This was awesome. It's an honor to be here.
Chris Strahl:
Awesome. Well, hey, talk again soon.
Amber Stickel:
All right, sounds great.
Chris Strahl:
Hey, I'm here with Taylor Cashdan. Taylor, you're starting a new career pathway, but let's hear a little bit about where you come from and why we're chatting.
Taylor Cashdan:
Yeah, sure. So I've had a little bit of an interesting journey landing into the design system space, did some work in the brand world, in the marketing world, and that teetered into UX and then kind of fell upon systems during my time at Fidelity Investments. So imagine massive enterprise kind of system program. I was there for about three years working on their core experience platforms and design systems, and then took a stab at the startup life and joined another organization called Hologram, doing their design system stuff. And here we are.
Chris Strahl:
Awesome. Awesome. I wanted to chat with you today because I think that you had sort of the spicy anti-take on design tokens, if you will. Not that you're not a believer. You have a very tempered set of expectations, if you will, about this. And so let's talk a little bit about that. What is it that has kind of got you, I mean, I don't know, down's not really the right word. What's [inaudible 00:18:40] so that you're a skeptic on the value of design tokens?
Taylor Cashdan:
Yeah. I think it's less skeptic. It's more cautiously optimistic. I put it that way because I think a lot of things in our space, design systems, is very new and fresh and evolving. So I hesitate to put all my eggs in one basket on just about anything because at any moment, the frameworks can change, the approach can change, whatever. So my optimism that is very cautionary in design tokens is that I think they're very powerful in the sense that they provide an abstraction layer that can help normalize the way we talk about certain design decisions, search in engineering practices certain attributes of the interfaces that we build and produce and support. But what I don't like is oftentimes they're sometimes spoken about as some magic wand that's going to fix a bunch of things in our UI and inside of our UI kits and inside of the component libraries they support as if you have design tokens, you no longer have problems, whether they're accessibility, whether they're theming, whether they're break points, whatever. They're just another fantastic tool and they need maintenance and attention and thought just like anything else.
Chris Strahl:
So is this about then the construction of the idea of tokens as like a construct, or is this about the inflated expectations and we haven't quite reached that valley of disappointment yet?
Taylor Cashdan:
Definitely the latter. I think it's mainly because like all things in this space, there's a lot of newness to it, and we're still trying to figure out where the start and stop is of all the things. That also means there's a lot of new practitioners in this space who are latching on a little bit to things that are shining and new and effective without truly having a stance yet on where that should stop, right? So that means when talking to leadership, when talking to managers, when talking to consumers, sometimes we oversell the power of the tool we're putting together because it haven't hit that outward bound, that constraint you're talking about yet. I fear when we talk about things as the game changer of our space, that we're overselling a little bit or getting to a point where like, "Yeah, kind of, but not really."
Chris Strahl:
Gotcha. So in your practice, where have you seen things fall down and where have you seen things work really well? So if you were to sit there and say like, "I could wave a magic wand and reset expectations for us," what would you put out there into the universe?
Taylor Cashdan:
In the context context of design tokens, I would say they were a very powerful way to normalize the way we talk about certain things. Like design tokens make it really easy to say, "All right, we never have to remember hex values anymore," or "We don't have to start to think about what's nested in a particular class name that we didn't realize." They can be as specific or as generic as you want. And because there's layers of abstraction inside the way we use design tokens, you can create or mitigate as much complexity as you're prepared to maintain, right?
And on the other side of it is I think there's kind of two aspects of design tokens. There's the maintainer side and then there's the consumer side. The maintainer side, oftentimes we'll be way more complex. We've got dependencies, we've got that... I'll just use color as an example. We've got the hex value that leads into the red 4 that then leads into critical alert and whatever else it's paired with. But that we have to remember to be very careful on like, "Well, we don't want to just add tokens to add tokens. We want to make sure they have intention and they're put there for a reason and we're not putting a dependency somewhere using that alert red inside of something that isn't an alert because then when we change the value there, you know what happens."
But then on the consumer side is making sure that they feel comfortable and we help with that culture change, that they don't need to think about the hex value or if it's even red 4 that we go, "No, no, no. You're building an alert or something that needs that alert-esque feel, go for red alert color or whatever that token value is." Don't think about the pallet swatch anymore. You don't need to. I think that's very uncomfortable for folks, especially consumers who aren't spending their time all day looking through tokens and understanding their value and their dependencies, right? They're just on the other end just grabbing something that we're shipping to them. And without that educational layer, it makes it really tough for them to understand or want to even use the thing in the first place.
Chris Strahl:
Yeah, it's interesting. There's a lot of thematic in these design token conversations around the idea of where you strategically introduce fragmentation into your system. So we're all thinking about systems concepts, we're all thinking about the way that we structure, like per your conversation about the consumer right, how to make life easier for those consumers because there's systems in place that help either constrain their decisions or make a lot of the decisions for them that they're not the right person to make that decision. That strategic introduction of fragmentation in a system, thinking about it, the very, very complex token level, there are a lot of people in the design system space that believe that components are just constructs of tokens where, "What is a button?" Right? A button is a grid, a fill, some colors, some typography. And maybe the one thing that doesn't fit neatly into the token box is the inclusion of an icon or something like that. But even that could be represented as a token.
And at that lower level thing, like taking atomic design to its extreme, everything should be represented as a set of tokens. And then there's this other idea that tokens are limited in their appeal because you end up in this esoteric layers of abstraction that you were talking about earlier where the complexity of that for maintainers becomes something that's then generally untenable. And so in this balancing act that we do there, we have to kind of decide where do tokens stop and where does the rest of the system begin? And I think that what I'm hearing you advocate for is like, "Look, serve the needs of your user, your consumer of that token, and really focus on that and don't worry so much about the abstraction that you put in place being this perfect elegant system."
Taylor Cashdan:
Yeah, I think that's a fair assessment. I think the two things that I'd say on that is also that whole atomic nature of things is no different than the way we can construct HTML and CSS. These aren't new ideas, right? These aren't new concepts. They're just a different way to do them. And on the other side of that, you can add or mitigate as much complexity as you want. I think what happens more so is that folks spend too much time thinking about the intricacies and then not delivering value to their consumers. Now, I think the other thing to mention there is making sure that as practitioners, we're being very mindful about those undoable decisions, right? We don't want to create a fork somewhere or add an abstraction layer that we can't mitigate or work around later, or that forces us into some corner. So that's often the threshold of decision and an easy one to say, "Well, when do we add a new token?"
A lot of teams should have what I tend to call an additive threshold. It's not a term that I coined to be clear, this is something I've heard somewhere else. But it's deciding this particular value has to be used across say three things before we tokenize it, and at that stage is when it becomes a token. And guess what? That means if those other two things, or more than that for that matter, are not using the token, when you ship said token, you will have to go back and possibly refactor them or add that token back in. And that's normal and healthy behavior. That's not as bad or as breaking as I think folks are scared of. The more things we evolve with our systems, the tokens, their architecture, the tokens we provide, the other things that it supports need to evolve with it, and that's healthy behavior.
Chris Strahl:
Yeah. And that incurrence of that little bit of design debt or technical debt as a part of introducing that system, I think that that is a cost we should recognize, but it's also a cost we should be willing to pay. And like you said, I think mindful is probably the right word there. Be mindful that you are incurring a debt, but at the same time that debt should allow you to reap the benefits of that systematic approach for months or years to come.
Taylor Cashdan:
Right. And there's ways to do that so that it doesn't blow up your end user's experiences or your consumer's work, right? You can do that, number one, by over-communicating, "Hey, next month we'll be shipping this token work we just finished. We're waiting a month so that you can prepare for this version bump, this breaking change, this whatever." And then also making sure that you have some form of a regular shipping cadence so that you're not sending breaking changes four times in a week and your consumers are like, "This is ridiculous. I can't even use this anymore. It's too complicated. They're shipping all this stuff that's busting my stuff. I can't. I can't," right? And then you lose advocates.
Chris Strahl:
So all that said, I am curious, what do you see in terms of the future of tokens with that sort of skeptics take, that cautiously optimistic take, that is really exciting about this technology? Because I think you are excited about it, you use it yourself. There are parts of it that are very practical. What gets you into that peak of inflated expectations?
Taylor Cashdan:
Yeah, I think when the design tools themselves catch up with the advancement that the developers get to take advantage of, we'll have a nicer harmony between how we use these things, where we use them, and why we use them. There are some plugins, extensions, extra tools you can kind of add to whatever design tool you're using at the moment to kind of make it work, but none of them are great. I don't mean that the tools themselves aren't great. I mean that they won't work in every organization for every team at every level. And that makes it really tough because you see all these concepts that are really cool and you talk to your engineers who are used to this variable value pair situation, so you give them a new framework, a new idea to use, they're like, "Cool, I'm already used to this. I can integrate it in my tool suite. No problem."
You tell that to a designer who's used to using layer styles no matter what tool they're in, you tell them, "Hey, no, no, no. Actually, don't use that thing you're used to that you've been using forever. Don't ever use your ring dropper again. Don't remember your hex values anymore. Now you got to remember this really long string of text that we're going to tell you because it makes it easier during handoff or it makes it easier to codify a decision." And they go, "Yeah, hell no. I'm going to keep doing the thing that makes me performant because I have deadlines. I don't have time to relearn your new weird structure thing that you decided is better for us" kind of thing. And that's, I think, a gap in the tooling than it is the people.
Chris Strahl:
Yeah. Well, I think there's a lot to be said about gaps in tooling, right? I think that this is the ever-present lightning rod of pain, which is that design to engineering handoff process, the devil's tennis match of reviews and oftentimes finger pointing about why something in design doesn't look like production. I think the reality of that is there's a lot of things that are very hard to model inside of design tools that introduce artificial constraints into our process. That is an interesting problem. So take states for example, modeling states inside of a tool like Figma is extremely difficult. Modeling states in code can be relatively trivial. Likewise, animation and lots of other different things that are present that are challenges here. And so the thing that I worry about with I guess my own value of despair after inflated expectations is that our design tool is ever going to be adequate to express this stuff.
And I think that the challenge that you have is there's kind of two things that are happening right now in the design space that I see, is you get a lot of designers that are designing for other designers, the whole Mad Men thing of don't write for other writers, and then you have this other side of it, which is that because designers see that their beautiful work is not translated perfectly into a production application, you actually have designers being less ambitious about the things that they're creating because they know that what shows up in production is not going to be as good or as complete as what they built in a design tool. This is really bizarre effect of making our products worse. I wonder sometimes how do we push back against that, right? Like if it's about better design tools, is it about designing in a different medium? What do we see as the net of how we solve this designed to code crisis?
Taylor Cashdan:
It's interesting. Two things came in mind. Number one is that I have faith, to be clear. I for the longest time was against browser-based design tools. I was like, "I want an app. I want to be able to use it and I want to be to isolate my work into this space and never touch a browser because my browser tabs are a mess and it's always bogging down my RAM. So if I put another thing on there that's my work and it crashes, I'm going to be pissed." But the more and more I dive into this space and I understand the ecosystems we're building for, the more confidence I have in thinking that like, "You know what? Maybe some of these limitations are because we're expecting this standalone thing that's not really in the world we're building for to do things that it can't."
What I mean by that is I'm wondering, and I'm no engineer so I don't know this for sure, but I'm wondering is if we continue to index on browser-based tools, if it unlocks a lot more things that we weren't able to do at a separate app level, maybe integration of things like tokens, maybe being able to really view what Dreamweaver promised all those years ago, being able to see your design side by side with some sort of sample, right?
Chris Strahl:
Right.
Taylor Cashdan:
If we're in the end place, maybe it'll help us get there and maybe that'll bridge some of this angst and this gap on what tools we're able to provide today. But you hit on a little bit of basically design degrading over time based on either designers' perception of limitation or that they shouldn't do something because it's not capable. What's interesting is I have one of those strong opinions loosely held hot takes of that's supposed to be there. Design is not art, right? Design is intended to solve a problem. We don't need magical, beautiful landing pages for every area of an experience. If I see another thing that's like, "I'm going to reinvent the way forms are done, I'm just going to quit." No, they should be simple, easy to parse through, logical from end to end. And you know what? The same everywhere. We should not be surprising our users on the different way of form field looks when they've done forms a thousand times elsewhere and we're just asking them for simple information, right?
You want to bake in some nuance and some beauty and some [inaudible 00:31:59] to the way your dashboard displays data or the way your button animation works to make it a little more lively to your brand? Fine, go for it. But let's not over-index on the artfulness of things when we're trying to make sure that this is a binary interaction with our consumer, they're inputting information, they're moving on, they're spending little to no time on the place we're spending all of our time, and that's a problem.
Chris Strahl:
Yeah. So I think that that opens up this entire other interesting line. So we have a bunch of mundane stuff that happens inside of that design process, right? All those mundane things that we build right now, do we need to model those in design tools or can we just have an AI grab hold of what a form field is and make that for people? I think that this is where the interesting emergent frontier is happening right now right before our eyes is we're watching somebody be able to hold up a cocktail napkin sketch to a camera and have it make a webpage based on that. Now, of course, it's a far cry from like, "Hey, I made some HTML and CSS that looks like that cocktail napkin" versus like, "Hey, this is a production application that works for millions of users." But at the same time, a world is coming where at least those mundane decisions should be able to be largely automated.
Taylor Cashdan:
Yeah, I think there's two pieces there. Number one, I think people have forgotten that this AI computer generated machine learning stuff has been around for a lot longer than we're willing to admit, right? If we remember when Content-Aware Fill got added to Photoshop, guess what powered that? It's looking at all the information around and it's taking out elements of your image that you don't want. It's been there for a long time.
Chris Strahl:
This whole conversation's taken me back in the Adobe ecosystem like Dreamweaver. I love it.
Taylor Cashdan:
Well, it's such an easy, massive thing to reach for, especially for designers who have only lived in that world. I went from Quark into PageMaker, into InDesign. And then from then on it was Adobe or nothing because they were the only ones that were supported across multiple ecosystems. And then Sketch became a thing and Figma became a thing. Now Adobe's buying Figma. So it's like all this stuff that's just making the world kind of loop around. But when we think about the AI impact on work, I would argue too, it will in some ways simply support the touchpoint, the cornerstone of design systems work, and that design systems should handle the boring things, right? Maybe AI should handle those boring things. We are meant to provide the space and the bandwidth for the people that are using these tools to be able to create, right?
A designer consuming a design system should never have to think about what their interactive color is, what their form field looks like, all that stuff. They should be able to spend that time, that bandwidth thinking about how to add those delightful moments, making sure that that area of that experience matches what problem is actually being solved, spending time digging into the research, et cetera.
Now, on the flip side of that, I think the risk we see more so with this whole AI discussion is not a designer's job evaporating. I think it's more so the business side going, "Oh, so you're telling me we can save all this time, and that means the designers can crank out all this other stuff?" rather than "No, no, no. This should buy them back time in their sprints to spend time thinking, to be able to really approach the problem from a holistic way." I mean, you talk to designers every day and they're like, "I'm stressed out. I have three days to crank out this UI when we should have had a sprint or whatever it is." And all these tools tend to do while we designers are going, "oh no, it's taking away this fun, but oh, maybe it'll actually give us some space" is the business side going, "Oh, it's a time saver." And time saver means squeezing more stuff into the bandwidth of the people we already have as opposed to going, it gives them more bandwidth to do their jobs effectively.
Chris Strahl:
Well, I think that that mentality is changing a little bit, right? We've had a couple of conversations recently on the podcast about the idea of how, frankly [inaudible 00:35:41] we've made product metrics over the past couple of decades where product metrics have been all about like how much can you ship, number of points in a sprint, et cetera. What's happening is we're starting to realize, especially in the era of tightening budgets, that doing things like valuing design doesn't mean hiring a hundred designers, doing things like making a great product doesn't mean shipping the most features. It's about who creates the best quality software. And that quality metric isn't about even just software defects. It's about what represents the most value to users.
I think that that's what I'm hopeful for at least of an AI future where again, like you said, it's not replacing designers' jobs, it's figuring out ways for us to make better software. And how you make better software is you give people the time, attention, and focus on the things that matter. Nobody makes a better application by arguing for the 40th time about the accessibility contrast ratios of a called action. What people make better software on is when they're able to really think about what that product onboarding experience looks like or what that experience around that first touch really feels like to a user. Those are the things that create more product value. And I'm really encouraged by watching sort of the transition happen in the product landscape from caring about how much we ship to whether or not what we ship moves the needle.
Taylor Cashdan:
I agree. I think what gives me some pause in that though is I think we've got two almost intersecting pendulums, right? There's the tooling one of like, what's available, what's not, and how much AI's going to impact that. And then you've got this culture change one going the other way, right? At some point they're going to hit each other and they're going to figure out, "Well, this is where that magical intersection goes."
Folks can try to talk down or talk up for that matter, the market conditions of today with the massive number of, arguably in some cases, unnecessary layoffs, but all of how that stuff is then playing a part in this same pendulum. It's also the heavier weight that's coming down because yes, have these conversations been happening about what we measure and how we measure it, for sure. But when you're telling me that you're also laying off three-fourths of the team, unless your roadmap is changing, unless your product stance is changing, unless all of the bandwidth things are changing, and this goes for engineers, designers, it doesn't matter, then you're not changing much except increasing the workload of the people who are "saved" that are there, that now have to do the work of five people.
And again, that's also in that pendulum. There's a period of time after a layoff, in most orgs at least, where everyone feels nervous and concerned, and then some of that happens. And then good orgs go, "Let's pause," or "We've been planning for this," or "Here's the things we'll drop off of the roadmap or whatever." But there's also toxic orgs that go, "Well, we committed to this to our customers, so we need to ship this and it doesn't matter. Sorry, late nights are coming." Then we can talk about the whole mental health aspect of all that, but that's a whole different discussion.
Chris Strahl:
Right. Right. Right. No, I'd love to have that on a future combo. Well, hey, I really appreciate your take on this. It's been an awesome chat, thinking about skepticism, hope, the future, so really appreciate you. Thanks so much for being on the program.
Taylor Cashdan:
Yeah, thanks for having me.
Chris Strahl:
Talk soon. Hey y'all, Chris here again. That's the end of part one of our two-part episode. I hope you learned a lot from our speakers. Don't forget to register for our webinar on April 26th where we're going to have all four of our guests on to talk more about tokens. Hope to see you there.
