170  |  Formalizing Design with Gabrielle Mérite and Alan Wilson

Especially when we make guidelines that are going to be used potentially by hundreds of people, we have such a responsibility to do them properly.

Hi everyone, welcome to a new episode of Data Stories. My name is Moritz Stefano and I'm an independent designer of data visualizations. In fact, I work as a self-employed truth and beauty operator out of my office here in the countryside in the north of Germany. And usually I record this podcast together with Enrico Bertini, who is a professor at Northeastern University in Boston. But today I'm solo. But luckily I'm joined by two guests today, which you will hear about in a minute.

Hi, Moritz.

Hello. Thanks for joining me. Quick introduction. So Gabrielle, can you tell us a bit about yourself?

Yeah. Hi, I'm Gabrielle Merite. I'm French. I'm an independent information designer. So I help ethically driven organization uncover important truth and share stories with intention backed by data. And I'm also currently, for another month, the senior DeDeviz designer at Pentagram in the team of Georgia Alubi.

Which we also had on the show a few times and who's of course well known. And yeah, it's exciting to see you two work together.

Yeah, the incredible Georgia.

Ellen, how about you?

Yeah, I'm Alan Wilson. I'm a principal designer at Adobe. Where I work primarily on the experience cloud, which is Adobe's enterprise business. We make marketing software and other tools to help large organizations keep their messaging and help their customers. And I guess the main thing that we'll be discussing today is my contributions to the design system at Adobe, which is called Spectrum. Right.

Yes. And this is also how we got in touch around two years ago because I started working together with Core, an agency in the UK on a design system for the World Health Organization. And yeah, and we sort of uncovered this whole world of wow, there's so much happening in this space. And it's also really hard to orient yourself. Like it sounds so easy if somebody says, oh, we need some database style guide or guidelines. Can you help us do that? You know, everybody's like, yeah, sure,

I guess I'll go first. I think the main value is answering questions, right? As organizations grow, you have to coordinate a lot more to make sure that you as a group have a coordinated voice. Space. Questions are very common, right? What font should I use? What are our standard colors? How do we lay out this particular document type? People need standards to communicate in a unified way.

Mm-hmm.

I love that answer.

Yeah, that seems pretty comprehensive already.

Yeah, I had a way more like strict like dot list. Yeah. But I love that answer of answering question because I think it answers a lot on the definition. I see, on mine, I kind of see like four kind of point of values. Efficiency, just the idea of answering questions faster. So just people being able to reuse design to know what to do. All these things come into efficiency. Consistency, which I think is the one that people don't always see.

Yeah. Yeah. And in the like more branding and PR and advertising world, brand guidelines are super common, right? And often we just receive them as, oh, here are our brand guidelines. Can you make sure the charts, you know, fit into that? Right. And so, yeah, that's already where we touch these wider like communication contexts. But in this world, it's very common to have like a big book with the fonts we use, these are the colors we have. This is how we pick photos.

I think one of the reasons data is emerging more and more in the style guide space is because people are using it more and they have more questions about it. So we're traditionally style guides focused on how you use the logo and how you use photography and other visuals to communicate. People are using charts to communicate and they have questions about how to best do that.

Yeah. Yeah. Yeah. So it's a natural evolution of us actually mattering, which is good.

Yeah, precisely. And there's this idea of like, you know, authority. I think in the world where trust is hard to gain, for organizations that have gained that trust or are trying to gain that trust, having that recognizability of like, oh, this specific data visualization is coming from this institution that I'm familiar with. And I can recognize that a very first look seems really important. In the public discourse.

Yeah. Cool. So I think we have the motivation is clear. So you want consistency, you want a scale design, you want to make sure all outputs coming from one source have a minimum level of quality, they're recognizable, they look from the same family at least. And not have to be a mysterious process process that some gifted rock star designers can only do, but sort of scale the capability to anybody.

Yeah, Spectrum is a design system and I would put it further down, maybe even at the very bottom.

At the bottom. I'm also in the bottom.

Yeah. When I think design system, I think the difference between a design system and a style guide or a theme or just a set of guidelines is a design system has infrastructure behind it So that when you make a change those changes roll out into all the places that they need to maybe there's also software components that exactly implement that stuff and Yeah, yeah And it provides resources for all parties that are involved.

