Ep 7: What’s in a Name? Designing Design Systems with Jason Bernert
Language turns abstract ideas into tangible ones. Having a shared language allows us to understand one another and work together.
In this episode, Engineering Lead Jason Bernert of the Washington Post walks us through Design Systems: what are they, and how does this system shape the shared language and experiences his development team, reporting, and the readers who engage with the newspaper’s digital content.
This is a special episode because Keith believed everything Jason said was gold. We’ll be doing part two next week, when we’ll dig into how design systems have historically shaped Dungeons & Dragons, and how those systems are rapidly changing the RPG.
About Jason Bernert:
Jason is an Engineering Lead at the Washington Post. Before that, he worked as a News Designer, Senior Product Designer, and Senior Engineer for the paper, where he helped design and develop products like The Washington Post design system, The Post’s 2020 election design system, multimedia stories, apple news articles, and internal publishing tools. His career in journalism began at Oregon Public Broadcasting.
Jason is an Oregon native, hammock enthusiast, and always on the lookout for a great sandwich.
What is a design system?
A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications. Like LEGOs.
There are a variety of ways that organizations create and manage their design systems, which Jason touches on in the episode. Want to know the various models of design systems? Check out the article by Nathan Curtis on Medium here.
-
Sara (00:00):
Hi, this is Sara Shepherd
Keith (00:01):
And this is Keith Hazen Diehm and this is Dungeons and Documentation,
Sara (00:06):
A podcast where we explore information architecture through the lens of role playing games.
Keith (00:10):
This week we'll be speaking with another Jason, Jason Bernert has a long career in technology and journalism, and presently is a software engineer for the Washington Post. We got him into the studio to talk about design systems and style guides, but our conversation became a little more wide ranging and was on so many topics, we decided to devote this episode entirely to our interview with Jason.
(00:36):
Next week we will be coming out with what would normally be part two of the episode. We'll talk a little bit more about what names do and don't do within the world of Dungeons and Dragons. And then we will also go on to talk about how to create a style guide for your campaign. So look forward to that here in a couple weeks. But for now, please enjoy our interview with Jason. We certainly did.
(01:09):
So last I knew you worked at the Washington Post, but I understand you don't do that anymore, Is that right?
Jason Bernert (01:13):
I still work at the Washington Post, but I've changed my role now for the fourth time in four years. You know, you can't be caught being too many, doing too many things. Yeah. Yeah. I think if you're doing the same thing longer than 18 months, you gotta mix it up, <laugh>. It's a natural cycle of life.
Sara (01:28):
It is. I agree with that.
Jason Bernert (01:28):
I've been a news designer, a product designer, and now I work as a software engineer working on novel computer aided reporting techniques. So that means like, how can we build software to make journalists lives easier and also like, so they can get a story up more quickly or more easily. so it's a lot of like really kind of niche software to solve really specific problems.
Sara (01:49):
Can you give us an example of something that you're working on? If you can say.
(01:52):
I'll give you an example. Like a past project we worked on mm-hmm. <affirmative>. So for instance, during like the January 6th insurrection mm-hmm. <affirmative> it was all captured like on parlor, you know, that video capturing Oh yeah. Platform. And then that platform closed down. But before that, we worked to scrape and catalog all those videos, so all of them would be available to our journalists to like recreate the event. And so then you can kind of run different analysis over it, like facial recognition to figure out who was there. Wow. When those videos were taken, where those videos were taken, you kinda like piece things together. So it's a really big like, technical task, but it's also a journalistic task. So the newsroom engineering team that I'm on kind of combines what the newsroom does with what engineers do. So if there is a journalism problem that can be a very like technical problem, like downloading thousands and thousands of videos, like we step in and try to help that, that helped them out.
Keith (02:42):
Got it. So the guy in the suit, in the fedora with the press sign in his hat is out there like collecting data and then you're sort of interfacing them with the 21st century basically.
Jason Bernert (02:51):
Well, you know, journalists I think are in the 21st century, but we try to -
Sara (02:55):
No one wears those hats anymore.
Jason Bernert (02:56):
It's true. Didn't anyone tell you that, that Keith?
Keith (03:00):
Oh, no. I mean,
Jason Bernert (03:01):
Oh man. I'm not gonna tell him.
(03:04):
No wonder I'd never see any journalist. I'm always looking for the person in the fedora with the press pass stuck in it. Yeah. I thought, I thought journalism was a dying trade
(03:12):
That's everyone thought was because the magazines and newspapers weren't being published anymore, but you were just looking for the hats.
Keith (03:18):
Yeah, that's right. I just couldn't, didn't see 'em. Yeah.
Jason Bernert (03:21):
Oh man. So we help the people on the hats, Keith.
Keith (03:24):
Yeah. Good. I mean, they need it. There's very few of them left.
Jason Bernert (03:27):
Yeah. So we have so that's what my team does. We kind of interface between the world of engineering and the world of journalism in the newsroom. Yeah. but before that I was working on a the Washington Post design system. So we have an internal design system that allows designers and engineers to easily talk about what components to use and what like design foundation to use like color or spacing and all these things that help build and create like websites and UI for the Washington Post. Mm-hmm. <affirmative>, whether it's on the Washington Post homepage or an article page. Like we helped kind of design all those things. And so when it comes to systems, spoiler alert, those are the things that I'm really passionate about.
Sara (04:03):
And was that for print and digital or just digital? Like is there the print side of the post completely separate from the online app experience?
Jason Bernert (04:14):
So what I worked on was the online design system. So we already kind of have a system for like the newspaper and how it lays out and how there's like layouts and columns and type faces and the line height for those type faces and how we style certain headlines. And so that's been established for the last hundred plus years and we kind of designed it every couple decades, you know, redesign it. So it's that the paper's coastal along just fine. However, like everything we're building online is like constantly evolving. Like everything we did like a year ago has already been rethought, you know?
(04:43):
Whereas the newspaper can kind of, you know, luckily for us, newspapers haven't really changed too much in the last a hundred years when it comes to design. So that one's like, okay, it can kind of coast on its own, but the design system I was working on was very like, digital for it. So it was like how we built things online, How should things look in the app, kinda have all those digital experiences?
Keith (05:02):
Well, so I mean, it occurs to me that what you're doing and what you're working on is very important and you are sort of uniquely positioned working at the Washington Post in order to do it, be supported in doing it because you're sort of working on how to make a newspaper in the news relevant in the 21st century.
Jason Bernert (05:22):
I mean, computer aided reporting has been around for decades. Some, the early ages of community aid reporting was like when the computers came out and you switched from a typewriter on your desk to a computer on your desk. Reporters and journalists were already thinking about like, well, how can we use this to help tell stories, right? Like, how can we convert these big handwritten notes into a spreadsheet? Right. And by cataloging all this data, and then like, you know, summarizing it was in early, early days that was like computer aided reporting. It was kind of the work we're doing. It was just the work that was going on 40, 50 years ago instead of today. But as we know, with all technology, it gets, it grows and becomes more and more complex And so over the years here, our, this is like, it's not a concept what we do, right. We just try to do it a different scale. So even in small, smaller newsrooms, local newsrooms, like Oregon Public broadcasting, my former newsroom just up the way like
Keith (06:13):
Opb mm-hmm.
Jason Bernert (06:14):
Support your local station. What, what you know, there's the exact same process happening there, but it's often, when it's a smaller newsroom, it's usually like, you know, one nerd who went to journalism school, but how was you and a few others up there. Like Tony sh is a investigative reporter up there who does the same thing, but, you know, like, how can I use databases or the compu, you know, various like computer reporting techniques to like, make my life easier. How can I use it to like find a story that anyone else does? Like if you can pull a database and start running queries against it, then like, that's a great lead for a story. You know? So like, why are there, you know, like these outliers in this data set and then find who like knows and can talk about it, you know?
(06:52):
And that's, you pick up the phone and call the person, like who's deep inside of like a government organization that handles the data and it's the first time they talked to a journalist like in years if not their whole career. And then you have a great lead going. So I think like, it's not a new concept. What our department does, we just do it a different scale. So the Washington Post newsroom is very large, where like at OPB it's a maybe a hundred people working on content when I was there. And like the newsroom is maybe like 30 ish people and like, but the majority of 'em already had dedicated things. So like my group is like nine people, you know? So, you know, it's like maybe like one or two people working on these things.
(07:24):
But in the newsroom, the Washington Post for like a thousand journalists, so there are still plenty of journalists, they are working on projects at different scale. Right. So when you work, talk about like the January 6th story. No one person is gonna look through every single video to try to identify a face. So like how do you use like no longer the Excel spreadsheet on your desk to like summarize data, but how do you use facial recognition across thousands of videos to figure out who was there that day? And so like as the scope and scale of technology grows, so does like the support with a newsroom to try to match that. So that's why like our department exists is because there's just so much more information and data, like, and it's, you know, continually growing and also the ways to like, analyze and understand that data is also growing. So it's become an industry in of itself to like have teams like work on this space.
Keith (08:13):
Okay. So let's dive in a little deeper into that space and talk about what we actually came here to talk about. so let's just start with a very simple question. What is a design system?
Jason Bernert (08:26):
Yeah. So design systems also have been around for a long time. but they've kind of grown and, and shaped in different ways. And so I think some of the early design systems I'm thinking of for like when for instance like NASA needs to be branded, right? And they have their little like logo and they wanna know how it looks on like their letterhead and they wanna know how it looks like on the side of the building or side of a rocket. They had like style guides that said like, Okay, if you're gonna put the logo, make sure it's like in the upper right corner, the upper left corner, and make sure it's like this far away from the edges of the paper. so it's been like design guidance for a long time.
Sara (08:58):
So a style guide and a design system, are those synonymous or is it like a rectangle square situation?
Jason Bernert (09:04):
It's more of like a, like a Venn diagram. And the style guide is just one piece of the Venn diagram that fits into a design system.
Sara (09:11):
So when's design system meets physical element style guide applies?
Jason Bernert (09:18):
Sort of, So I would say like a design system is the all-encompassing set of foundations and guidelines in some cases rules on how to build, design and write content for a company. So for instance, style guides may just be how to put your logo and what color it should be. But a design system may also include, well, how do we write call to action language on a button? So is it click here, click me, like subscribe, submit, Like what language do you put in there? And that can also be under a design system. How do does a user like interact with a like, product online? So for instance, like a piece of paper is not gonna have motion or animation or, and it's not gonna have transition effect, right? Cause it's a static medium, but our phones like, you know, we flip from one page to the next or we might things might fade or fade out. So it's also like how do you experience those things as well?
Sara (10:13):
Ah, so additional decisions, like "we're not a fade company."
Jason Bernert (10:15):
Yeah,
Sara (10:16):
We're dissolved
Jason Bernert (10:17):
<laugh>. It's like when you watch a Star Wars like movie, you know, George Lucas is like, "No, no, no, no, we're a star white family. Yeah. We're not a fade family." You know? so it's like those are like design session system decisions that help kind of make up the entire system. So like style is part of it, Language is part of it. Interactions, part of it, how you develop things is part of it. Like architectural decisions is part of it. So it's in the over encompassing like company decisions around how you build and create experiences for your audience.
Sara (10:44):
And how many people were working on the design system for the digital side of the Washington Post?
Jason Bernert (10:50):
Yeah, so this is another thing. This is a whole other episode. Okay. But there are different systems of how to manage teams like design systems. So for instance, <laugh>, we used a federated approach and that means there's a core group of people. So there was anywhere between three to five people that were committed to the design system at all times. So I would sit down with designers and developers. we had another engineer and we had another designer and a project manager. and we would all kind of talk about like, what are the, except for the system, what things need to get done. But then for instance, if a designer comes along and like, Oh, I'm making this new component. it's a series of faces and circles. It's gonna be called like an avatar. And like there's rules to it, we would then like collaborate with them. So they would work part-time, maybe they would work like on the article page, the watching post, the homepage, they would come and collaborate us in a federated system. So they would come and help us out and help build that product design system, contribute to it, and then we would kind of help maintain and refine it. And so we would have designers and developers constantly coming in and out of the design system. There's always four or five like committed, but then you had, you know, dozens of people helping contribute to it.
Sara (11:58):
So you were like a gelatinous cube. And then someone with a unique idea would be assimilated into the cube to create a rule. So they have a unique idea. And then the system assimilates that idea and into standards, right? Like the Borg.
Jason Bernert (12:12):
Kinda like the Borg. No, except the idea is like
Sara (12:14):
But they're released back once they're, once the usefulness is sucked from them, you get them back.
Jason Bernert (12:19):
No, no. So it's more of like the Borg would come to you and be like, You're part of the bo now. Sorry. well if you want people to adopt a system, you can't be like, this is the system, you're using it now. Sorry, I do ask, be like, this is our system, we're building it together. So that way you have joint ownership of those ideas. Cuz the worst idea, if you're a creative person or you like building things, the last thing you want someone to come in and be like, No, no, you're doing your job wrong. This is the blue, not that blue. This is the border rate. It's not this border rate. So there's like a give and take of like, no, no, no. Like I design this icon that I really, really love and now that my no another design's working on it, I can then advocate for that work. And so they're not only advocating for their own work, they're also advocating for the system. So a fed approach allows people to feel not only like they've contributed to the system, but they also own that system.
Sara (13:03):
So it's like Vecna, when he went to the upside down, he still got to have his unique identity, but he was working for the hive mind. Is that correct?
Jason Bernert (13:09):
It's like if you're a state in the US government, you can have your own laws, but you also have some of the federal laws.
Sara (13:14):
Okay. And if a state has a really cool law, then sometimes the federal government will be like, Ooh, tell us how you did that and maybe we'll adopt it for grander applications. So
Jason Bernert (13:24):
What would be like a contrasting
Sara (13:25):
System to that? Yeah. Like is there a, you know, authoritative?
Jason Bernert (13:29):
Yeah. Gosh, I was trying to remember the names for it. Communism, there is like a centralized system and that is more of like, we decide and distribute it downwards. Mm-hmm. So it's more like a waterfall fall system. You
Sara (13:38):
Gonna pull out your phone if you wanna reference specific names.
Jason Bernert (13:40):
God, I have to look it up. I don't know. It's fun around my noodle somewhere. Want me to look it up for, for the, No, that's
Sara (13:45):
Right.
Jason Bernert (13:49):
It's fine. We're in a time crunch here. We can link, we'll link to it in comments below, Smash that subscribe. <laugh>. But what I'll say is there's like this, So we had a federated system. There's like a core group, but the people flow in and out contributed. There's the other system where there is a core group and they tell other people, this is how you need to function. And there's another option where there's no core group and you just kind of like all kind of collaborate together and hopefully it works out.
Sara (14:11):
Okay. So what sorts of decisions were you making and how did that shape the experience of working there and the experience of people reading the news? I don't know if there's an example of like, someone had an idea for a new feature and it was ambiguous and then the federation helped them create a consistent rule, which then led to the development of a new button.
Jason Bernert (14:39):
Yeah. Yeah. So I think what a design system works really well for is taking like those good ideas that are kind of one offs, right? Like I have a one feature, one specific use and then making it more applicable to other reasons why you kind of generalize it. Allow it to be reusable. And so for instance, like the Washington Post had a feature where you could gift up to like your, if you're a subscriber, you could gift an article to someone. So for instance, hypothetically if I had a subscription to the Washington Post and I wanted to share it with Sarah, I could send her a gift like link. It's like, here's the link, you can come and, and read this article for free, even though it's payroll. So thoughtful of you mm-hmm. <affirmative> mm-hmm. <affirmative>, mm-hmm. <affirmative>. and so definitely not just like sharing your accounts, but so they might have a great idea for one feature, right?
(15:24):
So we had a button, we put it like on our article page, you can click that button. but the idea is like, okay, how, if someone else wants to add another feature to that article, right? Like maybe we have a new like share on Reddit button or something like that. How can we use a lot of that logic and design decisions so we can get that feature out more quickly? Ah, so for instance, for the design system we already had an internal component. It was like a button icon. And so when you, sometimes you just see an icon that's a button, you know, it's like, it's like a little heart this post on Instagram or Facebook, or I'm gonna like up upload this on Reddit. It's just like a little icon of a heart or a, like a hand holding a thumb up.
(16:04):
So we had like an internal component that we called like the button icon that you would use. And we had a suite of icons of like a hundred icons. And then from there they can composed up this like tray of button icons for an article, which we called the article action bar. So we instantly started building up this like, vocabulary, right? So that way if you're a designer or developer or product manager, you could say like, Oh, can we add a new button icon to the article actions bar so else people can share this more easily on Reddit, Right? Whereas before it'd be like, Hey, can we add like a new feature as like an action on the article? Kind of like where those buttons are right now, You know, like the circular ones and like can we like add it towards the end?
(16:44):
And so there's like a lot of like words you could use to fill out ideas. So like, it's kind of like a, I have think like a dictionary, whether it's just psych, that little gray circle round thing that has an action at the top of our articles, you're be like, Oh, it's a button icon in the article action. So quickly you're giving your like coworkers a bunch of more detail information with three words instead of like three sentences. Mm-hmm. <affirmative>. Yeah. so like, the design system work wasn't just like, how does it look and how does it function, but how quickly can you communicate higher level ideas to create new features? So for instance, your question about like, well how does that work to make a new feature? Is that we already had like the button icon built, We already had like this article action bar built.
(17:25):
And so when we wanted to like make a gift button, all we had to do was kind of like add that extra logic in for that button and kind of ship it out that component. So, you know, people start to see like little small microsystems within a larger system and they can kind of start to kind of play and design and build within those places. So for instance, a product manager might see a whole article, but then they might see like the little article action bar of like, well, what can we add in this space? What can we do in this space? Space? So it allows people to kind of take a really big amorphous idea, kind of break it down into smaller and smaller chunks in their mind, which I think is a reoccurring theme of this podcast.
Sara (17:57):
Yeah. And creating consistent language. And in the process of determining what to call it, you actually were more clearly defining what it does versus like the, the whatever icon we want area became the article action bar. Because these are actions people can take. It's not passive,
Keith (18:18):
Right? You could just call it links at the top of the page, but then that makes it much more amorphous and people might start putting whatever nonsense in there that doesn't, doesn't make sense to be in there. But when you call it an article action bar, all of a sudden that tells you exactly what it does and exactly what you could add to it. And if someone had an idea to add Yeah. Yeah. Or if someone had an idea to add something, well, where would we put that? Well, how about the article action bar? Mm-hmm. <affirmative>. Mm-hmm.
Jason Bernert (18:42):
<affirmative>. Yeah. Yeah. So I love like semantics, like the concept of naming things to give them meaning with the name, I know like all names are made up, right? Mm-hmm. <affirmative>, but we have other words like action and bar and button. And these have like, you know, metaphors in our brain that can kind of click. Sure. And so how do you use language to be very descriptive when talking about your work? Mm-hmm. <affirmative>. because yeah, it kind of gets rid of that cognitive overhead of like, Oh, how do I describe this thing? How do I talk about it? And you can just get your idea right out there. And so there's like the design system part, which is like, how does this look? How does this function? But the communication systems is like something I always really love because, you know, I was a journalist who works in engineering, surprise.
(19:19):
I love both technical things and word things. Mm-hmm. <affirmative>. So I think that's the thing that I always really loved is like, well, what do you call this hue of red? Mm-hmm. <affirmative> and what name, what meaning does that name have? You could say like, Oh, this is red and this is dark red. And those have like hex codes aligned to them. Or you could say, we were talking about this earlier, like this is red 80 and red 100 and you know, that red 100 is like 20 degrees darker than red 80. Right? And that way if you have like a blue 100 and a blue 80, then instant, like, oh, well I'm sure red 80 and blue 80 might have the same like darkness, right? They might have the same, they're not as light as maybe like blue and red, 100 are mm-hmm.
(20:00):
<affirmative>. And so then you can kind of start using a system of like colors that already has like inherent meaning. So like giving names, like those things can like really help people understand. And then you can give red 100 a name of warning. And so like, Oh, I want it to be our warning color. And so no longer you're talking, not talking about a hex code anymore. You're not talking about red anymore. You're talking about this idea of like, how do you convey warning to a user? And so then neither the designer or the developer has to think about like red or hex codes. They just think about the warning color. And so, and then it has both kind of semantic meaning like, well warning kind of like alert, you know, But also it has the deep like like technical meaning cuz you already have like the, the color red subscribe to it and you have the he code subscribe to it. So it allows you to like have like higher meaning to simple like
Keith (20:48):
Ideas. So what you're saying is not, you've layered names on top of that color. So you started with a hex code that made no sense to anyone except someone who is, you know, very sort of knowledgeable on what hex code data means. Mm-hmm. <affirmative>, you went to a red 80 red 100 and then you added, well this is a warning red, our red 100 is a warning red, but warning red still means to you red 100 and hex code, whatever.
Jason Bernert (21:14):
Yeah. Yeah. So that allows everybody to start talking to like the same language, right? Mm-hmm. <affirmative> because maybe like a product manager doesn't know their hex codes, right? Because it's like, why would they, you know, and maybe like a developer doesn't wanna remember the user behavior of colors, of like, Oh, why do we use blue? Why do we use red? Like, they don't even remember those things, right? Right. Like, you get a successful like green check mark web, you've bought your things in your cart, you know but a project manager likes those things, right? So like, oh, we need to convey warning or seriousness here. Like, oh, we need to convey success here. And so if both the product manager, developer and designer are all talking about the word success, and those all mean something unique and specific to them, right? Like, Oh, this is the variable I use in the code, or this is the hex code I use in my design. Or this is the meaning of success for a product manager. They're all now using the same word around the same concept, but it has different locations for their work. Mm-hmm. <affirmative>. And so I think that's that higher level communication that I really love, right? Because before we were all trying to like speak our own languages to like each other, and now we're all kinda using a shared language.
Keith (22:16):
But then the linchpin of that is that you have, you have to have a dictionary of terms so that if, you know, if the project manager and the programmer are talking and the programmer says, Oh, we'll use red 100 and the project manager can't recall if red 80 or red 100 was warning red, then you need to have some sort of intermediary and the, and let's say the, you know, the designer doesn't recall, oh, was this warning red or caution red or you know, whatever. So at a certain point, can't that sort of break down into lack of meaning almost if we're, if we're all using different words for the same thing.
Jason Bernert (22:57):
Yeah. So I think that's why like documentation is so important in like any system you use, right? Like
Keith (23:02):
I, I don't agree. I mean I, I think
Sara (23:04):
He's the dungeon side. I'm the
Jason Bernert (23:07):
Document. Oh man, I'm pro, I'm
Keith (23:08):
Pro documentation. I'm kidding. I'm like,
Sara (23:10):
Has this guy never opened Jira
Keith (23:13):
<laugh>? I've never opened Jira. I don't even know what that is. Oh man.
Sara (23:17):
Then you could see in the product request we need a new alert button and then tag it or write in the notes using warning red and then somewhere you could click on that and see what warning red is cuz someone's notated that.
Keith (23:32):
Oh, all right. So yeah, explain that to me. I mean it
Sara (23:35):
Documentation, so internal and external documentation it sounds like. And so when we talked about earlier about style guide Yeah. Logo should always be a hundred pickles from the top and 120 pixels from the right. That's the very basis of documentation for style. But with Jason's work,
Jason Bernert (23:50):
Yeah, it's like pretty much the exact same thing, but just kind of elevated, right? So the example of this logo needs to be in the upper right, it needs to be this color. It's the same thing, right? Where like, this is the hex code we use, this is like what we call it and this is how it's used. You know, so that's like written down in documentation. So you can like go to a web internal webpage of the Washington Post and learn what those things mean. Right? so that way it's also helpful if maybe you don't remember exactly like what is the warning color again? You can go and and look it up. Yeah. But also
Sara (24:16):
If you're it when you're making a new feature proposal mm-hmm. <affirmative>,
Jason Bernert (24:19):
Right? And if you're new, right? You're a new developer or designer at any company, you can then read the documentation and kinda understand the system there. Hopefully like the meaning behind the words kind of becomes more and more abstract and more and more descriptive, right? Because to describe something really, really specifically, you often have to use like a lot of words, right? Sure. Like it's the circular gray UI element underneath the headline and it has that plus icon on it. And when you click on it, you can like add it to your reading list mm-hmm. <affirmative> and like that's very descriptive, but it's also very long and hard to say. And so that's why I think the evolution of any language, we invent more words mm-hmm. <affirmative> so that way we can use one word instead of like, you know, multiple sentences. And so there's definitely like the pros of being able to say like, Oh, it's the article action bar and you move on.
(25:08):
But there's also the cons of like, you need to know what that is first. Right? And so that's why I think the how language kind of builds on itself. Like if you're a kid and you're learning how to like read for the first time you learn some words and you learn some more words and then you learn the really big words and how those big words can interplay sentences and how sentences can be constructed. and I feel the same ways as when you're in like any kind of design system or language, it's like you, oh I kind of, okay now we have these colors and now we have these names for these colors and then I know how those colors are used. And so if you design a system that hopefully is kind of has inherent like under like inherent qualities to names you can understand like kind of going back to that red 100 blue 100 mm-hmm. <affirmative>. Like if you see 100 at both of them, you're like, oh, this might be linked. If there's like also red 200, red 300, 400, you know, blue, 100, blue 200 blue 300, blue 400, our minds are already really good at seeing similar similarities, you know, and kind of like associate 'em is the same when they are are related. So kinda like leaning into those core semantic principles helps us like make names that actually has meaning to it. Mm-hmm.
Sara (26:08):
<affirmative>. And would you say that some majority of the names that you're creating are, it's telling a new person the purpose of that thing within the name,
Jason Bernert (26:19):
Right? Right.
Sara (26:20):
Is that, like, is that a common thing in design systems that the name should hint at the purpose?
Jason Bernert (26:28):
Yeah, you should. So when we try to name things in a design system, it's a good idea to kind of lean on existing like frameworks, right? a common UI element in web development is like the accordion. Mm-hmm. I dunno if you're familiar with this idea.
Sara (26:41):
I'm a weird out fan.
Jason Bernert (26:42):
Yeah. So like we know the know the instrument recording how it expands and contracts. there's also like dropdowns that can expand and ex you know, expand and contract and so they call like an accordion. So you kind of can lean on language that way. But also accordion has its own meaning inside of like web development. So if you ask a web developer what an accordion is, they're probably gonna know what it is. If you have ask like a UI designer when an accordion is, they're gonna know what it is. Yes. So with the post makes a new component that looks and walks and talks like an accordion, we're gonna call it an accordion. Does
Sara (27:10):
That make sense? Right. So you're not always making a novel, you're kind of walking the line between established I understanding of digital design and novel elements. Mm-hmm. <affirmative> without being like, well at the Washington Post, we don't call it an accordion, we call it a widgety
Jason Bernert (27:23):
Woo. Right. Which is just like inherently complicated. Like for instance, when we were gonna quote unquote name the Washington Post design system because we wanted to like give it a name, a lot of people were like, Oh, at, I'm trying to think of the crazy examples. Oh, at ibm we call it carbon, but they're like, a lot of people moved away from these cutesy names. Cuz if you go to IBM like, oh we're using carbon, a new employee. Like wait, what are you, what are you telling the carbon? Yeah. And so when we named the Washington Post design system, guess what we called it?
Keith (27:47):
The Washington Post Design
Jason Bernert (27:48):
System. And why do we call it that?
Keith (27:50):
Because it makes
Jason Bernert (27:51):
Sense. Exactly. Yeah. And so when we name components and things, we name them so they make sense.
Sara (27:56):
Ah.
Keith (27:57):
So the same thing is true in medicine. So like traditionally in medicine, you know, whoever discovered the thing in the body would just name it after themselves, you
Sara (28:06):
Know? Mm-hmm. <affirmative>, like I call this organ the Keith
Keith (28:09):
<laugh>. Yeah. Kind of. I mean a lot of, a lot of times it's much more specific than that than an organ. You know, it's like a specific duct or a junction or something like that, or area of the brain. We've got a bunch of areas of the brain still that are named, you know, the weres and bros and like those are the named after the, you know, white dudes that discovered them. But it doesn't make any sense. So like there's, there's this big push sort of in the, you know, anatomy slash medical world to change names to things that actually make sense. The trouble that they run into though is that you've got doctors who have been trained 30 years ago who have no idea what the hell you're talking about when you say, you know, the like the new name of something and
Sara (28:51):
Then in the middle of brain surgery the patient flatlines cuz they didn't know where the word was
Keith (28:57):
<laugh>. Yeah.
Jason Bernert (28:58):
Well but that's the tricky thing is like when a word already has a lot of meaning, subscribe to it, it's hard to rename that word. Yeah. And so that's why when we would ever name something the design system, like the first thing you choose has to be really well thought out. So we would spend sometimes a week or two weeks while working outta the work thinking about what that name should be. Cause the moment you say this is the article actions component, you're never gonna be able to rename it. Like if someone wants to rename part of the brain like good luck, you know what I mean? Cause it's like really hard cuz they already have so much meaning to it. Mm-hmm. And so you can start to be like, oh yeah, it's also, or it's also called this mm-hmm. <affirmative> or you could start teaching, you know, med school students like, oh it also means this. Yeah. But then you have two meanings for one thing
Keith (29:39):
And then your brain is better or worse. Right. Well and that's kind of what I was trying to get at with my earlier questions. So if we have these three different levels of names or that all mean the same thing, at what point does that actually become less useful? Because we all have to refer to a style guide instead of all using like a common sort of nomenclature that we can sort of agree on when we're talking. So that, I mean I get that like if you have a written request for something, it could just link to the style guide or whatever. But even that, I mean, although that's very easy to read, even that requires someone to write the software to have, you know, the style guide and put the link in and like all that stuff just takes more time. Whereas if we just have one name that we all use for the thing, isn't there something that we like isn't, isn't that easier to communicate?
Jason Bernert (30:32):
Yeah, I think, I mean if I can get really high, If we can get really high
Keith (30:35):
Level here. Yeah. Yeah.
Jason Bernert (30:36):
I think whenever you're communicating any concept it like what's it called? What does it do and how does it relate to other things? Cuz that gives our brain an internal model of how to understand larger systems. Cuz if we have a name for it, we can quickly go into our little internal catalog of our brain and identify that thing. What does it do allows us to know like the part of the brain, like how does that interact with our other parts of the brain? What parts of the, is it sit next to? how does it interact with those parts of the brain? What is it supposed to do? What is it computing? Those kind of things. And then how does it relate to other things? You know, like Yeah, exactly. Where is it sitting and like how does it work with other pieces of the brain?
(31:13):
So for us, like having three names for a single color is to solve those things. Like warning red gives it like the meaning of what this red is red 800 or red 80 gives it the relation to all the other colors. So you know how red 80 interacts with blue 80, yellow 80, those kind of things. Mm-hmm. <affirmative> and then the hex code is like, well what is it actually doing on the computer level? Mm-hmm. <affirmative>, you know, so it cuz when you have just a hex code, you're like, well how does this hex code interact with the rest of our palette? Mm-hmm. <affirmative>. And it's hard to know that unless there's a defined system. So that's why the red 80 comes into play. Right. So, and the red warning is like, well what is red 80 mean? What do we use it for? Oh, it's for warning. So like we have multiple words for things that helps communicate those ideas. Sure,
Keith (31:59):
Yeah. That makes sense. And so really it's, it's, you're not thinking of it as three different names, you're just, it's it's one long name. It's like a first middle and last name. Yeah, exactly. For one color red.
Jason Bernert (32:09):
Yeah, yeah, yeah. You can figure out where like my last name, like where they hail from, you know what I mean? Right. But you can know who they are by their first name and things
Keith (32:15):
Like that. Yeah. Which makes sense too because I'm, you know, now, like thinking as a programmer, if I'm trying to program you know, oh I have to put in this popup for, you know, like someone's gonna leave the Washington Post page or whatever. What color should I make the button? And then you think, well maybe it should be warning Red. That would make sense. And then even without a project designer involved or whatever, you could prototype something at least, least that makes some, some amount of sense with this style gut rather than making it, you know, blue or
Jason Bernert (32:43):
Something. Yeah, yeah. Exactly. And that's the whole concept, right? If you have a design system that has like, clearly defined kind of foundations and rules and names, then you can start kind of acting independently. So it's that kind of reverse idea of creativity. Earlier we talked about like, well what if like a design system tells me what to do, then that kind of sucks. Cause I'm a creative person and I wanna like build cool and fun things. But if there's a system that you can lean on and like, Oh, I have to build this thing and it's due by tomorrow and I need to like warn someone cuz of the popup, you know, is telling them they, they should, you know, try to subscribe again before they leave, then you already kind of have that inherent meaning to help make that decision and work independently and hopefully enable your creativity instead of hind
Sara (33:19):
It. Yeah. It seems like it gives you flexibility because then what if someone comes in and says, well colorblind people can't see warning red, Warning red exists beyond its hex code warning. Red is a function that you can easily change the hex code of if new information is introduced into the system.
Jason Bernert (33:35):
Yeah. Cuz think about like, well we want to change our warning color from red to yellow and we use that warning color in thousands of places throughout hundreds of components, across dozens of different platforms and devices. So if you have a system of like, this means warning, it's assigned to this color, it's a sign to this he code. If you wanna update that hex code, you don't need to rename, you know, red 80 you I name warning. But if you want to change warning to yellow, you can like change that definition. So it allows you to kinda like work within that system and change it across a lot of products and kind of scale.
Keith (34:09):
So in that federated system that you were talking about earlier, if someone comes in and they're designing I don't know what, what might someone design a new button? A new Yeah, sure. Yeah. Someone's designing a new button and they use the style guide. They sort of have a jumping off point from the style guide that they use, but then they sort of get creative as you say, and deviate from the style guide. And then they've created something that they think is awesome, but it doesn't fit the style guide precisely. What's the, and and let's say you come to them and you say, well, so we do have this sort of standard in the style guide for this piece of the button. Like we don't use an exclamation point and you used an exclamation point mm-hmm. <affirmative>, something like that mm-hmm. <affirmative>, you know, and the person says, Well I feel like this exclamation point is really essential for this button. You know, and I feel very, I feel very strongly about the outcome that I've, that I've produced here. What is the sort of resolution process for that? Like what, how does, how does that move forward from there?
Jason Bernert (35:10):
Yeah. So I think this is a real issue. Is there a problem? This happens all the time. Yeah. Not a problem. It's a real like workflow based like way of life, right? Because people when they design things like they want to evolve the design, they wanna evolve the system that will evolve the product mm-hmm. <affirmative>. And if you have like a system that can never change, then you'll never evolve. So if someone's like, I want to add an exclamation mark here, we kind of have this rule that like a lot of designs should be like 80% kind of driven by the system. So, you know, you're like using the right colors and the right spacing and generally the right language. But you have this 20% of like, this is where I can iterate, this is where I can be creative. This is if I wanna add an exclamation to mark this button, I know I can do that.
(35:48):
And so the process would be you can like add it and hopefully the system is flexible enough, not rigid, but flexible enough to like do a one off of like having that explanation point at the end of a button. And then if you want to like make that part of the system because maybe you do testing on it and that clickthrough rate goes up really, really high because people are like, Oh, an exclamation mark, I'm definitely gonna click on this button. Yeah. Like, that's a good iteration. That's a good experiment. That was very successful. And if you want to make a successful iteration of that, again, you wanna be able to create it. So bring that back into the system mm-hmm. <affirmative>. And so that's when we kind of talk about like proposing new ideas or adding things to the system. Right? And so if you had a successful experiment from that 20% iteration you did on your new button and it worked really, really well, then let's propose that and bring it back to the system and find a way to make that systematic.
(36:33):
So maybe on the button there's like a little option that's like add exclamation mark, right? Mm-hmm. <affirmative>, or maybe you change the documentation that says like, when we write doc, when we write call to action text on our buttons, we like to end them with exclamation marks. Right. because we notice in this past experiment the results were this and it worked out really well. So that way hopefully you're iterating not only on individual design through an individual button, but also iterate on the system as a whole. So then the federated approach, you as an innovative designer, maybe you'll go and like do the exclamation point, you see it worked well and you say like, Hey guys, check out how well this worked out. Yeah. And then the team is then like, Okay, then we'll figure out how to make a part of the system.
Sara (37:08):
And then imagine there's someone within that team who's like, I agree with the exclamation marks, but let's not use it when it's the button add obituary. Yeah. <laugh>.
Jason Bernert (37:18):
Exactly. Yeah. Because if you're trying to get someone to subscribe to something, maybe it's worth it, but it's also not a good idea depending on context. And so they kind
Sara (37:26):
And your subscription,
Jason Bernert (37:27):
Right? Yeah. Yeah. Woo. And so I think there is that aspect of the bigger picture, right? And so one off ideas are great cuz you can kind of test little ideas to see if they work or don't work, but bringing it back into larger system does take thought and you have to think about like, Oh, how is it gonna be applied? Where is it gonna go? What meeting is gonna change? And those kind of things. And so that's where like the two week kind of like, Oh, let's just like, you know, stroke our chins and think about how is this gonna change the whole system, you know? Mm-hmm. <affirmative> that's where that comes into play. So Yeah, absolutely Sarah, it is definitely like, not just like, let's just apply and be done. Like there is the, you know, the consideration, the proposal,
Sara (38:02):
I've already seen the style guide of buttons branching, and it's like, well, it's sections A and two, you can use an exclamation mark, but over here, you know, actually warning red is yellow because we don't want people to be ma like,
Jason Bernert (38:13):
Depending
Sara (38:14):
On behavior and the desired outcome and the, like head space or, or even what the article is about.
Jason Bernert (38:20):
Yeah. And so that's the thing, when you branch too far, you no longer have a system, right? Because you just have a bunch of people working in silos. And so the idea is bring those things together and have them pretty well, like defined foundations. Some people can build off of them, they can still explore, be creative because that's important for evolving products involving, you know, evolving companies. But to kind of cut out the the overhead thinking of like, well, what is a button? What is like how round should I make this button? Like, that's not a problem a designer should solve. They just copy and paste button and move on with their day Right. And figure out what the button says. Actually, I should put it or not, because that's what makes a difference. Sure. but you know, if it's totally lawless, then you're just kind of like yeah. Trying to figure out like what color it exactly should be and you're thinking about different heads code and what it should be and all these kind of design choices. And so it's a, it's a fine line between having some kind of system at, at play in the center to help make sure things feel consistent and they're easy to use and build, but don't create like a stagnant like rigid system that no one can kind of evolve and be creative
Keith (39:21):
In. Right. So, so like any language it evolves, but unlike language, it evolves in a thoughtful way. So there's a process for evolution, right? Hmm.
Jason Bernert (39:31):
what do you mean by that? Like evolves in a thoughtful way?
Keith (39:34):
Well, so what you're talking about, So if I wanted to add my exclamation point to that button, you're not just, just gonna say, Yeah. Great. Okay. Add the exclamation point.
Jason Bernert (39:43):
Mm-hmm.
Keith (39:44):
<affirmative>, right. You win, you know? Yeah. Right, right. You're, you're actually gonna look into it, you're gonna, Oh, yeah. So we'll prototype that button. Yeah. Yeah. We'll prototype it with the exclamation point. We'll see how it goes. If it goes good, great. We'll add it and maybe we'll add it to the style guide. We'll add it to add it to other buttons that could use exclamation point. But if it doesn't go well, then yeah. We'll just get rid of the exclamation from Mark. And, you know, you were just wrong about that.
Jason Bernert (40:05):
Yeah. And I think I like what you said about like how language naturally evolves and changes meaning to, because like, if someone uses a new word, a new slang or something like that, eat
Keith (40:13):
Here <laugh>. Right? What does
Jason Bernert (40:15):
Ye what is ye
Keith (40:16):
Yeah. I mean, if it were, if it were language, that person would just add the exclamation point because they wanted to.
Jason Bernert (40:21):
Yeah. And then I would see it and be like, Hey, it's a great idea, I'm gonna copy you. Yeah.
Keith (40:24):
Right. And you would mm-hmm. <affirmative> and there would be some guy over here who's pissed because you put an exclamation point on there, but he can't do anything about it because it's language. Mm-hmm. <affirmative>, Right. I'm, the, the word myriad comes to mind. I don't know, do you remember, This was a big debate. I remember when I was in college and I had a lit major roommate who would go on and on about the word myriad. Are you familiar at all with a great myriad
Jason Bernert (40:47):
Debate? No, I am not
Keith (40:49):
So myriad. The original meaning of Myriad was like an uncountable number, Right? So if I looked up at the stars in the sky and I said, There are myriad stars in the sky, that would be the appropriate use of the word myriad. but people started using it as to they, people would say there's a myriad of stars in the sky. And I, I forget that the, the you know, the what, what is an adjective or whatever. And that's probably why people started using it poorly is because they didn't understand the, like, you know, form of the word or whatever. but there were, you know, English nerds who got really upset about that for a very long time and would correct people when they said would say, There's a myriad of stars in this guy. They say, Nope, there are myriad stars in this guy. Mm. And like I say, I had an English major roommate and he would get pissed about this. And over in the course of being in college Miriam Webster added the, the other form of myriad to the dictionary. Oh. Because it had been used so many times because it just be, become the assumed meaning of the word Yeah. That people would say a myriad of stars rather than myriad of stars. So they said, Well, it can be either of these forms of, of word.
Sara (42:07):
How did your roommate take that?
Keith (42:09):
You know,
Sara (42:10):
There were a myriad of reactions,
Keith (42:12):
<laugh>. Yeah. There were <laugh> there were there were myriad reactions. Yes. That's correct.
Sara (42:17):
Yes. The dictionary had to do a similar thing with the words literally and figuratively. Yeah. Because around the eighties to nineties, the meaning, or I guess it might have been the, the meaning swapped,
Keith (42:25):
Right? Yeah. So yeah.
Jason Bernert (42:28):
Skunked term. Yeah,
(42:29):
Skunked term. That's the term for that is like, when a term is normally used for one thing, and then over time people misuse it mm-hmm. <affirmative> to mean the other thing. Mm-hmm. <affirmative> that the, the definition changes. So, for instance, I love, what I love is pull yourself up by your bootstraps back in the day that used to mean something, it's impossible to do. Right? Cause you think about it like you're wearing your boots. You cannot lift yourself up by going down and picking up your bootstraps and picking your own self up. So it's an impossible task. Like, Oh, good luck with that. You're really picking yourself up with your bootstraps there. Like, you're not gonna be able to do that. But now it's like, oh wow, they really picked themselves up from their bootstraps and they made it work. They made it happen. You know? So it's kind of like how people use words also change over time. So that's an interesting syntax thing, Right. And semantics thing is like, well, if words do change, and like for instance, in my job, like if the web ui, we don't call an accordion and accordion anymore, cause a better word comes along, then you have to adapt and kind of maybe change the name of things, right?
Keith (43:18):
Yeah.
Sara (43:18):
Yeah. Yeah. And, and you know, we were even seeing this like the slave and master debate within programming.
Jason Bernert (43:22):
Yeah. Don't do it. There's not a debate, there's no debate. Just don't do it. It's no longer
Sara (43:26):
A master bedroom. But that's, Yeah. It's a good, it's a good change. It's interesting to see like our biases within language and within our systems and change them when it can be improved to make more sense. Like, this is not a slave.
Jason Bernert (43:38):
Yeah. And also they can have more meaning like, we use Maine and develop because the main branch is the main branch of work. Like, it's hard to use another word for it. And develop is the one that we're actively developing. Makes sense. So those words not only are more appropriate, but they also are more descriptive, you know? And like, we used to use terrible work. Like,
Keith (43:58):
Did you used to use Master Enslave for those
Jason Bernert (43:59):
Two terms? Everybody did, like, yeah, everyone We did. Yeah. Yeah. So it wasn't until, Sorry,
Keith (44:03):
I'm not a
Jason Bernert (44:03):
Yeah, yeah. It was a big move from Twitter like three years ago after the George Floyd like event, they said like, We're gonna change this. And then they, people who never thought about it before, like, Oh yeah, these words are loaded because we never thought about it, were challenged and never questioned it.
Sara (44:15):
And the real estate community was rocked fake. But now you'll hear not master suite, this is the owner's suite. This is the main bedroom.
Keith (44:24):
Wow. Owner's suite. I don't know. I dunno that changing it from master to owner is really that much better. Especially if you remember that it used to be called the master suite
Jason Bernert (44:32):
<laugh>. But one thing. Yeah. The one thing that you used to say was like, Oh, it's a black list or white list. Yeah. But now it's like a blocked list and an allow list. I got you. Because a allow list also means like, Oh yeah, these are the things you allow. Sure. Whereas whitelist is inherently racist. Yeah.
Sara (44:46):
Right. Racist.
Jason Bernert (44:47):
Yeah. So it's one of those things where I think naming conventions, yeah, they can mean a lot of things. And also, like, you should also question like what those words mean and how you're using them. One thing we also introduce, and speaking of these words we use oh my gosh, where are already blanking on the name. It for a lot of our projects we use an innclusive linter, which means like, it's spell check for inclusivity. So if you want to call something like a dummy component and be like, try to think of a better word besides dummy, because that is kind of like hurtful and offensive. If someone wants to use a component that's called dummy, like how does that make them feel? Right? So like maybe something more descriptive could be nice. so, so
Keith (45:24):
Wait, so you actually have like a, like a, a program that checks your words for that? Or like, you do that with each other's work?
Jason Bernert (45:31):
We have a program. So if I'm typing code and I use like, Oh, this is the white list, it'll be like, no, no, no. Change this word to allow list.
Sara (45:39):
Yeah. Do you allow guys?
Jason Bernert (45:42):
No. Yeah. So yeah, guys isn't either.
Sara (45:44):
I feel as a Western West Coast person, I do not like that move because guys is the West coast version of y'all.
Jason Bernert (45:51):
Yeah,
Sara (45:51):
Yeah, yeah. We have no other option. So when that, that was a big wave where Slack started saying, you cannot use this word. Come on guys.
Jason Bernert (46:00):
<laugh>. Yeah. I think also it's, it's hard because English language doesn't have a good like, collective pronoun, you know, for a group of people. When you walk into a group of a party, you're like, Hey everybody, hey you all like, we just, we never really got that morning
Sara (46:14):
And everyone
Keith (46:14):
Yeah. I've just been trying to embrace y'all.
Jason Bernert (46:17):
I, since I'm to the East coast, I say y'all and I come back to the West Coast and I feel bad about using y'all cuz they're probably like east coast, east coast chain. Who do you think you are coming in here appropriating the word y'all.
Keith (46:33):
That was our conversation with Jason Burner, a fantastic fellow. Thanks so much for joining us this week. for posterity's sake, I wanted to let everyone know that the original form for Myriad, as I understand it was an adjective, in fact meaning a countless or extremely great in number. the example of sentence and that Miriam Webster gives us is the myriad lights of the city as opposed to the noun that it became also meaning a countless or extremely great number. However in the noun form you would use in a sentence as networks connecting a myriad of computers. So there we go for posterity's sake. and so that my old roommate doesn't tear out his hair, if he listens to this episode that is the original and transformed meaning of Myriad. Be sure to get back with us here in a couple weeks.
(47:33):
We will be coming out with part two of this conversation where we will dive into the worlds of Dungeons and Dragons. We'll talk about names and categorizations in the worlds of Dungeons and Dragons how they help us, how they hurt us, how they can expand or contract a horizons. And then we'll talk a little bit more about building a style guide for your campaign in that episode as well. And hopefully have something to put up on the website for you in that regard. So check back with us in a couple weeks. thanks for listening. Dungeons and Documentation is a production of Keith and Sarah's free time. This episode's executive producer was Oslo Cobble Pot. Theme music is by Ian. Post underwriting is provided by Shepherd Creative Enterprises. You can find us online@dungeondocs.com or dungeons and documentations.com. This episode brought to you in part by DM Tools, DM Tools, Needle, Local Watering Hole. You can generate one dm-tools.fision.app. That's dm-tools.fi.app.
Sara (48:40):
This episode of Dungeons and Documentation is brought to you by completely arbitrary. Do you like trees? Listen to their show. But only after you listen to our show, they have enough listeners.
Keith (48:52):
This episode brought to in part by the English language, the English language, it's universal. As long as you speak really loudly and slowly, the English language, don't leave home without it.
Sara (49:03):
And I will never <laugh> ever make a website where the button says, Yes please. Because I look at that and I just wanna throw up over your head. <laugh>, I don't even care if I want to go to your event. If the button that I have to click on to purchase a ticket does not say purchase ticket. It says, Yes, please. I will not go. Wow. Because that is dumb. I want the button to tell me what I'm doing. I don't want the button to put words into my mouth. Like, What if, Instead of Register Now, the button said, Pledge your allegiance to my podcast.
