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, everyone. Chris Strahl here with the Design Systems Podcast. Today I'm talking to Danielle MacDonald. Danielle is the creative head of digital product design at Waters. Welcome to the program. Super excited to have you here.
Danielle MacDonald:
Hi, Chris. It's great to be here. Thanks for having me.
Chris Strahl:
Give us a little bit about your background. How did you get into this world of design systems?
Danielle MacDonald:
I started doing user experience design around 2005, and then I ended up going into more of a style guide role and learning about speccing and digital handoffs and what happens in development and the relationship between design and code. And then, as I progressed, I was a part of a major rebrand that launched in 2015, and two years after we had built all the components and stuff, we started to see a problem with our libraries and the cost to build something was really astronomical because we would have to do it all over because of the fixed spacing, typography, all of those details. And I got really frustrated and I was like, "There's got to be a better way to do this." I went down my own path and came across Brad Frost and the Atomic Design System, Dan Mall, and what they've been doing there, and really started to think about it and doing an inventory of our components because we had to customize every single component. We ended up with about 2,400 components.
Chris Strahl:
Holy moly.
Danielle MacDonald:
Yeah. And I took the approach of, I can't think of the name of the book off the top of my head, but where you throw all of the gloves on the table. I actually printed out all of the components that were in the guide so that people could visually see how many components we had, and with that, we were able to consolidate and get rid of a bunch of assets that were redundant. My goal was to get down to 60 because, based on what I had understood about design systems and what Salesforce had, what material was doing, you don't need to exceed more than 60, so my goal is to get into that baseline of 60. And what I had done is I invited our marketing partners, our branding partners, our front-end development and our user experience, so accessibility, content strategy, I brought all of them in and we sat literally around the table with these paper printouts and went through them together and thought about how to build those differently and what was redundant and what we didn't need to do, so we got to that base.
Chris Strahl:
Old-school interface inventory style, literally scissors and printouts, just going crazy on it.
Danielle MacDonald:
Yeah, I still have pictures from it because we had them all over the table. We had them on the walls. And it's one of those things, because digital isn't necessarily tangible, so people don't realize how much is there until you actually show them. Putting that output there visually for people to touch it, feel it, see it, was a big realization of, wow, this is a lot, and understanding that we've got to do something to make it more efficient.
Chris Strahl:
Gotcha. You have all these people around this table. You're working on all this stuff. You're trying to go from 2,400 components to 60, and presumably a lot of that is variance, right? You have different components for when the button is a different size and that sort of thing. You go through that process and the justification and the realization of this was that this system was really inflexible and super difficult to change. Am I getting that right?
Danielle MacDonald:
Exactly. There was limited opportunity to scale, to fix spacing, to fix typography sizes. One of the things that ended up happening is, which, right now, today, I'm like, "Oh, this is such a big no-no," is attaching an H1 to your largest title tag versus having the naming conventions go through. With our accessibility, we always had to have our H1 be 60 pixels, and so if our headline needed to be three lines and 60 pixels, it wasn't happening. It put a lot of constraint on us.
Chris Strahl:
No, the idea that H1s aren't just bigger, getting people out of that mindset was a challenge there. I think that most people are there now, where the realization that headlines denote hierarchy more than they denote size. But, yeah, boy, was that a fun time. Well, so I think the reason to think about why this is important and why we're talking about this is we're in a world where budgets are tighter, things are a little bit harder in terms of design and engineering. You hear about layoffs on LinkedIn and likewise all across the industry, and people are facing, I think, this design system itch, like, hey, most people had a design system somewhere between two and five years.
You're in this situation where lots of organizations are like, "Okay, so I spent however many millions of dollars on my design system, and I'm being asked year over year over year to continue to reinvest in this thing. When is that going to end, or does it ever?" And I think that practitioners are still in this place where justification of the money that an organization is spending and the time and the resources attached to it has to continue to exist. And a lot of this is first principle stuff, but there is also a lot of it that is pointing towards the future.
And so let's start with first principles. In your opinion, in this very real example you gave, what was that transformational value that a design system enabled you to do that you couldn't do before?
Danielle MacDonald:
Theming. One of the things I noticed in what I understood was we had multiple products, and our example that we did was a button. Why do we need a different button framework, a different code, when we can decouple that infrastructure from the visual piece of it? And what we learned at the time is, me and this one developer, they said, "Just put it through and see if you break anything," and that was from our senior tech guy. I actually asked him about it and he's like, "Just do something small. Prove out your proof of concept. Show me that it's scalable." And we did, and we had a button in there and we could, on the dime, in the code, just change it to blue or yellow or red without having to do it, even changing the radiuses because we finally decoupled the presentation from the actual button-coding infrastructure.
And, from there, we both realized there was something to be said about doing that for all of our components. And then we get into design tokens today, which I'm still fascinated and trying to figure out exactly how to use them just right because there's so much opportunity there. We started looking at spacing and started to pull those things out and realized it was more about the naming conventions and really breaking down the granular details, the atomic pieces, to make sure that those more complex components, as you built them, ended up as more of a pattern. And you could hard code them when you needed to, but they were always flexible. If you needed a heading that was 25 pixels versus 60 pixels, you could do that because it was separated from the code in a way that was themable.
Chris Strahl:
Yeah, that's great. Everybody's favorite punching bag is the button. The button gets a lot of shit for being a catchall for the illustration of design systems, but there is some brilliance in its simplicity and its ability to be understood by people. This idea that, if you go from a position of not having variance and not having themable systems and systems that are highly coupled to code instead of decoupled, the button's a really great illustration of the way that this matters because buttons usually come in lots of different shapes and sizes. And, when you're talking about, as my co-founder, Evan, likes to say, ye old pilot component, when you're first implementing a system, the button's not altogether all that bad. It's maybe not the most important thing you could do, but it's also not the least important one. And it does a really good job of painting a picture in people's mind, the idea of, "Oh, I'm creating something that is systematic."
And it is actually funny, we've mentioned this a lot on the podcast lately, about how human beings just have a really hard time conceptualizing abstract systems. If you're thinking about what is an abstract system, and to your point earlier, when you think about digital systems then being one more level removed from that physical tangible thing, you have this thing that's both intangible and abstract, how do you make it real? And I think that what you just talked about is a really cool way of doing that, and it's something that, after we implement the design system and that initial group of people goes away or goes back to doing whatever we borrowed them from, we don't reinforce that enough in these ongoing conversations.
How do you think about the reinforcement of that tangible, concrete nature of the design system you're working on now?
Danielle MacDonald:
The value, so looking at even the projected return of investment and how that design to scale will help multiple products at the same time. We have a team internally in our digital design team that is our design systems product team, and we refer to that as the product that services all of the products. Knowing we've got over 10 different products, so we have to have that infrastructure right, we want our branding to be there, we want those design patterns to be relatable. But similar to, if you look at Adobe or Microsoft, we can have different branding and theming capabilities, but you still know you're in a Waters product. Looking at that and the value of that is we can create one component, we can put it out into production, and it's consumable by any of those development teams so that they don't have to do that detail work.
At the end of the day, we've done it for them. We're putting out releases regularly, we're showing them new things, and they can focus on what they're really good at, the backend, the hard coding, the more complex stuff to make that workflow work, to consume that data and produce it in a way that's meaningful to the end user. We're looking at those patterns and trying to have them not necessarily cookie cutter, but production ready so that it's one less thing on their list to do because it's a lot of time to fix those things.
Chris Strahl:
Yeah. There is so much of that friction in that design-to-engineering pipeline, that workflow and that transition. We've talked about it in terms of handoff for so long, but I think that also handoff is a misnomer in the modern era because there's so much design work that's still yet to be done when code is first starting to be written. And so I like to think about this idea of, when you're taking something from intent to implementation, what does that feel like? What does that look like? And that's a very fraught process still.
There's still a lot of pain in that that exists, and it's largely because we have a bunch of imperfect tools that we're designing with that ultimately then become something that a user experiences, and those aren't the same medium. And so that gap that exists between those things is a fidelity gap, and that fidelity gap is between intent and implementation. And, when you think about a design system and how it helps you solve that gap, being able to look at a component in isolation and understand this is the thing that I intended to build and this is the thing that actually got built, and for the designer to have an opinion on the thing that actually gets built before it goes into production, is just this really powerful concept inside of design systems
Danielle MacDonald:
Yes, especially now that, I would say, even design is more dimensional at this point. It's not just a flat static component. We've got hover states, we've got click states, we've got transitions, we've got motion. We can only go so far in a tool like Figma. We can do some prototyping in CodePen and things like that to convey the message of the design and what we're trying to do, but it's not real until you see it in there.
When I think of a handoff, I always joke that you can't do a good design without your content strategist, your front-end developer, and your designer, and you can say visual designer, generalist. I know there's like should it be specialized? Should you be able to do everything? But those, to me, is the three pillars that need to be there having those conversations because you need to understand, "Should that heading have three lines? Should I look at what that line length is? Should it be more than 600 pixels? Should I design it that way?" And then, from a code perspective, even just the timing, the key framing, and you can do it one way, but when they do it, they're like, "Well, it's choppy," and you got to work together to find what that balance is and what's technically feasible to make that vision work and understand both sides of the coin.
Chris Strahl:
Yeah. We're definitely rolling out the tropes today, but one of my favorite moments doing that product owner role was sitting there with a designer and with an engineer that had never met each other before and basically saying, "Look, we're doing a German localization of this site and you have a heading tag inside of your product card that can only hold 60 characters. Here's a German word that's 83 characters, and look at what this looks like and how it overflows, and what do we do with that?" And, for the first time, that designer realizing that that was a real challenge that existed in implementation, not to pick on the designer. They didn't know. It was something that they were seeing for that first time, and then they came up with a really elegant way of handling it. But, otherwise, that's a design decision that's left to an engineer, "Do I truncate it? Do I wrap it and hyphenate? Do I just shrink the text? What does that look like?" And that's something that only really exists in the medium it's destined for.
Danielle MacDonald:
Yeah, a lot of times they take their best guess. And it's funny you mentioned the German example because one of the things I've been primarily focused on, companies that are US-based and not having to think about globalization and localization, now I'm talking about are we going to support 50 languages? What typography is the best for that? Should it live in the design system? And I'm like, "Absolutely," because then you don't have to think about it. We've done all that hard work. You just have to implement it.
And it's been a real eye-opener. It's been my big topic, globalization, and thinking about that this week because it's really complex and you want to make ... when you look at something in Japanese, they like dense data. They [inaudible 00:14:34] their layout. When you think about the theming capabilities on that, you want to decouple that so you can have potentially a theme that supports Japanese and what they like and prefer in terms of the end user versus what someone in the US might like with more white space. That's been a new thing for me with the realization of design systems is there's a whole nother type of theming we should be considering inclusive design-wise.
Chris Strahl:
There's so much there that is so exciting. Let's shift gears, actually, to thinking about that whole, "Let's build better software with design systems." We talked about some of the causal things, like why we end up using design systems, and from the perspective of somebody that's designing or implementing as an engineer, a little bit about that ROI conversation about, look, we want to make our lives easier. We want tools to make this stuff more efficient, more effective, more maintainable. But there's also a part of this that is about better software. And that part that's about better software gets into a lot of these future concepts of design systems that I think are also really cool.
Funny enough, for a guy that runs a design system startup, I actually think that design systems are only interesting when you start to think about what you can build on top of them. Otherwise, it's like saying, "Hey, I got a really cool DevOps workflow." Awesome, but what actually matters is what goes into the servers that you're sitting there using in the cloud to do something with. When I think about this, I think about, first of all, when it comes to that more concrete, better software, getting people to make those decisions together, and that triad team you talked about, content, engineering, design, all working together. I think that this enables this in an interesting new way, and I'd love to get your take on why that triad is so important and how design systems really enabled that more democratized collaboration.
Danielle MacDonald:
It's funny the way you referenced it. Usually, when I talk about a design system and what it is underneath, I was like, "If you wanted a house, you want a house that has a good foundation. You want a good layout. At the end of the day, you can knock out everything in that framework and you can rebuild it, you can redesign it, the fun stuff." If I want my kitchen appliances to be teal, I can make them teal. If I want stainless steel, I can do stainless steel." You have that opportunity, like you said, and you can start to visualize it and see it, and it's the pretty picture, but the hard work comes behind that to make it feasible to do whatever you want. And a lot of that has to do with talking about requirements and understanding scalability. Is it responsive? Should it work on a mobile device? Should it work on a 60-inch TV? How do you want your application to scale?
And, with that group, with engineering and content and the designer and even the product owner, talking about the constraints and the requirements early in the strategy, you're able to apply those. And, when you don't have to think about those fundamental components, and in this day and age, a button is a button, a heading is a heading. We're more about the experience and making the end user's job easier, potentially, making the customer more efficient in taking their money out of a savings account. We want the experiences to be so good, and it sounds funny, that they forget about them because it was just quick. It was easy. I got done what I needed, in and out, and I didn't even have to think about it twice.
The experiences that we get hung up on are the really complex workflows. Well, it took five minutes for this to load. I got stuck on this. It doesn't work on my phone. I had to go to my computer. Putting all of those into the design system assets gives us time to think about the experience better and less focus on trying to fix things so that they work everywhere, because we've done that upfront with the design system itself.
Chris Strahl:
Right. And the idea of, if I have components or patterns that have all of these things vetted and established and understood, the assembly of those patterns into features or pages or whatever that end result is, is going to benefit from all of that work that came before. And so it is this fun standing on shoulders situation where you want to have those foundational pieces, those bones, the structures, the framing of your house and your foundation, to feel really strong because, ultimately, that gets assembled into doors and windows and walls. And then you get to have those fun treatments, like you said, about what tile are you going to use in your bathroom? Like everybody on the planet, I did a big remodeling project during COVID.
Danielle MacDonald:
Me too.
Chris Strahl:
Yeah, it was the time to have people traipse through your house and make a bunch of dust. And so one of the hardest things was we have this master bathroom that has been a just gigantic thorn in our side, where we've redone this master bathroom three times, we've lived in this house for seven years, and we can't get the framing right. And, because we can't get the framing, we keep having to rip it out, either because stuff breaks or because we just, frankly, don't like it. And we're now in our third iteration and we still don't love it because we're designing a bathroom. We're not talking about framing or foundations or anything else like that. I'm like, "Look, it's an old house. It's probably never going to be perfect," but I feel deeply, in my own bones, your metaphor.
Danielle MacDonald:
Yeah. I used to use Legos, but I feel like the house one resonates more because everybody's had that experience, where, "I painted it and it looked better, but it didn't necessarily do what I intended it to do."
Chris Strahl:
Yeah, exactly. And maybe inline CSS is the caulk that we all used to hide our mistakes, right?
Danielle MacDonald:
Yes.
Chris Strahl:
Anyway, with that in mind, shifting gears now to more far-flung things, you brought up a button. One of the things that we've talked about in Knapsack a lot that I think is a fun concept is what if we resurrect Clippy, but Clippy is a button instead of a paperclip, and that button is telling you things about your design system. Are we full circle on this to the point that, because of AI and because of chatbots and because of all the things that we're doing, what we're back to is having some sort of assistant that's actually helping us navigate and move through our design system and make choices?
Danielle MacDonald:
Yes, I think helping us make choices, but also helping us be more efficient. There's certain things ... kids don't like to do their homework, so they don't want to write their book report or things like that. When it comes to your design system and your component and your rules of use and your accessibility, that's the not fun part of it because you have to get those details right so everybody understands, and it's the single source of truth. I look at AI and ChatGPT and those types of things as an opportunity to help me do better documentation quicker and more efficiently, and I can get that out to the teams faster. I see that as an opportunity. People probably haven't thought about it like, "How is it going to help make my job easier so I can focus on the things that matter?" versus, "Oh, no, it's going to take my job."
I think people have to look at it differently that way. Mobile phones, everybody was like, "Oh, responsive design. This is crazy." Or even when we started, you use Firefox, you use Chrome, browser changes, having to make things work in different browsers. Now we're getting into the chat piece and the virtual assistants. Watching my kids use, even on Xfinity with the voice remotes, they don't even type in things or use the touchscreen. They rely on their voice UI for that experience. Our design system not only accounts in those patterns for visual pieces, but also, when you look at the content strategy, how does it translate if you have to do a voice workflow? What would that do?
Chris Strahl:
That's also, I think, really interesting because it just makes the context of a design system so much more important, the idea of having your principles in there, having usage guidelines in there, having all this stuff. And, yeah, robots can help us generate a bunch of this stuff. We have this fun experiment in Knapsack right now where you import a pattern into Knapsack and it automatically builds all your docs for you based on what it assumes that pattern is used for. And that's cool right now. It's a good prototype tech demo type thing, but we're not that far away from actually having that in our app, where you're going to be able to say, "Let me point to a bunch of code patterns, have it auto document those code patterns," and then also determine your basic usage guidelines based on how it views the system as a whole.
But, in order to do that effectively and for AI to be able to effectively give us what we need at our fingertips, that context is really relevant and is really important to the conversation. And so making sure that you have, again, things like principles in your design system that help the AI tools relate what you're working on to the broader context, that's this really interesting new frontier. It's almost like what's the next generation of user interfaces for the way that we build? And I can't wait to see those start to show up in the apps that we're using right now.
Danielle MacDonald:
Yeah. And I look at any experience we do digital or not is, at the end of the day, you're trying to solve someone's problem. At a bank, you're trying to solve how the customer views their money. At Knapsack, you're trying to solve how we take our components through and produce great single source of truth. We're all trying to help solve a problem, and it's how can I take more time to think about the problem strategically to come up with better ideas than to sit there and redo the same things over.
If you think about, even Apple, when the iWatch came out, "I'll never use a watch. I'll never use the Apple Watch." And now personally, for me, I can't go without it. I love having my watch on there and not having to have my phone next to me if I get a text message or something. But that connectivity with digital just overall and having those systems of patterns and thinking about how they all work together, not even just on a screen, but how does my Alexa work with my phone, with my Mac, my TV, "Oh, I forgot to turn off my lights." There's all those patterns and workflows that we have yet to even touch from an experience perspective that we can solve.
Chris Strahl:
I completely agree. I think that the idea of how do you create more attention and more time into this is really interesting. I also think that there is this opportunity that's this unlock for things that we haven't thought of before. You talked about the localization experience earlier, what does it look like if you're a Japanese user or someone that reads and speaks Japanese? Your aesthetic is very different than an aesthetic that is used in Portland, Oregon, most likely. And so is there an opportunity, because we have variations of design systems and things like design tokens and collections of design tokens, to basically say, "Look, I want a more compact, more text-heavy, less image-heavy version of this entire application, but because I know this person is in Tokyo and is a 40-year-old Japanese person that, most likely, they're going to want this experience personalized to them."
Danielle MacDonald:
Yeah. That's where I hope we can get to. Even Google Maps and things like that, I don't know if you get those notifications, but routines of your day today, it's like, "Hey, it looks like you're going to the hockey rink. Do you want me to put the GPS in and tell you how long it's going to take?" We should be able to have that authenticity of who our end user is and be able to accommodate to them so they don't have to think about that. Netflix, it's personalized to you based on what you've chose to do. We should be able to put those options in the design system so that we can scale it and start to personalize things, and it's almost like choose your own adventure, the stories. Maybe personas aren't going to be as important, or maybe they're going to be more important, because we're going to have this level of letting people make it how they want it so that they can get their jobs done better, or their experience just improves because it feels right to them.
Chris Strahl:
Yeah. And I'm also hoping for this new era where we can tailor needs for folks with assistive technology as well, the idea that you could have an experience that is tailored for somebody that wants a lesser cognitively intense experience or somebody that needs to have assistance seen. All of these different things are really important to making sure that we're taking care of everybody, and I'm really hopeful that that's the way this all heads.
I think there is a little bit of a dark side to this too. If it gets so good that we're all forgetting that we're shopping and we're just watching our bank balances decline, beyond even just spending the money, there's a lot of bias and a lot of algorithmic problems that come into these sorts of technologies, and I think it really remains to be seen exactly where this goes. I have to remain hopeful because I'm in this industry and it's kind of like, "Look, we're all out here trying to build the future together." But when you think about this idea of where this is all going, do you feel like there's a hopeful tone to it?
Danielle MacDonald:
I would like to think so. You think about other things that have come out in the past that folks were skeptical of and, "Maybe that's not what I want to do, like Alexa, "Oh, she's always listening." But yet everybody now has something like that in their houses and they use it to do things. You can turn Alexa off with the AI. And I know, with Google, with the conversations coming out about it's dangerous, I think everything is. It's how do you follow it? How do you adhere to it? How do you make it work for you in a way that doesn't make things unsafe?
I love the idea of thinking about it from an inclusive design perspective and thinking about kids in schools and different learning styles, so not even just sight or sound or the five senses, but someone whose cognitive load, because they have ADHD, they're going to learn differently, or auditory processing where they might have to repeat something multiple times because that's how their brain works and what that functioning is. There's all sorts of different abilities or things like that that aren't noticeable, but they impact people day to day. You and I both have glasses on, so you could say we're technically visually impaired in some way.
Chris Strahl:
I was going to say, thanks for outing me. I'm still getting used to them. They're new, okay? I turned 41 and, all of a sudden, I can't see anymore.
Danielle:
There's all different things like that. You look at the way that education is shaped, everybody has a different learning style, and that doesn't go away as an adult or as an end user. You still process things in a certain way and there's accommodations made for that, so you can attain in equal education. We should be doing the same thing with digital experiences, whether they're voice-activated or touch, whatever, how we do that. How do we make it work for everybody?
Chris Strahl:
Totally. I love that. That was great. It was a nice sunshiny take on where this is all headed, so I appreciate that. It's a cool perspective. Tying it all back around again, I think that what enables us to explore these really interesting things is we're not having to think about how we design a million different experiences. What we're trying to think about is how we design a system that's capable of building a million different experiences, and that ability to use systems to build at scale. There is a lot that is contained under the design system umbrella, and there's a lot of things that it empowers and enables, but the idea of, hey, this is a system that scales, that allows me to create really, really interesting, really meaningful designs at a scale I would never be able to do if I didn't have one. That, to me, still maintains as the biggest central value focus to what a design system is.
And I'm curious, when you're representing this to Waters or representing this to other people in the community, what's the tack you take to really share that with people?
Danielle MacDonald:
Yeah. I look at it and I always lean on the 80/20 rule. Let's solve for 80% of the users with these standard things that are going to work for most people, and then that 20% is something where we can put more time and effort on when we have the opportunity to do so. I love doing A/B testing. I love being able to put things in a design system that's supported by research, clear, proven testing, so it's got the data to support what we've implemented in the design system. Because you can say it works, you can say it does this, this, and this, but if you're implementing a pattern, you need to be able to show that it did work, and out of 50 users, 45 were able to do this. You've hit your mark there in terms of supporting the data, that you have a strong pattern or component there.
And then I think you take a step back from that, and once you've established that and you've hit that maturity in your design system, then you can really think about things differently, and how would I make this experience better? How can I add that next level of it? What is the story I'm trying to tell? How do I want that end user to accomplish this? Where do I put the Easter eggs or the delights in there, certain things, is it a sound? Is it the [inaudible 00:31:49], different levels of thinking in there, strategically thinking. It gives you the opportunity sometimes to take a step back and look at it completely differently and flip it on its head. Maybe it's time to evolve it and change it differently.
The design system supports the regular day-to-day implementation of things and allows you to take a step back and plan for the future and think about your user in a different way and give you the time to conduct the research and solve problems that you learn about as you go along versus trying to fix the right now where it's like you're building the plane while it's flying because you have to get it out for release next month and you focus only on features.
Chris Strahl:
Yeah, certainly. And I think that this has never felt more acutely than now, where teams, across the board, are not growing or shrinking, roadmaps aren't getting any smaller, so how do I use systems thinking and the application of systems to really continue to meet what's probably a very demanding roadmap for most organizations, and to have it not feel like the ambulance service. I think that that's one of the things that is an interesting effect, at least within the design systems I've seen, is that it makes people just feel a lot more calm about what they're working on, that tranquility that comes with, "Oh, I don't have 400 little test cases I have to manage and that I have to fragment up my day and chop everything up to talk about litigating accessibility of color contrast for the 400th time." And so this idea of it gives everybody just this ... we always talk about focus time, that ability to get into flow.
The fact that your flow doesn't get interrupted by all these mundane decisions that exist is interesting. And then, to think about what you were talking about, I see all these opportunities, like we talked about earlier, for AI to help continue to evolve this into even greater insights about how our design system is being used. If you have that idea of what works and what doesn't, can the system help you determine what you should try next? And I think that this is really, really cool because we have this foundational idea of what these systems are and what they do, and now the sky's the limit on where we can build.
Danielle MacDonald:
Yeah. And, if you look at the algorithms in certain things, for me, I think about, one, coming from financial service, I immediately think of data visualizations, even for science. Show me how my things are connecting together so I can get an end result that might solve whatever I'm trying to do. And my example is always like, "Can you help me cure cancer and give me the information I need after all my testing?" We should be able to do that in a better way and not spend so much time on making a really complex workflow where it takes them longer to do the workflow to solve the problem and get the data than to analyze the data themselves.
It's like I want to take that burden off of them so that they can focus on doing what matters to them and what they came to do and what they're passionate about, at the end of the day, without having something that feels hard to use, or they don't even think about it as hard to use, they think about it as part of their day. But, if we could cut the time in half it takes for them to do something because we've become more efficient, it gives us more focus time to strategize on how to solve their problems, but it gives them even more time to focus and solve on the problems that matter to them most.
Chris Strahl:
That was an awesome, I think, just overall summary of this, and I think that's a great place to say ... let's leave everybody with this hopeful vision of the future and some idea about where they might be able to take things. And I think that grounding that in the fundamental principles of why this stuff matters, I just really enjoyed the conversation. Thanks so much for being on and sharing your thoughts and your journey with us.
Danielle MacDonald:
Awesome. Thanks so much, Chris. It's been a pleasure. I have really enjoyed the conversation today and thinking about the future and what we can do with it.
Chris Strahl:
Awesome. Appreciate it, Danielle. Have a great day. Thanks everybody for listening. See you all again in a week. Take care.
That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @TheDSPod. We'd love to hear from you, show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