And so, okay, cool. So we have design themes, automated in the design system, and super well documented. So then how about guidelines and style guides?

How does that fit in? I don't know how Alan feels about it to me. So I work hard on that one. I was like, is there a difference between guidelines and style guides? And I think we use it pretty freely in the design world. It kind of, we use it, at least in the, you know, bright side of things, we use it kind of like whatever, we can exchange them.

And that part cannot be automated or implemented well in software, right? Like, how do you automate tonality? Can you? I don't know. But at least, let's say, a style guide or design guidelines are usually targeted at people making charts. Right? Is that fair to say?

I mean, I think all of these are targeted at people making charts. But to Gabriel's point, some focus more on the aesthetic part of the problems and the aesthetic questions. And others focus on the technical questions and implementations and things and systemize things a bit more.

More. Yeah, so you can see already, it's this muddy mess of people, machines, data, audiences. It's an exciting space. And then really think about, okay, how can we abstract principles there and re-covering rules and not just solve problems once, but more or less for once and all, which is of course the hard part.

It's funny because it reminds me of what Alan was saying about the design system. So at least just like Alain had placed it at the end, to me it's what encompasses everything, including Style Guide, but also design theme, design language, like the actual components and little design elements, like templates that you may have created. And I would call it a repository of institutional knowledge that solves problems,

Yeah, right.

Yeah. I think another thing worth calling out is that sometimes data visualization is its own thing. There is a datavis style guide, and it lives up separate from the brand guide and the user interface guidelines and other resources. But more and more, we're seeing all three of those things. And other things as well come to, content guidelines in important ways that we need to account for.

Yeah. Yeah. Yeah, so there's a lot of overlaps with adjacent, maybe other design systems, like the branding or the UI design, and we need to see how we fit in with all of that. I guess what's unique to data visualization is often the extra design vocabulary you need, like specific color scales that work, have certain functional properties or or chart types and all the things we're all familiar with, legends and axes and whatnot.

Yeah, one of the challenges with writing guidelines for data is that differs from brand guidelines and others is some of the other areas are just self-evident and really easy to explain the guidelines for. And data visualization has its own language and its own set of things. I mean, it intersects with data literacy and some specific domain expertise that you might need to be effective. And often I find myself in writing the guidelines, I'm like, man, I need them also to read these books.

Yeah, same problem here.

Yeah, and maybe that's the first real learning I think we all share probably is like, you really need to define really well what the purpose of the whole thing is and what your audience is. Like, is it skilled information designers that use it or should it be implemented in an automated system or should it be for total novices, like a foolproof system, because that will shape everything in terms of what do we even supply people with and in which form, right?

Sure, sure. So Adobe Spectrum is our design system. If you want to take a look at it, you can find it at spectrum.adobe.com. And, Yeah, the first thing I want to point out is that it's a whole team. There's a lot of people involved. And so I am a small piece of that whole ecosystem that builds and maintains that. And the design system was about two years old before we introduced the data viz guidelines.

Right.

So it is used for our, you know, dot com website and some other things, but the primary focus is for how do we build, you know, really good software using that system.

Cool. Gabrielle, how about you?

So I worked on quite a couple and I can't talk about everything. So I'll talk about the one I'm publicly allowed to. I think the one that's the most public that you can see on the pentagram website is the Deloitte insight. It's a guideline and templates, so it's not full design systems. And so, DeLaw Insight is a magazine. It also has a web platform attached to it.

So it had to be pretty... It's really hard mode. It's like all the hard parameters are switched on, right?

Yeah, it had to be pretty strict. And also, we were working for both web and print.

Of course.

Why not? So just to add a little bit to that.

So yeah, and a bit of spice, you know.

And the law inside covers any themes, so it can be any type of data, whether it's about people, but you know, economic, like anything, everything, throw it in together in one package. So that was probably one that I can talk quite a bit on. And the other one is for a nonprofit organization that I cannot name. They work in the gender equality space. And this one was tricky because we had to do it and they hadn't produced any work yet.

