A transcript of Episode 268 of UX Podcast. James Royal-Lawson and Per Axbom are joined by Brad Frost to discuss what target size is, what it means, and what to consider in your designs.
This transcript has been machine generated and checked by Bevan Nicol.
Transcript
Computer voice
UX Podcast, Episode 268.
[Music]
James Royal-Lawson
Hello, everybody. Welcome to UX podcast coming to you from Stockholm, Sweden. We are your hosts, James Royal-Lawson.
Per Axbom
And Per Axbom.
James Royal-Lawson
Balancing business, technology, people, and society, with listeners in 199 countries and territories all around the world, from Pakistan to Cyprus.
Per Axbom
Today, we are bringing you a past guest of the show: none other than Brad Frost, a web designer, speaker, consultant, writer and musician, located in beautiful Pittsburgh, Pennsylvania, as his website says.
James Royal-Lawson
Now, the first time we talked to Brad was back in 2013. And that was eight years ago, and when we talked to him back then it was just when responsive web design had basically taken its first steps, and it was just before Brad had started to do his work and writings around atomic design, which of course, has been released as a book after that. So it was interesting to listen back to that episode and see how he was forming the seeds of thoughts that then led to some of the work he’s been doing with atomic design. And then how much he’s been working with design systems since then.
[Music]
Per Axbom
So you sped through the history of the web, really. And you go, even through Geocities, and MySpace and the rise of mobile and app stores, and all the way to this problem of creating three comps of the same design that we were all doing some years ago. And then you were talking about “we need to blow up” the notions of how we create digital experiences and “blow up” our user interfaces. And when you said that, I was thinking that probably means, when blowing up our user interface, it means that we bring it down to components. But I wasn’t sure.
Brad Frost
Yeah, yeah, no, that’s right. That’s essentially probably where I was hinting at things in 2013, even whenever we are talking, about responsive design, and that’s what led to one of my first projects, which was called “This is Responsive,” which was a collection of responsive design patterns. Because, as I was getting into all of this in 2010, and all of that, we are sort of creating these experiences, and it’s like, the whole page isn’t the problem. It’s not everything, all the different components of that are sort of uniquely challenging, or can be uniquely challenging. Some things like text just kind of wraps to the next line. So you don’t even really have to do anything to that. So it’s like, ‘Okay, so that’s not the issue.’ But the issue is things like, you know, navigation patterns and things like, you know, tabs and accordions and data tables, and all of that stuff. And so, it was really through that responsive design lens that sort of led me to start breaking things down into components, and to start focusing on them as isolated chunks of, you know, their own worlds. And that hasn’t stopped.
So so you know, basically, that’s what I feel like, yeah, again, since the last time I talked to you, that’s more or less what I’ve been fully committed to has been sort of growing those ideas, executing those, you know, with a bunch of different clients, working in all manner of different tech stacks and technologies and all that stuff, handling a bunch of different things. But the gist of it remains – it’s like how do you create your own set of components that sort of help solve whatever user interface problems that your organisation needs to solve? And how do you do that in such a way that team number one, team number two, team number 17, are all able to sort of use the same stuff. But also, again, there’s there’s so many nuances and other sort of challenges, or we’ve done a bunch of multi brand ones, so like themeable design systems. So how do you make it so that these in one of our clients 600 brands, how can you sort of flow their distinct brands through the same underlying components?
James Royal-Lawson
You just said 600 didn’t you?
Per Axbom
Yeah, okay.
Brad Frost
Pfizer. Yeah. They’re big company, and I can’t take credit for developing the COVID vaccine. But we did help them. So, I don’t know, we could sorta kinda…
Per Axbom
It’s a team effort.
James Royal-Lawson
But 600, though, because I mean a lot of design systems really are used or adopted most, I guess, at the bigger organisations because that’s where the problem space becomes more apparent when you’ve got multiple brands and so on. But 600 brands, that’s actually so big, it becomes an interesting challenge in itself, because you surely can’t you can’t standardise across 600 in a visual way. I mean, this must take you into some kind of under the surface aspect of the design system.
Brad Frost
Yeah. So that’s exactly right. The aesthetic layer is just totally up in the air, right. So you just have to treat it as you know, each button, each brand is going to have its own background styles, border radius styles, box shadow sizes, you know, the typography, all of that the aesthetic layers valuable, right? So you just kind of treat that as like a black box. But it’s like, what’s the underlying bones of all of this? What’s like the sort of structural foundations? What are the naming conventions and the architectures and all this stuff that you can put in place that can be shared? Because at the end of the day, a button is a button is a button is a button. So how do you actually get that benefit of speed and quality from not having to rebuild different buttons again and again, just to accomplish different aesthetic results? And so that gets really, really fun. And what it ends up being – the sort of analogy I use is, y’all remember CSS Zen Garden?
Per Axbom
Yeah. Oh, my God, I hadn’t thought about that in years.
Brad Frost
But that’s what we’re talking about. It’s like, same basic underlying HTML, just componentized, right. And then we basically are able to sort of hit a separate layer in the sort of CSS and token layer or whatever, define whatever you want, and then just sort of flow that stuff through the same bones. And so you get accordions that open and close without having to rewrite that functionality, right. You get buttons that do what they need to do, get everything else that you need, but they just look wildly different from brand to brand. So anyways, it’s been a heck of a lot of fun solving these problems, because what we’re learning is that design systems are like a constellation of about a couple dozen subsystems. And with each new client engagement, with each new sort of design system that we build, I feel like we’ve been cracking different codes, whether that’s typography, colour, icons, deployment, governance model. Some of the nitty gritty, actual web design development stuff, but then a lot of the things are about the cultural, organisational, inner, interdisciplinary cross team, whatever, all of that stuff, the human stuff. And so yeah, so it’s been a wild ride. It’s been a lot of fun. But we’ve been, you know, each new project has like, ‘oh, here’s an interesting wrinkle.’ There’s always sort of something new to dive into and codes to crack and we’ve been having a blast doing it.
James Royal-Lawson
Yes, we’re coming from the angle of trying to streamline code production, but then also streamline design and those two kind of major aspects of it, but it filters out, spills out into everything else. But ultimately, you’re you’re being you’re organising, creating something structured, it’s structure and organisation.
Brad Frost
That’s right. Yep. Yep. And bringing that to the world. I feel like object-oriented code predates the web, so that’s kind of been around for a while. So in our experiences, developers don’t necessarily need to be convinced of a lot of that. But, in the world of design, the design landscape and tooling and whatever and mentality and stuff, hasn’t been historically so rigorous, I guess, or systematic with it – with the exception of a few kind of well known design systems and brand systems from the 60s 70s and 80s and beyond- but whenever it got into the world of interface design, we had Photoshop and you open up a Photoshop file, and it was like, “layer seven, copy 36,” you know, and it’s just like an utter and complete mess. And we and then eventually we got like Smart Objects where it’s like, oh, here’s a component, you could drop this in, but they’re self contained, so if the button says, click me, you can’t edit that.
So it’s like, it’s really only been within the last 5, 6, 7 years, maybe that tools like Sketch, and now Figma, and XD, and the rest of them, have really sort of gotten into the game of “Oh, designers need to work with other designers. And we want them to be sharing the same language and stuff like that.” But even just, for instance, Figma launched within the last six to eight months their variants, which is you could create a component and then create variants of that same component. So instead of having to have, ‘here’s my primary button component, here’s my secondary button component,’ you could actually have a button component with a primary and secondary variant. And that gets you so much closer to how things actually play out in code. So I bring that up, just because this mentality of like how to actually do this and think about this stuff in a systematic way, in the world of design is actually a much, much newer endeavour than what the tooling and stuff has historically supported. So it’s been an interesting ride to help bring a lot of people up to speed on thinking in this more rigorous and systematic way.
Per Axbom
I’m seeing in front of me, that famous image when you’re critiquing usability, where you have two spray bottles, black and gold, and one is the fly and insect killer, and one is the canola cooking spray. And they both have the same design, same yellow colour, same font, and you can’t tell them apart. So I think that’s one of the things that people bring up a lot when you’re talking about design systems. And where we are at today is when you say, people have been doing this now for five, seven years – I think less than that, less time than that, actually in Sweden, if I’m going out on a limb here – but, so what are the some of the problems? Why are design systems failing? What are the some of the problems you’re seeing?
Brad Frost
The biggest reasons that design systems fail, is that they don’t take into account the environment in which they’re being deployed. Any designer developer… Yeah, I get it components, buttons, okay, sure. I know how to build buttons, I know how to build components. I know how to make cards, and I know typography, I know colour. And then they sort of just dive right in. Right? So the biggest reason that design systems fail is that they fail to take into account all of the human stuff that comes and the cultural stuff at any organisation. And it’s incredible, the different cultural landscape, ducking my head into organisation one versus organisation two versus organisation three. What motivates people, what scares people. The nuts and bolts, like the technology stuff and the tools and whatever, that’s all sort of secondary.
It really comes down to what scares people, what’s motivating people, what gets people raises, what gets people fired, essentially. And you really have to tune the design system to lean into those things and address the real fears and the interpersonal issues that are present at any organisation, right? Oh, these people don’t talk to these people. Right? If the design system doesn’t address that issue, things are gonna carry on and you could be like, I don’t understand we like made this really great thing, why it’s like nobody using it? And it’s because it’s really not about the design. It’s really not about the colour typography, it’s not about the View versus React versus, you know, Angular or anything like that. It’s all about, again, what are we trying to do here? What are you motivated by? What are you trying to get done? And how can the design system actually accomplish that?
James Royal-Lawson
Something I noticed during your talk at From Business to Buttons, there’s a side chat that goes on now, when we’re doing all these digital conferences. And in the side chat, something that really surprised me was the amount of designers who were questioning the whole benefit of design systems. And the whole thing around consistency and a consistent design system is that consistent UI and whether both of those mean better UX? And now, where’s the boundary of consistency? There was a lot more fight back of that than I expected. Is that really just a reflection of the culture and organisational struggles that they’re facing? Or?
Brad Frost
I think that a lot of that scepticism is valid. And I’ll say that consistency from an end user perspective is actually not a primary outcome. The goal of just making good products is for people to get done what they’re trying to get done, whatever that is, right. And so to that end, or framed like that, consistency is a way of helping that along, right, where the cognitive overhead of being confronted with three different date pickers, as you move through a flow from the homepage to the checkout, or whatever that might be. We did like an airline site. And that was a big one there. Date pickers are hard to build, so people just reach for different ones, different teams reaching for different solutions. All of that’s cognitive overhead. And even if it is fractions of a second of new paradigms, or new controls, new patterns that they have to learn, it doesn’t help, it doesn’t help, it slows them down and introduces friction into into the mix.
So consistency is important. But I think the idea, and I think that why that scepticism is a little bit warranted, is that it’s like, that’s not the goal here. The goal is not to just normalise everything so that everything looks the same. Like that’s really not it. When we talk about consistency, that end-product consistency is one thing, sure. When we’re talking about consistency, so much of it is the consistency in the way that we work. And what I mean by that is things like we name things the same and we talk about things in the same way. Whenever we say size, we say size large, size small, not size, you know, jumbo versus size tiny or whatever. You know, we use the term ‘variant’ to denote different stylistic variations of a component. And we use that consistently across the board. And what that consistency does, that consistency of language and consistency of execution and architecture and all of that, that unlocks quality, that unlocks velocity. Those are the huge ones.
So it’s less about, ‘we’re just trying to create interfaces that just look totally the same across the board.’ I don’t think that that’s explicitly the goal of any design system really. But designers like to go there just because it’s this whole ‘Design doesn’t matter anymore. We’re all just like trying to make the same boring design, like crap it out the other end.’ And I think that that’s a very uncharitable take, having built lots of design systems that are very aesthetically powerful and unique and clever. It’s not a ‘No, we just all need to crank out these sort of consistent yet boring designs.’ Sometimes that’s what you need. And that’s good. And for different organisations and enterprises that I work with, sometimes they do just need boring run-of-the-mill thing, because that’s what their world is – enterprise. But other times it’s really splashy, brand marketing kind of stuff and whatever. So decouple that conversation. But by coming back to consistency, it really has everything to do with the people doing the work and being consistent with how we’re doing that work. That is a way more important consistency than the end-user interface consistency. Although there is, again, there is value in having a consistent user experience. But but that’s, again, you could argue about that. And I think that that’s fair.
Per Axbom
As you’re speaking I’m actually thinking that the type of arguments against design systems, where they actually do say it has to do with consistency and the visual aspects, that’s actually reductive in the sense that then you’re actually reducing design systems to only be about the visual, how it looks. Whereas design systems, of course, are so much bigger than that, and are growing in what they actually encompass more and more every year.
James Royal-Lawson
And I guess, Per, you’ve got the individual threat. I mean if you’re a designer and suddenly, maybe you’ve changed job or something, you’re faced with a design system. You know, for a lot of people, that’s going to be, at least a first glance, very visual. And maybe depending where you’re coming from, you’re gonna feel threatened by the fact that all of this design exists and is structured. And, you know, again, depending on your design history, then that may be a difficult transition to deal with. So I guess maybe, now we’re maybe bringing up the importance of onboarding people into design systems.
Brad Frost
Yeah, I think I think you’re touching on something that’s very real, and something we encounter a lot. Designers have taken a lot of time to learn how to draw rectangles, and they’ve mastered tools and multiple tools for drawing rectangles. And whenever you basically say, you don’t have to spend your days drawing rectangles anymore. That scares people, because it’s like, ‘wait a minute, I got really good at that. And now you’re telling me, I don’t need to do that.’ One of the things that my colleague and frequent collaborator Dan Mall – an exercise we kind of do – is we say, ‘Think of the last project you worked on, what’s the one thing that you wish you could have gotten around to, but you didn’t have time?’ And it’s always, ‘Oh, you know, I hate our icons, I would love to redesign or icons,’ or ‘I really wanted to sort of spend more time working through the nuance of the animation styles,’ or ‘I really wanted to explore different typography, because I don’t think that ours is very good.’ It’s like that becomes the job, that becomes the work.
Once you’re free from having to redesign and rebuild this sort of card component for the 16th time, right, you’re able to sort of free yourself up to do more worthwhile, hopefully more high-level tasks. And so a lot of people getting out of that production mindset – it can be challenging, but it does unlock a lot of opportunities. And that’s why we like working with different clients, because we help show them that it’s okay. It’s like, ‘Well, what do I do with my hands now?’ and we’re like, ‘Let us show you. Here’s all these things you can be doing that need work. But obviously, there’s still UI work that can happen. But again, historically, we had all these people on this sort of production hamster wheel. And it’s just not required. There’s bigger fish to fry, there’s more important things. Rather than having to make all the form controls and build those, design those from scratch, figure out a way to cut that form in half, right? Figure out a way to remove and reduce the amount of crap that people have to wade through just to submit that form. Right. So it’s that kind of stuff.
But coming back to your point earlier, the term ‘design system’ is such an unfortunate name, because it just has design in it and so therefore, it’s like design equals stuff that designers do, which means that nobody else really has to care about it. But really, like one of my big soapboxes is that a design system has to live in code in order for it to be successful, right? When a design system is successful, it means that you’re able to go to a URL or download an app and fire that that thing up, right, however you get to it. When you click on that button you’re clicking on the design system’s button. If you’re not at that point yet, you don’t have a successful design system yet, right? You can have the most sort of well-organised Sketch library or Figma library or whatever, but that’s not actually powering real software. So it does involve the developers in a big way in like, and I’ll say, a more important role. We’re talking like a 60/40 split, not an 80/20 split. Obviously, designers are needed. Obviously, UX is important. Obviously, visual design is important. But also, development – front end development is very important as well. So, again all of this lives under the design system umbrella term and that’s kind of unfortunate, just because it really doesn’t fully get to how cross-disciplinary this thing needs to be.
James Royal-Lawson
If you, If you got the chance to rename design systems to something better, what would you call it? That was an awful question to give you wasn’t it.
Brad Frost
Flirkles. Yeah, I don’t know. But it is, again, it’s it’s tough. Naming things is hard. If there’s if there’s one thing that’s, that continues to be true is naming things was fired. Right. So naming something like design systems is, is also hard. So I don’t know,
James Royal-Lawson
I think you’re right, we seem to be doomed to end up having discussions about why things are called, you know, internal discussions about what things are called, we’re still not happy with UX, we’re in a design gets frowned upon by organisations as being “design”.
Brad Frost
Yeah.
James Royal-Lawson
You know, oh. At the same time, we’ve, we’ve been talking about how the vocabulary, the words you use to work together for collaboration are incredibly, are really, really important.
Brad Frost
Yes.
James Royal-Lawson
These kind of conflicts have kind of internal discussions about what we’re called, or we need to call things the right thing, or we’re not going to get on.
Brad Frost
But that’s but that’s, and that’s kind of the beauty of all of this and against it. And just coming back to that sort of consistent language, it’s like, let’s just get together, figure out what we’re going to call this thing, lock it in, call it the same and code and InDesign and, and documentation and all of that. And then – job’s done, right, we can move on to bigger and better things, we don’t have to call a meeting. Because, you know, this vendor, that sort of building stuff is is building rebuilding the same thing that we already have over here, that’s called a different day. It’s like, that’s, that’s it, it’s just like, kind of a dumb, very sort of stupid, like, an obvious kind of thing. But it’s, it’s like naming is hard doing those sort of exercises, like what do we actually want to sort of call this stuff is, is, is hard, but it’s important, but it’s just also important to just sort of commit and be consistent with it, right. And that’s like, one of the things I love to sort of tell the, the client teams that I work with, and help build design systems for, we’re like, we can pick some conventions. And even if we don’t feel 100% about them, so long, as you’re using everything consistently, we’re able to sort of go through and just kind of make wholesale systematic sort of changes in a snap of the fingers, it’s a Find and Replace.
So if we don’t like this name, just sort of go through and like sort of just do it. So long as everything is sort of following the same sort of conventions, doesn’t matter what systems you’re you’re putting in place, so long as they’re consistent within themselves. So that’s that it’s, it’s, that’s like a big, like, kind of freeing thing, because it’s like, it takes the pressure off of, oh, you have this like one shot to get this, right. So therefore, we need to kind of paralyse ourselves and have like four hour conversations about what the name of component or whatever it’s like, just pick something, go with it, commit to it, use it consistently. And you’re good to go. Again, it’s been quite the journey. And I feel it’s been, it’s been fun to kind of reflect on a bit of that journey. And there’s obviously like a lot of work to be done. A lot of really exciting stuff still happening. And it’s we’re not yet at this stuff is totally a commodity or a totally like a solved problem. And even just rewinding to the last time we talked, it’s like response to design isn’t a solved problem, or whatever. But it’s like, you there, there’s now sort of more sort of solid foundation to stand on, which is really fun. It’s kind of fun to kind of be a part of this, well, nothing’s ever fully solved, obviously. But with each sort of passing, you know, project or year or whatever, we sort of like unlock new things, establish new sort of norms and vocabularies and stuff. And that’s really fun to contribute to.
James Royal-Lawson
And I’m, I guess you’re quite excited, too, about going into the age of container queries soon.
Brad Frost
Yeah. Yeah, that’s a big one. And that really plays into the spirit of ‘Look, all these things are super self-contained. Let’s just formalise that. Like, oh, make a thing in isolation, drop it in anywhere. And tada.’ It just it just kind of worked. So I feel like I missed the boat. There’s now been a load of different articles. And I’ve been so busy with my client work that I haven’t had a chance to write my own, but basically, it is what we’ve all been clamouring for for years. So I’m so glad that the It’s finally around the corner here. So that’s great.
Per Axbom
Yeah. For me that was perfect to end on. Thank you, Brad.
Brad Frost
Yeah, well, thank you.
[Music]
Per Axbom
So I have some takeaways from this. I think the first one is around consistency and how Brad is so good at perspective-shifting. He’s saying, it’s not about the consistency of the visual design – that everything has to look the same – that’s not the purpose of the design system. The purpose of the design system is consistency in the way we work together. Because that is what is going to help us make better products.
James Royal-Lawson
Yeah, that was an interesting reflection. One of the things I’ve been thinking about asking, and one of your earlier questions was along those lines, I was going to ask how do you manage a design system, or do you need a design system, when you’re a small company – just a few individuals working with something? And strangely, his example about Pfizer and 600 brands kind of helped me get an answer to that. Because it’s so big and so massive, and so incomprehensibly a large number of brands, that it boiled down to the essence, which was that baseline of working together, having components, a way in which you would name stuff and build stuff as a foundation that allowed you to be flexible with everything else. It’s kind of, ‘Oh, well, yeah, the same thing with just a couple of you, you’re effectively one of the 600. When you think about it as a small organisation.’ So if you set that baseline stuff right and get shared language, ways of working, a bit more organised around that side of things, then you’ve got a system. A system of working.
Per Axbom
At the From Business to Buttons conference, he actually got a question at the end of his talk, ‘Is there ever a time when you don’t do a design system?’ And his answer was actually, ‘No, you always do a design system. Because even if you have a three-page website, just three web pages, the second web page that you make, has to be consistent with the first one: you need to have the same header, the same look and feel. But the design system then is the first web page. That is what you look at to get the code to make the second web page.
James Royal-Lawson
Yeah, you’re gonna steal elements from that to do your next page, whether it’s an official system or not. It’s your it’s your underlying inspiration for page two. As well, the whole thing with consistency, I mean, we don’t we don’t generally set off with the intention of being inconsistent. It’s rarely a goal for a project to be inconsistent. So when we’re talking about ‘should we be consistent?’ Well, I’m not gonna sit there and demand three differentdate pickers, I demand that all the buttons are different sizes and colours. That that would be, that would be a peculiar project.
Per Axbom
Yes, definitely. Another takeaway I have, actually, is how he emphasises that if you work more efficiently, as the design system allows you to do, you get to spend more time on the right things. You actually get to spend more time on being reflective about the things you’re creating. So you can cut down, as you said, you can cut down that form to half the size, or half the number of form fields. But for me, that’s also addressing this aspect of design systems where you’re making everything more efficient. You’re making everything look the same, you’re reducing friction, which was can cause problems sometimes. But given that it’s all about how do you spend the time that you save? If you can spend the time that you save on being even better at research, even better at doing impact assessments, risk assessments, then you’re spending your time on the right things.
James Royal-Lawson
Yeah, I mean, I don’t really have a burning desire to build a drop-down in every project. We probably need one or you know, all these elements, you need them. But I’d rather be investigating looking if the entire thing does its job it’s meant to rather than kind of constantly going back to designing these individual elements, these baseline things. Another interesting aspect of this, and Brad touched on it, we have kind of parallel worlds these last five, he said 5-6-7 years, with Sketch, Figma, XD, where we’ve got designers building up UI libraries in these tools. And then we’ve got engineers coding the actual elements in a web page or in an app and so on. And these, there isn’t any double sync between these two worlds. Or it’s very limited. As in you know, you update the Figma file, it doesn’t update the components automatically in view. And if you update the React components, they don’t automatically update the Sketch files. The connection between these parallel worlds and then the other world of the public documentation or your public documentation around the design system, there is still a lot to do around the interplay between these things.
Per Axbom
That’s a huge risk. That’s where it can really break down.
James Royal-Lawson
Yeah, and you get to a point of efficiency working on these things. But then it needs to live its own life and evolve, and not just be a static reference point.
Per Axbom
And my third takeaway is around the common vocabulary, which he was emphasising how incredibly useful it is that we actually decide on having the same words meaning the same thing at the beginning. But what I did reflect on then is how we might not be starting at the level we should be. Because we’re not perhaps defining what design is. But I’ll bet that every designer in their project has a different version of design. And I think that it’s healthy to talk about it. We may not always agree on it, but it’s healthy to at least get the views of everyone and let everyone have their say. What is a design system?
James Royal-Lawson
Exactly. I think you’re right there, because we all have an opinion about what UX is. We all have an opinion probably about what design is. We all have opinions about what designers should do and what engineers should do, and shouldn’t do. We’ve got plenty of opinions. Our industry is not devoid of opinion. So yeah, you’re right. A conversation upfront is really useful. Again, we’re talking about when you are starting a design system, but as we talked to with Brad, a lot of people now are going into jobs where a design system has been around for years, half a decade, or even longer depending on where it’s got its roots. If it’s got its roots in style guides and branding of before, then you’re not starting from a blank page.
Per Axbom
That’s right. And that relates to what you were saying about onboarding and the importance of onboarding new designers into design systems. And I think giving them the space and allowing them to have opinions is really important, because that will help them accept the design system itself.
James Royal-Lawson
Oh, now I think about onboarding people generally in organisations. Because I mean, if your design system is a fundamental building block for your organisation, then awareness of that, and understanding and collaboration around the language used in it, and the application of the design system, is something for employees and co-workers outside of the design and engineering space.
Per Axbom
Wow. We have some recommended listening for you. Three episodes, I think. The first one, of course, is our first chat with Brad in 2013, which was Episode 51.
James Royal-Lawson
Yep. And second one, we talked to Jina Anne, who has done a lot of work with sound systems and Brad himself credits Jina Anne as being one of the important women involved with the early development of some of these design systems, and the way we’re thinking and working with them. That is Episode 163. Very good hands on practical episode to do with her story of working with design systems at Salesforce.
Per Axbom
Right. And then we also have an interview with Sophia V Prater. And back then she was actually Sophia Voychehovski, talking about object-oriented UX in Episode 135. You will maybe remember that Brad mentioned object-oriented programming. So that was a fun conversation about how to bring that thinking into UX.
James Royal-Lawson
And if you can spare a little bit of your time, then please join our little community of volunteers. We are always looking for people to help with our transcripts for polishing the transcripts. And also for building our links that we add to our shownotes page.
Per Axbom
Remember to keep moving.
James Royal-Lawson
See you on the other side.
[Music]
Per Axbom
James, what do you call it when a cow is doing surveillance on another cow?
James Royal-Lawson
I don’t know. What do you call it when a cow is doing surveillance on another cow.
Per Axbom
A steakout.
This is a transcript of a conversation between James Royal-Lawson, Per Axbom and Brad Frost recorded in June 2021 and published as episode 268 of UX Podcast.