in this episode Knapsack's VP of Design Leadership, Richard Banfield takes a look back at a conversation between Chris Strahl and Emily Campbell. They discuss the convergence of design and code, and what that actually looks like. They walk through what a designer role looks like in a modern digital product team and Emily explains her idea that design and development are the same. They just have different approaches to the same process or medium. Other topics the duo touch on include questioning if designers should learn to code, intent around design and development, the importance of making intentional decisions, and more.
Guests
Emily Campbell
Now the VP of Design at HackerRank, at the time of original recording Emaily was a Senior Design Specialist for InVision. Emily is a veteran design and product practitioner who focuses on human-centered design, translating creative strategy into business value, building a culture of leadership, and sharing ownership across disciplines. On the side, Emily enjoys exploring the desert around her home in Moab, Utah with her husband and three kids.
Transcript
richard banfield [00:00:00]:
Hey, everyone, this is Richard Banfield. I'm the VP of Design Leadership here at Knapsack, and I've taken over the podcast for the next few episodes to revisit some of my favorite and the most insightful moments in DSP history. In this particular episode, Emily Campbell, who is a great friend of mine, and Chris Strahl dive into the evolution of design systems from way back with traditional pattern libraries to modern, fully integrated systems that actors the shared language across multiple disciplines. So whether teams are sitting next to each other or they're working across the globe, this transformation is how they're collaborating. And that's the nature of this conversation between Emily and Chris. I really like this story and this conversation because even though it happened a couple of years back, the challenges it addresses are still incredibly relevant today. In my recent conversations with CEOs, VPs, directors, and just about any other leader in our industry about this topic, it's clear that the design dev collaboration remains one of the biggest hurdles that teams are facing. It's something we need to continue to talk about and figure out as an industry.
richard banfield [00:01:16]:
In this particular episode, you'll hear Emily and Chris chatting about how designers are moving beyond pixel perfect mockups to programming patterns of behavior, and why, when those collaborative prototyping opportunities are created by these teams, they create a better product. Because ultimately, the future of design isn't about people learning to code or designers in the code. It's about understanding how the process of digital production works and how everybody can contribute to that process in a way that makes it feel cross functional and collaborative. At Knapsack, we're tackling this challenge head on with our own software designed to foster that collaboration, especially across the disciplines, and also try and democratize that digital production process by sharing what it is that you're creating with the people on your team and even some of the folks that are maybe adjacent to your teams. Our goal isn't just to connect designers and developers, it's to open up the entire workflow, empowering product teams, marketers, UX professionals, accessibility experts, and just about anybody else that's contributing to the product creation process. When we think about Knapsack, we think about teams that can prototype using really well validated, real coded components without relying solely on just engineers. Right? So think about how the process of creating assets happens. We want it to be available to just about everybody, not just to the folks who are actually writing the code.
richard banfield [00:02:56]:
So if you ever wondered how to break down those silos, improve the designer developer collaboration, or really just to scale your Design systems. This episode is particularly for you. Let's dive right in.
Chris Strahl [00:03:11]:
Welcome to the Design Systems Podcast. We're all about the places where design and development overlap. We talk with the industry experts about trends in design development and take a look at new ways to build digital experiences, typically over a beer or two. Hey, this is Chris Strahl with Basalt. And this is the Design Systems Podcast. I'm talking with Emily Campbell, the senior design specialist at InVision. Welcome, Emily. How are you doing?
Emily Campbell [00:03:35]:
Hi. I'm good. Thanks for having me.
Chris Strahl [00:03:37]:
Yeah, yeah. Really excited to chat with you. So let's see. We've been talking together about design systems now for, what, like, going on two years?
Emily Campbell [00:03:45]:
I'm a little shy of that, but for a long time. Yeah.
Chris Strahl [00:03:48]:
So when were you first introduced to the concept of a design system? What was that all about?
Emily Campbell [00:03:53]:
You know, it's funny, we call the things that we're calling design systems today this fancy term, but I've been working in that space for, well, about eight to 10 years now. Even back in the bootstrap days, even then, some of the pieces of what became design systems were there, like patterns, components finding, common language. But it's really just been in the last few years that we start to understand this is something bigger than just a collection of stuff.
Chris Strahl [00:04:22]:
So what do you mean by bigger? You have all these different disparate pieces that come together, and when you put all these things together, what does that make? What to you represents a design system?
Emily Campbell [00:04:34]:
I mean, the reality is that a design system can take many forms. The most successful design systems out there are more than just digital, more than just components. They're actually a language that people who don't work in the same building, the same discipline, the same team can use to communicate and work effectively together. But for a lot of teams, a design system starts out as just a pattern library. And I don't think that we should diminish that definition because it can make people feel like they're not on the path to something successful. So anything that helps you communicate fluently with people who don't speak your native language of your discipline, whether that's code or design, I think constitutes a design system. And we're just starting to see the beginnings of how that can be leveraged.
Chris Strahl [00:05:20]:
Gotcha. I know we've talked before about a lot of your more interesting and I would say, even progressive thoughts about what the convergence of design and code looks like. So as you see these languages that are different but. But sort of collaborating and working together in the same space, what do you see the role of a designer in a modern digital product? Is that closer to code? Is it still the traditional notions of design, and how is it different than it was even just a couple of years ago?
Emily Campbell [00:05:49]:
It's been really exciting to watch this change. So design is starting to go through a bit of a divergence in its practice. On the one hand, you have designers who continue to do what we have traditionally thought of as software design, which is understanding the patterns of human behavior when interacting with software and building interaction patterns and visual patterns in order to help them achieve some intended outcome. Right, Those job stories we talk about. But we're also seeing design start to take on additional roles. This role of service designer, this role of translator, design ops. So I think how we define design has to change as far as, like, what the relationship with design and development is looking like. Designers are starting to recognize, especially in more mature organizations, that we can't be responsible for creating every individual screen, every individual touch point or moment, and instead we have to start to think about what we are doing as programming, in effect, right? We are building consistent patterns that hopefully create consistent outcomes of human behavior, even if what's happening in the middle is very highly personalized to the journey someone takes to that interface or the content that's on their screen.
Emily Campbell [00:07:08]:
So it's almost like we are programming algorithms of human behavior, but through design as opposed to through written code. So that's kind of. I think we're only just starting to see what that looks like at some of the more mature design organizations, especially where design and development works very closely together, but where those teams are applying this effectively, you actually see design and development working in partnership. There's less of a gap between the two disciplines. They're just applying different approaches to the same process, to the same medium.
Chris Strahl [00:07:45]:
So there's no other place that I can think of that designers and developers come into contact more in kind of a modern environment than building digital products. And so when we think about this notion of design and development using different languages to essentially accomplish the same thing, creating these patterns of human behavior that are codified and reusable. Do you look at digital products as kind of the leading foreground for this?
Emily Campbell [00:08:14]:
I think it is by necessity, because digital products, unlike physical products, where you have to have somebody who's building the thing versus somebody who's waiting on the thing to be built in order to program it, Digital products are, by their very essence, collaborative. You cannot see what it looks like until you build it. You can't understand the implications of that build until you have it out in the wild and people are using it. So the iterative approach to software development is necessary in order to actually make the thing, which is something that is so special about it. Coming back to this thought of designers and developers working in the same medium, I think it's why you are seeing that change in that relationship, designers and developers, is because to build the complexity of modern software, you have to have these people from different disciplines looking at this from different lenses, working together, or else the whole thing falls apart. Or you see the effects of that siloed approach in the actual product itself.
Chris Strahl [00:09:19]:
So there's lots of different ways that I've heard out in industry about the way people are trying to solve this problem of getting it, so that instead of shipping around pictures of digital experiences, we're actually talking more about the experiences themselves. Because that richness actually really matters when you're thinking about how an experience actually gets consumed by a user. Nobody's consuming a picture of a website or a picture of an app. Everybody's consuming that app experience or that website experience, which is typically a lot richer than that comp environment allows for. And so what would you say to the people that say that all designers should now learn how to code, and that's an innate necessity for being a designer for modern digital products.
Emily Campbell [00:10:02]:
The question, should designers code? That's the question. No, designers shouldn't code. But could designers benefit from understanding code? Sure. I definitely think that designers who understand the language of the people they're working with can benefit, just as anybody who's multilingual can benefit from having the perspectives of different language. Right. If you think about somebody who speaks English and German and Spanish, even though you can convey similar things in each of those languages, the actual construct of the language is different. So understanding how people communicate in a different language actually helps you communicate more effectively with them. But ultimately, whether a designer can program in Ruby or write JavaScript is not as important as understanding the construct of the language itself.
Emily Campbell [00:10:56]:
So designers should certainly understand the logic of code. They should certainly understand the mechanisms by which what we are building gets brought to our users through the browser, through our devices. But I don't think someone needs to actually code in order to get there. And I think sometimes we lose the nuance of that through this big, fun conversation that blows up design Twitter every two weeks. And we lose the fact that this is actually an opportunity for us to use that to work better together. It's not just about the action of coding. It's about understanding each Other understanding each other's intents and then finding those commonalities in how we approach our work.
Chris Strahl [00:11:34]:
I love that that is a big part of the zeitgeist of design Twitter. Even that design Twitter is a thing kind of warms my heart in some funny way. When you think about that idea of understanding somebody else's language being important to being able to communicate, I think you're really driving at the core of what a shared language means inside of a design system. It's not about necessarily having exactly the same language. It's about having a shared understanding of what that language means. So a designer doesn't necessarily have to understand how to define, say, like, props for a component or something like that. They don't need to understand how a JSON file is necessarily constructed on the developer side, much like a developer doesn't need to necessarily understand exactly how you go about applying different styling to a particular component in, say, sketch or something like that. It's a lot more about just making sure that those things are considered when you're actually building these experiences.
Chris Strahl [00:12:28]:
So a designer is much more effective at their job if they're able to understand that, hey, this is a headline. This headline has three different variations. This is the particular variation that I'm using in this particular case. And that also gets into things like semantic naming and understanding that perhaps it's not the best idea to call our primary color primary blue. It may be it's just a better idea to call it primary because it may not always be blue. Is that kind of what you're driving at?
Emily Campbell [00:12:55]:
Exactly. And you made a comment earlier about whether we should be painting or drawing interfaces versus whatever comes after that. And even the very words we use to define the relationship of handoff, Right? I mean, handoff is for two people who don't know each other, right? I'm gonna meet you on the street and I'm gonna hand something off, and I'm gonna continue on my merry way. Whereas when you have people who are interacting with each other or understanding where they're going, you know, they're having conversations, suddenly handoff doesn't mean it's the same thing. It doesn't even really exist. Instead, it's just these different touch points in the relationship. So when you get to that point, then drawing interfaces can actually work really well because it's just a mechanism by which you communicate intent. That's where we want to get to whether I'm doing that sketching on a napkin or on a whiteboard, or drawing in sketch or even Writing some really messy HTML CSS just to get a point across.
Emily Campbell [00:13:54]:
If the relationship is one of shared understanding and shared language, then the mechanism is just that. It's just a vehicle to translate or to transmit a concept or an idea. So to your point, a developer doesn't have to necessarily know or understand the nuances of why I make specific choices as a designer, why I choose a specific color scheme, why I choose, you know, a specific architecture to my typography, for example. Right. Like, I mean, that's all kind of a little bit surface level and visual, but it's something that traditionally we don't expect developers to know. But I would want a developer to know the general content structure and content architecture of the content behind the design. I want to have a shared understanding.
Chris Strahl [00:14:38]:
So when you're thinking about these things, you're not just talking about the visual side of things, you're actually talking about the way that we actually construct these experiences at a deeper level that has lots of implications for developers and users. Things like accessibility or other things like that. Can you explain a little bit more about what you mean by that?
Emily Campbell [00:14:55]:
Yeah. When we talk about design systems, we put a lot of emphasis on the visual layer. So creating visual consistency is something I hear from a lot of design teams when they're talking about why they're building a design system. But for many of us, especially people in developing countries, people who might have differences in visual abilities or visual traits, their experience with the web is very different. With all of the focus on what style a button should be. If I were to turn off the CSS layer on my browser, would I see the intent actually reflected through that? The design system can help us with that. A shared language and shared understanding can help with that. Because as a designer, I'm relying on my partners in development to communicate that through code.
Emily Campbell [00:15:43]:
The intent that I'm designing for our common end user.
Chris Strahl [00:15:47]:
Got you. When you think about the process that you go through to communicate that intent, one of the big hot things right now is design ops. You talk about this idea of how do I go from something that is an ideation or visionary all the way through to an actual experience that ends up being consumed. And you want to have these touch points along the way that are these really meaningful ways of synchronizing the intent behind design and development. And it typically involves things that are a lot more development style things like version control, release management, metrics, all this other stuff that is often attached to these things that designers have traditionally been a little allergic to. And that if you all of a sudden are imposing a lot of process onto a design workflow. People kind of feel like that's somehow limiting, but you view it as empowering because ultimately the designer is going to construct a better experience because they're closer in understanding to a developer. Is that what I'm hearing?
Emily Campbell [00:16:50]:
Absolutely. And it works both ways. When designers talk about wanting to have more influence, a lot of it includes getting other people involved in the process earlier, sharing our learnings, sharing our process, and making the path to design something that we do together. So, as a designer, I'm also raising my influence and my visibility to my partners in product and engineering by forcing myself to lend my practice and my process to one that is more inclusive and is more closely tied to what the developers are doing.
Chris Strahl [00:17:23]:
Got you. So you would be a proponent of getting things into code faster because it's more of a medium that they're destined for, or do you look at things as like a collaboration on the comps, where you're trying to get a really, really great comp that has a lot of things like animation or whatever included in the comp? Or is it both? Like, where do you think about that spectrum on the idea of, like, we want to create really, really great comps before we go build these. These experiences in codeland, or do we want to get into code faster?
Emily Campbell [00:17:49]:
To be honest, I think I'd actually offer an even more disruptive way of looking at this. You know, first of all, you hear a lot of designers say, oh, we can't just go into the build process or things like Scrum and Agile. They keep us from looking at the big picture. So we still need to make room for discovery and understanding, but we shouldn't do that alone. So make time for discovery and understanding, but pull people into that, make that something that everybody is involved with. So the entire crew, design, product, content, development, are starting at the starting line together. Then as we go deeper into the design process, the sooner we can get to something that is as close to real as possible, given our fidelity of the understanding we have of the problem, the better. So we should get into prototyping as quickly as possible, moving away from just conversations and writing specs.
Emily Campbell [00:18:41]:
We should actually get something that's somewhat real that people can react to.
Chris Strahl [00:18:44]:
What does that prototype, how does that take shape? Where do you see that living? Do you see that as something that is like an experience in a tool like Storybook or something like that? Do you see it as a static site? Do you see it as a separate playground in the cms, where does that exist to you?
Emily Campbell [00:19:01]:
I think it totally depends. I'm very much in the camp of designers that would love. I go into the browser sometimes I mess around in the dev tools. I'll take a screenshot of what I created and I'll send it back out and say, hey, this is what I think we can do. That's a prototype. I learned how to write HTML, CSS, JavaScript, so I could mock up something in real code. That's a prototype. I work with developers who can do that too.
Emily Campbell [00:19:25]:
But honestly, sometimes drawing something in Sketch using some of the prototyping tools that are available out there is also as effective. The thing that is important is we should ask ourselves, what are we trying to accomplish with this information? A prototype is there just to answer questions or to get information. And if we need to get something really quick and dirty, and I can do that in 10 minutes by whipping something up in Sketch and pushing it into InVision, I'm going to do that. If it's something that is going to require a little bit more fidelity, we should pause and we should actually go deeper. But we should be making those decisions together and intentionally, as opposed to just adopting one way, one ring to rule them all.
Chris Strahl [00:20:06]:
Yeah, no, I mean, I think that it kind of goes both ways too, right? I think that in this new world where there's a lot more collaboration, it reminds me of the transition that we had back in the early 2000s, where we had all of this upfront project planning that would happen whenever you were undertaking a new project. You end up with Gantt charts and pert charts and resource plans and all this other stuff like that, typically these giant Microsoft project documents that you would do all up front. There was this idea that you dump that in front of a project team and you follow the plan and you continue to execute the plan, and at the end of it, you end up with this finished product that admittedly very rarely match the original vision of it. And I think that we're sort of experiencing a kind of a similar, more disruptive change like you were talking about in the design and development world right now, where, you know, agile was something that got adopted really easily into project teams and product organizations as a way of building these experiences. But when we were doing that, I kind of feel like we almost felt forgot about the fact that we still need to talk to each other. And so you have lots of different design teams that are running some sort of lean UX or agile design process, and you have some sort of development team that is also running an agile or lean process and those teams don't have the right touch points between them. And I think that what you're maybe driving at is this new way of thinking about maybe these should all be one cycle and they should all be working together towards building the same digital product on a cadence that is at least synchronized, if not the same as always. This podcast is brought to you by Basalt, a full service digital agency.
Chris Strahl [00:21:41]:
Basalt is committed to building a better web and specializes in creating design systems. Learn more at Basalt IO.
Emily Campbell [00:21:50]:
So there's a guy named Melvin Conway and he has a law, Conway's Law, that I love to quote when I'm talking about design systems and about design and to paraphrase it's that the communication structures of an organization will reflect in the products that they create or the systems that they create. So if we have communication structures that are siloed, that have these single touch point handoffs and then we all go off in our own direction or we're all following our own process, we might still be able to create great products, but we won't be able to create great products with the speed and the agility that we could have if the communication structures were agile. I mean, the original Agile manifesto didn't prescribe to specific software. It didn't say, oh well, the such and such needs to talk to the so and so first. It was a contract of human respect and how we work together. And that is the opportunity in front of us. When I think about what effective high impact teams are doing, I don't think any of it has to do with some specific technology or software or process because all of that stuff is going to be gone and replaced with something else in three years.
Chris Strahl [00:23:03]:
Exactly.
Emily Campbell [00:23:03]:
But the basic respect and understanding, getting rid of the power oriented hierarchies and instead thinking about accountability and co ownership, that's what allows us to actually thrive in this hyper fast complex interconnected world. And for those of us who are building the tools and the software that helps people interact in that hyper complex world, it's so critical that we are intentional about our communication structures first.
Chris Strahl [00:23:31]:
Yeah, and I completely agree around the idea of replacing tools. Right. It's always really hard to change human behavior, but it's also kind of like this most rewarding form of change because tools come and go. If you're a developer, your template language comes and goes. I oftentimes ask myself what's next after react type things. But if you have this solid understanding of this philosophy of collaboration, I think that that's A lot more lasting in terms of a way that an organization can lead in both design and development. And as my thinking around design systems evolves, I do kind of think about the idea of design systems as similar to the Agile Manifesto. And this idea of it's more of a philosophical thought process around what is your approach to design and development.
Chris Strahl [00:24:19]:
Right. A design system is the result of a systematic approach to design and development. It is not something that you build with tools or something that you build with code. It's something that is a systematic approach to those things.
Emily Campbell [00:24:33]:
So I don't know if we've talked about this before when we've talked in the past, but before I came to design, my background is in economics and I actually studied systems thinking and systems behavior. So I have a slightly obnoxiously academic approach to this in the back of my head. But when you study systems theory from that perspective, systems aren't just some connected group of things. They have an energy to them. Systems have an emergence associated with them. The ability to create independent characteristics that are not related to the actors within them. Right. So an example is think about birds who are flying in the sky.
Emily Campbell [00:25:13]:
Each bird is flapping his wings independently and together, not necessarily intentionally. They're creating these other structures. Right. So the systems of birds has this emergent effect on the shape of the flock.
Chris Strahl [00:25:25]:
Yeah, that's actually really interesting. You bring that up. We live in Portland, where there's like a pastime of watching the swifts return to this one particular. I believe it's a church in town. And you literally have, like, I think it's the largest population of swifts in North America, all simultaneously enter and exit this building every day and every night. And it's this absolutely unbelievable sight to behold as you watch literally like a couple million birds fly in and out of the same structure. And the idea of that is obviously like far beyond any single swift that's a part of that flock. But you get to see kind of the systems view in action in nature, if you will.
Emily Campbell [00:26:04]:
Exactly, exactly. So starlings are the birds that are like in the car commercials. You always see them in their fancy flocks behind the new car or whatever. But what's interesting about starlings, they mimic their behavior based off of the seven birds that are closest to them. So they're not observing the whole flock, but they're also not acting individually. They're acting around a small group that is closest to them. And then each of them is doing the same thing. And as a whole, they are able to come up with common patterns.
Emily Campbell [00:26:33]:
So, you know, coming back to design systems, or just systems of creation and working in of itself, we have to be thinking about what is the emergent factor that we're actually creating. Because a design system is a bunch of people working inter and independently around some common purpose, common goal, or common process. And it's gonna have emergent factors, right. And when we look at some of the issues we've seen in technology, right, so some of the privacy issues, some of the ethical issues, no company said, oh, you know what I'm gonna do? I am gonna create a software that completely disrupts the American election by changing the way people's algorithms affect information that comes into their world. Nobody did that. Even the worst actors aren't out creating that because you can't create that in scale on purpose. But that is an emergent quality to the fact that the move fast and break things approach combined with incredible technological scale and of course, the reach of their user network created this effect that nobody thought about. And that's obviously kind of a worst case scenario.
Emily Campbell [00:27:38]:
But the best case scenario with design systems is by getting people used to working with each other in these smaller groups, in these smaller ways, around components, around individual products, you're actually able to change the culture of the company itself through design systems. Because they are collaborative by nature, because they are cross functional by nature, they can actually start to seam together a different way of working that can then reach out beyond the design system. Totally. I think we're just at the beginnings of that and seeing that actually happen in the wild.
Chris Strahl [00:28:12]:
What's a really exciting thought, the idea that you could actually change the culture of behavior and even the culture of technology through creating better, systematic approaches to the way that we collaborate. There's a lot of echoes of a talk I saw by Tatiana Mack at Clarity about this exact topic. And she actually used the Starling analogy in it and also talked a lot about the emergence of dark patterns unintentionally from the choices that we make and the cultures that we create with technology. And I am, for one, very eager to try to help the technology world create better systems to manage the sorts of things. And I think that starts with this kind of interaction we've been talking about now for a little while is the way that we create better ways of collaborating with one another and better ways of sharing the intent of our design and our development.
Emily Campbell [00:29:03]:
Yeah, we talk a lot about should designers code, but I think it works in reverse. And even, let's get out of the binary, it's not should Designers code, should developers, should developers design? It's for those of us working in technology, what is the responsibility we have to understand the impacts of our work. As a designer, I should understand that, that the way that I create something will be reflected through code. So I want to understand the paradigms and the logic that fall out of that. The downstream effects of my work. As a developer who's often put in a position, especially back end developers working with data structures, they're often in positions where they have to make choices that affect the experience of anyone using the product, anybody building for the product. And you don't have time to take that all the way back upstream and go through a discovery process. So we should hold each other accountable to understanding the human effects of our choices when we are designing the algorithms that create the interfaces that people see.
Emily Campbell [00:29:59]:
So thinking about some of these technology companies, again, the algorithm is actually creating the interface because the content, you have the patterns of content. And this is where design systems are so important to define that. But the actual content itself is fed through the database. We should be thinking about how do we prototype the worst case scenario of this? How do we prototype the situation where this doesn't work as intended and can we capture that upfront? And again, we are just at the beginning of this. We are a decade and change into the effects of these large technology platforms, but we're also seeing the effects speed up. And now I think is the best time to get started on changing the way we approach this.
Chris Strahl [00:30:39]:
And you could think about the darker thoughts of how design systems could actually enable bad behavior. If you had a personalization or recommendation engine for, for a content or for an experience that was at the design system level, that effect is felt by every product that consumes that design system. And so it is important that we be intentional and thoughtful about these things. And I believe that Evan Lovely talks about it as designing for the miserable path. And so we always think about designers and developers inherently being optimists about the way that content is constructed or that content is consumed. And so you have this optimistic outlook about, you know, the way that something is going to be used. And it's very difficult sometimes to envision all of the different use cases that you would have that are not optimal, that are not on that happy path. And so most of the time we always think about things as a person with no visual impairments or, you know, no accessibility, need somebody that's using, you know, broadband Internet in a first world country and also doesn't mind the fact that their data has been consumed across a variety of major social platforms.
Chris Strahl [00:31:42]:
And they want that personalized experience. We don't think about that protester in Hong Kong that that is exposing who they are. We don't think about that person in Africa that is on, you know, some sort of feature phone that is is struggling even getting Internet access reliably. And I think that thinking about those and being intentional about those ways that we think about those experiences is really important. And to our earlier point, tightening that loop of feedback is a big part of this too. Because you have this notion right now, I think that is pretty pervasive in the technology industry of hey, I have this design that I've created and now I'm going to hand that over a wall to a bunch of developers that are going to go build that design and I'm not going to see that again, maybe not even until it's live on an actual website somewhere or in a mobile app somewhere. And that disconnect removes our tie, our tether to that original intent.
Emily Campbell [00:32:36]:
Exactly. I like the way you put that as well. So it's interesting. You and I are both parents and when I bought a crib for my kids, I knew that by putting that crib in my room, somebody had tested it against the worst case scenarios. They included hardware. I could attach it to the wall because at some point something tragic had happened and they didn't want that to happen to more people. And the same is for all the consumer goods that we have in our homes and in our lives. We don't apply the same rigor to the technology products that have just as much of an impact on our daily lives and can certainly harm and hurt other people if they're not used or applied with the right intent or if the intent didn't really capture their use.
Emily Campbell [00:33:18]:
So coming back to design systems is a mechanism for this. As more and more of what we do as designers and developers and technologists in general are applying these common components and new and different ways versus building unique frames for every experience. We have an opportunity as well as an obligation for those of us working on design systems to pressure test those earlier on, to use the time and the creation to say, what are all the ways that this component or canvas or some collection of the things we're creating, how is this actually going to be used in the wild? Can we prototype that? Can we pilot that, can we test that? And that's where design and development have to work closely together, because that has to involve research, it has to involve the actual real thing, it has to involve the ability to test multiple environments and real environments. But I think it also has the solution inherent in it to helping us make better choices, more scalable choices, and be more mindful about what we're putting into the wild.
Chris Strahl [00:34:21]:
Yeah, I certainly believe in that. I think that in my more cynical moments, I want to shut myself off from the Internet and move to a papaya grove in the middle of the Hawaiian Islands and just work on old boats every single day. Because there is a lot of depressing shit out there about the Internet these days. And especially in the way that, like you said, both being parents, I sometimes wonder if the work that we're doing is really of benefit to future generations. And I think that it is important for us to be thinking about that. And I wish more people took the time to be mindful of how the work we do is setting ourselves up for the success of not just ourselves, but of the future of this whole wonderful, amazing thing called the Internet. I do want to end on a really positive note, though. Talk to me about some of the stuff you're excited about.
Chris Strahl [00:35:09]:
I think that every time we chat about design and tech and everything like that, you have just these wonderful insights into what's coming. And I really like to hear what you're excited about right now. What is it that you've been hearing about in industry and through your work that has got you really jazzed about the future of design and tech?
Emily Campbell [00:35:28]:
First of all, just making what exists better really excites me. So I have a more ambitious response, but I'll start there. Because we are seeing changes in the way people work together, communicate together, both in our circles, design and development, but also more broadly. We're seeing that change and improve and the power structures flatten and purpose being something that drives our work that is still rather new. And I don't think it's going to stop. And that really excites me because that has effects outside of the products, outside of the software.
Chris Strahl [00:36:01]:
No, it's hopeful. I think that that's what is the most exciting thing right in the world of fake news and manipulated content and everything else like that. It's hopeful to be thinking about intention and purpose and hear the conversation be really springing up about that kind of all over. Not just in design, Twitter, but sort of all over the place. People being more thoughtful about how tech gets used. Again from Clarity, Ethan Marcotte's wonderful presentation about the idea of creating a tech workers union, not necessarily based around the traditional sense of what a union does, but based upon the idea that we need to be able to control how our technology gets used. How is our creation going to be used to benefit this world? And I think that that's a really interesting thought, right? That like, as an inherently creative enterprise, as, as technology tends to be, how do we control how our creative thoughts and our creative ideas enter the world and then ultimately affect it?
Emily Campbell [00:37:00]:
I think we're in this storming phase with technology right now where it's normalized, but it isn't quite understood at its full capacity. So people not understanding how to deal with fake news on the Internet is a perfect example of that. But as we get more comfortable with technology and we realize our dominance over it, that we are not the victims here, we are the ones in charge of this. If we can adopt that intentionality as people, as a community and as a society, that's where you start to get into the really, really exciting territory. When I think about.
Chris Strahl [00:37:35]:
I love that.
Emily Campbell [00:37:35]:
Yeah. I mean, when I think about what excites me most, it's using technology to have a deeper and more immersive experience with each other and with the world around us. AR&VR and reading recently that we're expecting to see consumer grade AR technology in 5 years. I live in Moab, Utah. I have a lot of access to national parks. You go to the national parks and you see people taking selfies. I'm starting to think about a world where people can see through their screen and not just look at their screen. So how can I use my devices to understand the people that came before, the native peoples that have populated this place, the history of human history, and even before humans, the geological history.
Emily Campbell [00:38:18]:
How can I better understand the world around me by having access to this technology at my fingertips but not having to be looking down at it in order to experience it. That's the experience. That's the stuff that really excites me. That is where the technology of design systems and be able to consistently create infinite canvases of content and information across infinite people and contexts. That is what we are just starting to scrape the surface of. But that is what's in front of us and think it will completely change our understanding of who we are and our relationship to technology and what technology can do. And I do optimistically, but I do think that we, we are heading in that direction faster than it might seem.
Chris Strahl [00:39:01]:
Yeah. And I mean, you and I both share this love of the outdoors and specifically for the Grand Canyon. I know you've been down and on a boat a couple of times, as have I, and I would always have this tendency to chuckle at the people that would be floating by, like looking at a cell phone. Like, how is that experiencing nature? And I think that as I get older and more experienced in understanding how technology, it evolves, and it's kind of placed inside of the human psyche, thinking about that as a way, as an opportunity to extend people's understanding of nature is something that I hadn't really thought about until recently. And I really hope someday that somebody can walk up to the edge of the Grand Canyon, pull out a phone and learn more about the place that they're standing instead of just wanting to take a selfie for Instagram. Not that there's anything necessarily wrong with that, but in national parks, as in a lot of things, there's always this. This idea of preservation and access and the balance that you create between those things. And I think there's similar conversations to be had around privacy.
Chris Strahl [00:39:59]:
There's similar conversations to be had around power systems and technology. But I think that you're right that so many people feel like they're a victim of technology instead of the person in control of the technology. That that is something that needs to change and is going to change over the next decade.
Emily Campbell [00:40:15]:
I agree. And when I think about the opportunity for technology to improve our relationship to each other, to nature, I'm with you. It really excites me.
Chris Strahl [00:40:23]:
Well, Emily, thanks so much for being on today. It's been really great chatting with you. You know, kind of meandered all over the place, social commentary, commentary about nature, the relationship of human beings to. To one another, economic theory, and even flocks of birds. I love being able to share these moments with you. Thank you so, so much for being on, and we really appreciate it.
Emily Campbell [00:40:40]:
It was a pleasure. Thanks, Chris.
Chris Strahl [00:40:42]:
That's all for today. We'd love to hear from you with questions, ideas for new episodes, beer, recommendations or comments. You can find us on Twitter hedspod. Cheers. And thanks for listening to the Design Systems podcast.
richard banfield [00:40:56]:
Great. Well, that's a wrap on today's conversation between Emily Campbell and Chris Strahl. We covered a lot of ground on this episode, from the evolution of design systems as a shared language between teams to how designers are shifting their focus from screen by screen layouts to reusable, scalable patterns that ultimately drive the consistency and the personalization that we're looking for in modern digital production. I think the big takeaway from this conversation was that successful design systems aren't specifically about those point solutions, about the tools. They're about reducing the silos or at least blurring lines between the silos within organizations and fostering co ownership, co authoring so that we're all participating in that experience of building something and ensuring that designers, developers, engineers, PMs, everybody that's involved in the same process ultimately is speaking the same language. Even if they don't have the same skills or they don't have the same backgrounds, they're ultimately going to be collaborating because they're learning to speak the same language on this platform. This is definitely one of my favorite DSP episodes. Emily and I work together and I really, really love the way that she approaches problems like this.
richard banfield [00:42:12]:
I hope you enjoyed it as much as I did it. Rumor has it that Emily is doing great work in AI as well, so I invite you to kind of check in on her and if you'd like to learn more about Knapsack or join our Patterns Leadership Summit to have these in depth conversations in person. We are hosting events with people like Emily and obviously other industry leaders around the country. So check out Knapsack Cloud and find the Events page under the Resources tab and apply. We'd love to see you there. See you next time.