Yeah, so you can see already it's quite different requirements and you need to be smart about what you do, right? And how that will play out. So maybe talking about process, then how do you... Address this? Like, do you first build a lot of chart examples, like in your design team, and then say like, okay, what are the recurring patterns?

Okay, I'll start. It might be very different because we so we even me as an independent or within Pentagram, we are external contractors. So we don't have access to everything internally in the organization that might be quite different than the way Alan works typically. So the way I like to work is I start with what I call analysis phase, which is just looking at obviously who the organization is.

So the idea is to... First the diagnosis, then the prescription, right?

Yeah, a little bit. But just identifying existing useful patterns, things that have worked too and things that are not working in the current applications, and who is working with it. It's way harder when we have a project, like I was talking earlier, where we don't have access to those existing applications, because there's none. But there's always a base somewhere of what data are they going to use? Where is it going to be published?

It's a double hop.

Yeah, there's a double hop here of like, OK, typically, if you work for a nonprofit, the final product is going to be a public, a very uninformed public, or on a sensitive topic. So what are the constraints already that I impose on the project? So there's all this analysis phase.

Like an actual design idea in a sense that there is, there's like a design approach to it.

Is there a metaphor that we can use throughout? Is there something that makes it stand out that's just not a design decision, but that makes it unique? And so that is a little more, on the creative side, that's less common. And then it's even harder to explain in Style Guides. But it's part of that thinking. And then usually you test that on basic chart and then you test that on editorialized charts because all client usually needs editorial charts and not the most basic.

Yeah, but there's an interesting tension because of course you and Georgia of course are typically known and booked for a super creative, unique, one of a kind work, right? And now the expectation is you do that, but also make it repeatable. Right?

And so I think there's an interesting tension there.

Yeah.

It's definitely a challenge. It's actually quite interesting because we end up creating, to me, it's almost like I split the guidelines into traditional charts with the most traditional bar charts, bar charts, whatever you need to have that needs to be made in PowerPoint, like we've got custom design, especially if we have users that are not designers. So PowerPoint, Canvas, RowGraph, the easy building building blocks that can

Cool. Yeah, that makes a lot of sense. And yeah, it's super interesting. Ellen, I could imagine your process is totally different because you don't work in an agency, but it's more this ongoing big ship instead of the little dinghy with the little party on it.

Yeah, yeah. Earlier in my career, I worked for agency. And we did a lot of brand guides and things of that nature, which certainly informed a lot of the work that I do now, but yeah, it is different. And I do think there's no one process for this stuff. It really is, part of the problem here is figuring out what an organization needs and how you can best deliver that. But for us, and one of the advantages of being an internal team is we can deliver

Retrofit, basically. What would have been the rules that would have made these choice that obviously seem to work.

Exactly. I feel like that's a good approach. But at some point you have enough guidelines that you don't have to start with the end and you can just take what's existing and expand it a little and then see what comes out of it. Yeah.

That's something we also struggled with a lot is you want to get started somewhere and build stuff and see stuff. Otherwise, how could you even progress in the project? project, right? You need something visual to work with and to debate. At the same time, you feel like it's such a big system. And if we just keep making graphics, you know, it's never be a proper system system, right?

That's the benefits of design systems. Because I think instead of the GAN line constrained versus as a design system and tokens and components and patterns help you be more flexible. In my opinion, it's like, it's more, we're giving you the blocks and then you can make it yourself. And here are just a couple of rules about big mistakes you could make. And you know, at Pentagram we do a lot of just the rules only. And I think that can be constraining and not flexible for an organization.

Yeah, on the flip side, I think it allows that creative work to have greater impact. So if you have to design every chart by hand, you spend a lot of time designing the same thing again and again and again and again. But if you have a system and you're designing the system and playing with the tokens, the output scales up really quickly. I mean, it's nearly infinite, You have so many different outputs that can be automated. And so, yeah, it's that flip.

Yeah, I love that. Because I think sometimes what you hear is, well, we don't need one because we want to do creative things, but it's the opposite. If you remove the small choices of picking the right font sizes, font sizes, picking the right font away, then you can spend more time actually looking for creative solution, but you have some blocks that are predefined that makes it way faster. And repeatable, obviously.

Yeah. But it's an ongoing thing. And I think another big challenge is, I think the initial version is easy to build, right? Like how do you make it grow? How does it evolve over time? And how do you not have it end up like the German administration that has lots of really good rules that in isolation make a lot of sense, but it's a bit too many of them overall. And so how do you manage? Complexity when things grow, right? Or even out of your hands at some point.

Well, my experience is the opposite. I think the first step is the hardest. Interesting. The initial thing is so hard. Maybe it's just my nature that I want it to be whole or complete in some way. And just right from the beginning. Exactly. I have that kind of perfectionist mentality. I don't want to put something out out there until it's ready and I really am confident in it.

Well, like, Gabby and I, we are brought in as external consultants, your in-house. What do you think? What can the roles of external consultants be versus in-house folks? I've also met people who said, design system? No, we don't work with external people on our design system. That doesn't make sense, right? Because they've begun in three months, then it takes care of the actual work that happens afterwards. Or is there something we can do? I don't know. What's going to take on that?

Well, at Adobe, we treat Spectrum like a product, like any other product at Adobe. It's a thing that we build. The differences, our user base is almost entirely internal. We do have some external people, vendors and partners and so on, and so on that use Vectrum. The primary audience is internal. And so I don't know how you would have a similar model with an agency.

Yeah, that's true. Gabby, any thoughts on that?

No, you raise a good point. Because I found it frustrating as a designer who makes guidelines as a contractor, to just, we dropped it to a client and we're out of here. Like, no feedback matters. There's a scope that's defined, there's a budget that's defined. So if the scope was that we don't get feedback on it, we don't get feedback on it. Even though it works or it doesn't work, it doesn't matter almost because we get paid. Unfortunately, that's how the business works.

Well, and I think that's part of the value of a design system, is it needs to be a living thing. Because if it's static, it just doesn't continue to solve problems. You need it to evolve to solve the different problems that you encounter.

So, yeah. Yeah, and I've been thinking a lot about that too. How do we actually make sure people use the things that we design and keep using? And they say like software is either maintained or abandoned. And I feel like the same might happen with design systems. If you don't like have somebody internally always pushing for this, the system we use, it's cool. This is how you use it. Right.

It's interesting to think that... External contractors like me, for instance, are designer and use guidelines. So we are often like the consumer of the product itself. And so I guess the way I see it, I've changed quite a bit of the way Starguide in agency work is often, Starguide only is a big PDF of 60 pages. You know, PDF, all school, sometimes made for print. So vertical, right?

Also books, real books.

So it's interesting how you can just come in and be like, I know what I would like. So to your point, I think sometimes we don't have access, at least I didn't have access to the designer that would be using the book, but I was like, here's what I wish I had. So, you know, text style, paragraph style made in advance in Illustrator. Paragraph style made in advance in Figma.

Template documents, right?

Just that kind of thing. I don't want to have the copy paste, the goddamn hex code anymore. Just things like that. So I think it's interesting how, you know, But sometimes we forget also, we do things a certain way. So it's interesting how sometimes having somebody new coming in can help with that or can look at it being like, I'm not sure this is working for me. Because I also find places where they're like, well, we do use the brand guidelines. We don't really know what we need.

Yeah.

I mean, I have a very similar experience. The very first foray I had into this was like a 60 page PDF, exactly as you described. And we printed it out and it actually, everyone loved it. Cause they had, we didn't have anything like that before. And so people like engineers and designers had it at their desk and they'd have it flipped open to pages, but they would be typing in those X codes and rebuilding the buttons themselves.

Or the palettes you can download and all that stuff.

Yeah, I just want an AAC file with my call of help.

Thank you. Exactly. And so we started to create those. And so it slowly evolved from a PDF that people printed and kept on their desk to a website with downloadable resources. And I think it's really important to meet people where they are. There are times when you need to push people into new and different tools to better do their job. But for the most part, they have the tools to do their job and they just need you to provide the resources. And so if your users are in PowerPoint.

Make it easier.

Exactly, if they're in PowerPoint and that's what they're using to build their charts or Excel, you've got to provide those Excel and PowerPoint templates. It pains me sometimes to say that, but it's true. And likewise, if they're in R or Tableau, use the tools that they use, provide the resources in that tool's format that form tools language and you'll be more successful by far.

Yeah, I think that's interesting. And I think that also, if you take that super serious means, really, you can't be too picky about all this, the design details, really, like, what the spacing is exactly, or, you know, what type of tricky access configuration you have come up with, but really be more really clear about these are our underlying principles.

Or am I being too generous here? No, there's a lot of truth to that. But I feel like one of my roles as a designer is to never give up on the ideal, right? So I always- It's facing matters. It does. That rounded corner makes a difference, right? It's only a one pixel axi, but just round that corner and it just makes it sing, right? And you can get that if they're working in one tool, but in another tool, like it just doesn't support that.

Yeah, yeah. You can have one gold standard implementation also, where you say this is how it really should look like. That's how it's meant, but then maybe flexible on. In a different context, it's fine if it doesn't hit all the design details.

I also found it, it's often that, to me, the pixel close, those precise details helpful sometimes for specifically non-designers or people who are like not, I think this, because we can't teach them design, we have to give them really precise rules so that they don't have the understanding of what the right spacing in, text hierarchy. And so we see it regularly when researchers make PowerPoint, right? No offense to researchers out here.

But then I'm thinking if the exact one-to-one look really matters, then maybe it's actually better to supply a software that creates the thing as it should look, or a template, because otherwise you end up with really long, super detailed specs.

I think so, but it's hard to sell to clients sometimes. At the industry level, I think that's what I run into is often we get scoped for just the guidelines and no templates. And they may come back six months later and ask for the templates. That happens regularly. But you wish you could sell it and be like, you're going to need this. Believe me, you're going to need this.

And the guidelines. Yeah, this is where this initial scoping comes in, in terms of, okay, what do you hope to achieve? Who is this for? What are the actual things we should supply because of that, right? Yeah, interesting. And at the same time, the whole tooling landscape is shifting too, right? It's like, what do you do your charts in? There's a new answer to that every two years. And ideally, our stuff should survive a few of these iterations as well in terms of tooling.

Oh boy, I would say be humble and listen. I remember early on I had just discovered histograms and I'm like, oh histograms, okay. And I thought I understood what a histogram was. And I was writing guidelines and explaining to people and six months later I realized I was wrong about some fundamental things. And it was difficult to eat that crow and fix the wrongs that I had done. Because people trusted me, right? I taught them things and I thought I was right

So early feedback and really get people to comment on everything.

Yeah, yeah.

Yeah, I like that you said people trust me, because to my point, I think, especially at Contractor, we get a lot of trust, and they hire us as experts, right? So we tend to be trusted, and you know, whatever we say, it's going to be the Bible. And I found it problematic. Not problematic, but I found that it's a lot of responsibility that we forget, I think.

Think about more than decoration of numbers, right?

Yeah. And also have that humility, you know. I think he makes a great point. We are a little bit approaching a top-down approach, like designers say something, and we are problem solvers.

Yeah, and also the hope is with this design system, it's the Bible. It's once and for all, this is how you do it. And we all know this is not how it works. You can be brilliant at your job and do it for 30 years, and still every project is new, and there's always uncertainties and doubt. And you could always do it this way or that way, and in the end you just make an informed judgment call. but there's no absolute truth in design, right? And so, yeah.

I love that point because I think there's so many decisions that lead up to the final product of a visualization. And a visualization doesn't often acknowledge those things, right? I think that's one of the most problematic pieces of data visualization is because it's so easy to trust. That's why we see so many problems emerge around dishonest charts and things of that nature.

Yeah, I don't know how to do that in guidelines. It's definitely an education maybe, but it is about, I think we tend to focus designer, we're taught for a long time that we are like solution maker, you know, but we should focus on approaches, on like something that's flexible, agile, and that gives space to others to give the opinion and take decision, you know, give them the best tool, including an educative tool, to make those decisions rather than just get really strict guidance that might

Yeah, that's a great point. Maybe it's related to my last provocation that I want to throw in here, because maybe I'm just getting old, but I find that a lot of design is really boring these days. Like web design is super boring. Everything looks the same. There's like big round buttons. You know, I feel like there's like five templates and they are just applied all over the whole web. And I think in a way it's cool because everything's super easy to use now.

I have a thought on that. So it's an interesting question because you said, I know my way around, which I think most people do, and the idea of we've standardized web design, for instance, is pretty standardized. I think there's a question of like, it's standard that's for who? Because we're in this conversation, right? We're standards, you're centric and then Americans.

Like, why?

You know, when you look at design from East Asia, like, it might look very different. And to the eyes of American designers like me, I mean, like, it's messy. It doesn't respect text hierarchy. It's not albedica. Well, no, albedica doesn't write like in the story, guys. So it's interesting how I wonder, I'm not against it. I actually found it like, to me, automating.

But you question if it's actually true or if it's just a slice of reality or...

Is it for the right thing? When is it used? How is it used? For who is it used? Is I think those questions that, you know, are like, I find challenging. Like, I want to automate my workflow. I want to, I think it's so practical to have those technology, Figma components. Like, it's so great. I just wonder if we automate, we tend to repeat a certain point of view in design that has been put by a certain type of population. And maybe it doesn't apply to everyone, it's not fit for every audience.

Yeah, I agree with that. I think that I like that. I think my take on it is that sometimes it's an enabler. We've talked about that a little bit already. By systemizing design, it enables you to design a lot of things at once. And that's really cool. And I think that's really powerful. And typically, the thing that kind of design you're enabling is, to your point, more it's pretty expected and not terribly exciting.

If you think about AI tools, they can generate hundreds of variations of something, and then you pick and curate and combine. That's a whole new thing. Exactly.

I think the idea of curating, I'm obsessed with AI, I think it's going to change how we approach things. I think it's a tool. It's just a tool. So we need to use it as a tool and it's not a finality. It's not just you run it and then you just dump it and that's done. And if we involve human beings in it and we still have a customization of it, you know, and we we curate the result, then then that's the it seems like the right approach to do that.

Yeah. Yeah. And maybe Lego is a good metaphor in a sense that it's super standardized. Like Lego is the most standardized tool you could think of or toy you can think of, right? Actually, each block is super boring, but you can build anything out of it. It's like endless fun, right? And so maybe, yeah, thinking about more like, oh, it's building blocks. It's something you can play with and build stuff out of, you know, is a better thought than it's a book of laws. You have to abide to it. Yeah.

It might also help with gatekeeping in a way. Like, I wonder how much, when I'm seeing AI mid-journey, like how much of now people who are creative but never got the chance to be educated, have the time to learn Photoshop can produce art. There's so much, obviously it's a little further away from a discussion, but automation and all those tools that are going to make our work practical is also going to allow more people to join the community of designers.

It's a good point. So the more people we bring in, immediately we have more diversity because there's more viewpoints represented. Yeah. Oh, now I'm thinking about AI plus design systems. That's such a combination, right? If you had Infigma, like you have your little...

I've seen some.

Some people are working on some.

It's definitely coming. I'm like, I don't have to do the components by hand anymore. It'd be great.

That would be kind of nice. Just write a little text. Make all the buttons we need. And here we go. Yeah. You could also teach, as you said, a design idea or a principle or a certain approach and then just see a hundred variations of that. I think that's exciting. Cool. So I'm glad there's a positive spin to my slight doubt at the end. But I think there is an interesting tension there. And it's what I also want to keep exploring.

Or as a free way to support the show, if you can spend a couple of minutes rating us on iTunes that would be very helpful as well. And here's some information on the many ways you can get news directly from us. We are on Twitter, Facebook and Instagram, so follow us there for the latest updates. We have also a Slack channel where you can chat with us directly. And to sign up, go to our own page at datastory.es and there you'll find a button at the bottom of the page.

And there you can also subscribe to our email newsletter if you want to get news directly into your inbox and be notified whenever we publish a new episode.

That's right! And we love to get in touch with our listeners, so let us know if you want to suggest a way to improve the show or know any amazing people you want us to invite or even have any project you want us to talk about.

Yeah, absolutely. hesitate to get in touch, just send us an email at mail at data story dot es.