0:00

Especially when we make guidelines that are going to be used potentially by

0:04

hundreds of people, we have such a responsibility to do them properly.

0:28

Hi everyone, welcome to a new episode of Data Stories. My name is Moritz Stefano

0:32

and I'm an independent designer of data visualizations.

0:35

In fact, I work as a self-employed truth and beauty operator out of my office

0:39

here in the countryside in the north of Germany. And usually I record this podcast together with Enrico Bertini,

0:46

who is a professor at Northeastern University in Boston. But today I'm solo.

0:51

But luckily I'm joined by two guests today, which you will hear about in a minute.

0:56

Just in terms of introductions, on this podcast, we talk about data visualization,

1:00

data analysis, and generally the role data plays in our lives.

1:04

The topic today is data design themes, design systems, style guides,

1:08

guidelines, design languages. You can already see there's a whole cosmos of new formats emerging here in this

1:15

space that we want to explore together today. And hopefully you'll learn something new.

1:21

And it's an exciting new emerging field.

1:27

I hope we can shed a bit of light on these mysterious terms.

1:31

Before we dive right in, just a quick note, our podcast is listener supported.

1:35

We don't have any ads. So if you enjoy the show, you might consider supporting

1:40

us. You can do this with recurring payments on patreon.com slash data stories.

1:45

So then there's a little donation you do every time we publish an episode.

1:50

Or you could also send us one time donations on paypal.me slash data stories.

1:55

It's always much appreciated, also small amounts. It just keeps us going.

1:59

And we also have a bit of cost, so any contribution you can make is super appreciated.

2:05

If you don't have or don't want to do monetary support, you can also just support

2:12

us on social media or give us a good rating.

2:15

Anything helps. And if not, it's also fine. Just keep listening.

2:18

Anyways, let's get started. Let's dive right in. And now I can reveal our guests. our guests today are Gabrielle and Alain. Hi.

2:27

Hi, Moritz.

2:28

Hello. Thanks for joining me. Quick introduction. So Gabrielle,

2:33

can you tell us a bit about yourself?

2:35

Yeah. Hi, I'm Gabrielle Merite. I'm French. I'm an independent information designer.

2:41

So I help ethically driven organization uncover important truth and share stories

2:47

with intention backed by data.

2:50

And I'm also currently, for another month, the senior DeDeviz designer at Pentagram

2:56

in the team of Georgia Alubi.

2:58

Which we also had on the show a few times and who's of course well known.

3:03

And yeah, it's exciting to see you two work together.

3:05

Yeah, the incredible Georgia.

3:09

Ellen, how about you?

3:11

Yeah, I'm Alan Wilson. I'm a principal designer at Adobe.

3:16

Where I work primarily on the experience cloud, which is Adobe's enterprise

3:22

business. We make marketing software and other tools to help large organizations

3:28

keep their messaging and help their customers.

3:32

And I guess the main thing that we'll be discussing today is my contributions

3:38

to the design system at Adobe, which is called Spectrum. Right.

3:41

Yes. And this is also how we got in touch around two years ago because I started

3:47

working together with Core, an agency in the UK on a design system for the World Health Organization.

3:53

And yeah, and we sort of uncovered this whole world of wow, there's so much

4:00

happening in this space. And it's also really hard to orient yourself. Like it sounds so easy if somebody

4:06

says, oh, we need some database style guide or guidelines.

4:10

Can you help us do that? You know, everybody's like, yeah, sure,

4:12

that sounds great. And then once you look into, oh, what do we do?

4:16

What do we actually do now? What do we offer? What's the format?

4:20

What's the scope of the whole project? You realize, oh, it's not even that clear.

4:24

And everybody needs to figure out what they're doing in that space.

4:29

And so, yeah, so there's so many flavors and approaches you can do.

4:34

And so, yeah, I got in touch with you, Alan, and a few other folks who have

4:39

experience in the field to help us guide along a bit. And here we are.

4:46

So I know both of you have been working on these types of projects.

4:50

So before we go into all the nuances, what the differences between different

4:54

subgenres are, maybe we can start with the purpose.

4:58

What, in your experience, do people hope to achieve when they start building

5:02

a design style guide or start formulating design guidelines? Building a design style guide or start formulating design guidelines.

5:08

What do you think? What's the hope connected to that? Or what's the value to

5:12

an organization to have something like that?

5:15

I guess I'll go first. I think the main value is answering questions, right?

5:23

As organizations grow, you have to coordinate a lot more to make sure that you

5:28

as a group have a coordinated voice.

5:31

Space. Questions are very common, right? What font should I use?

5:37

What are our standard colors? How do we lay out this particular document type?

5:46

People need standards to communicate in a unified way.

5:51

One of the things I like about this space is there's just such a broad range

5:55

as you already touched on of ways to answer those questions.

6:00

But for me, it's all about. Helping people do their jobs more effectively and efficiently by answering questions

6:08

that they have a difficult time answering on their own.

6:10

Mm-hmm.

6:11

I love that answer.

6:14

Yeah, that seems pretty comprehensive already.

6:16

Yeah, I had a way more like strict like dot list. Yeah.

6:21

But I love that answer of answering question because I think it answers a lot on the definition.

6:28

I see, on mine, I kind of see like four kind of point of values.

6:35

Efficiency, just the idea of answering questions faster.

6:39

So just people being able to reuse design to know what to do.

6:44

All these things come into efficiency. Consistency, which I think is the one that people don't always see.

6:51

But for an organization, being able to reproduce a design over and over or reuse

6:56

some time of... set of rules and principle that they can build upon, scale.

7:01

And I think Alan is going to know that more than me.

7:06

And then the one that I don't see often, but to add pentagram in my work that's

7:11

been pretty important, which is recognizability. So in those guidelines in Style Guide, the idea of being able to produce something

7:18

that is recognized by an audience, like brand them.

7:22

And we don't talk about that often in data viz, but that's really important

7:25

to me when creating style guides.

7:27

Yeah. Yeah. And in the like more branding and PR and advertising world,

7:33

brand guidelines are super common, right?

7:35

And often we just receive them as, oh, here are our brand guidelines.

7:39

Can you make sure the charts, you know, fit into that?

7:42

Right. And so, yeah, that's already where we touch these wider like communication

7:48

contexts. But in this world, it's very common to have like a big book with the

7:52

fonts we use, these are the colors we have. This is how we pick photos.

7:55

You don't crop photos like this, you crop them like that and so on.

7:58

And yeah, I think in database it's a bit more new that we would,

8:03

be so explicit about this is our approach, right? Yeah.

8:07

I think one of the reasons data is emerging more and more in the style guide

8:12

space is because people are using it more and they have more questions about it.

8:16

So we're traditionally style guides focused on how you use the logo and how

8:20

you use photography and other visuals to communicate.

8:24

People are using charts to communicate and they have questions about how to best do that.

8:28

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

8:33

Yeah, precisely. And there's this idea of like, you know, authority.

8:39

I think in the world where trust is hard to gain, for organizations that have

8:44

gained that trust or are trying to gain that trust, having that recognizability

8:47

of like, oh, this specific data visualization is coming from this institution that I'm familiar with.

8:54

And I can recognize that a very first look seems really important.

8:58

In the public discourse.

8:59

Yeah. Cool. So I think we have the motivation is clear.

9:05

So you want consistency, you want a scale design, you want to make sure all

9:09

outputs coming from one source have a minimum level of quality,

9:12

they're recognizable, they look from the same family at least.

9:21

And not have to be a mysterious process process that some gifted rock star designers

9:27

can only do, but sort of scale the capability to anybody.

9:32

Ideally, right, that, oh, with the right ruleset and the right tools and the

9:36

right building blocks, anybody can now make a chart that looks like coming from

9:41

that organization and is solid. That's the hope. It's a big goal, of course. But now we're looking into,

9:49

okay, how can we enable that? What are the things we can supply? And this is super crucial to be clear about that.

9:56

That's a trap I ran into in a few projects that we weren't really clear what

10:01

the difference is between a style guide or a guidelines or a component system.

10:05

System. I like all these things. And then you realize, oh, they actually wanted

10:09

to have a big book with lots of data with do's and don'ts.

10:13

And we were like, oh, we thought we're just designing a database theme,

10:17

like pick some colors, right. And so there's a whole spectrum of possible outputs you can have, right.

10:24

And maybe let's talk about a few of them.

10:27

And I try to organize it from small to big. So I think the smallest thing is

10:32

probably like a design theme, where you say like, these are the colors and fonts

10:37

you can use for a given charge or something like this.

10:41

And maybe a brand has multiple themes like a light theme and a dark theme.

10:46

It's like a skin you can apply to a chart like an Excel template type thing maybe.

10:52

Then the next step is maybe a design system. Alan, is Spectrum a design system?

10:58

Where's Spectrum on that ladder?

10:59

Yeah, Spectrum is a design system and I would put it further down,

11:04

maybe even at the very bottom.

11:06

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

11:09

Yeah. When I think design system, I think the difference between

11:16

a design system and a style guide or a theme

11:19

or just a set of guidelines is a design system has infrastructure behind it

11:24

So that when you make a change those changes roll out into all the places that

11:31

they need to maybe there's also software components that exactly implement that stuff and Yeah,

11:37

yeah And it provides resources for all parties that are involved.

11:42

So the designers get the design assets they need,

11:46

the engineers have the engineering components that they're going to use,

11:50

and anyone else in the organization has the guidelines and materials,

11:55

templates, things they need to do their work.

11:59

And so, okay, cool. So we have design themes, automated in the design system,

12:04

and super well documented. So then how about guidelines and style guides?

12:09

How does that fit in? I don't know how Alan feels about it to me.

12:14

So I work hard on that one. I was like, is there a difference between guidelines and style guides?

12:19

And I think we use it pretty freely in the design world.

12:23

It kind of, we use it, at least in the, you know, bright side of things,

12:27

we use it kind of like whatever, we can exchange them.

12:30

However, I could see a difference where for me, like one guideline could be

12:33

like do and don'ts versus a style guide is kind of putting all those guidelines together.

12:39

So to me, style guide is a collection of rule. You know, it tells you what you're

12:43

allowed to do and not to do given a context.

12:48

And I guess I'm going to go one step further, but there's to me,

12:52

the style guide, if you think about, if you remove style and you just keep guide,

12:56

then you can also include elements of voice again, to that branding element.

13:00

So not just doing dance on design, on color choices, but yes,

13:04

on tonality, on content, on way

13:07

more than just the look and feel and the practicality of design elements.

13:12

So that's how I see the difference in guideline and style guides,

13:15

but in the design world, we definitely use them almost as exchangeable.

13:19

And that part cannot be automated or implemented well in software,

13:22

right? Like, how do you automate tonality?

13:27

Can you? I don't know. But at least, let's say, a style guide or design guidelines

13:33

are usually targeted at people making charts. Right? Is that fair to say?

13:38

I mean, I think all of these are targeted at people making charts.

13:41

But to Gabriel's point, some focus more on the aesthetic part of the problems

13:47

and the aesthetic questions. And others focus on the technical questions and implementations and things and

13:54

systemize things a bit more.

13:55

More. Yeah, so you can see already, it's this muddy mess of people,

14:04

machines, data, audiences. It's an exciting space. And then really think about, okay, how can we abstract

14:12

principles there and re-covering rules and not just solve problems once,

14:17

but more or less for once and all, which is of course the hard part.

14:23

It's funny because it reminds me of what Alan was saying about the design system.

14:29

So at least just like Alain had placed it at the end, to me it's what encompasses

14:33

everything, including Style Guide, but also design theme, design language,

14:37

like the actual components and little design elements, like templates that you may have created.

14:42

And I would call it a repository of institutional knowledge that solves problems,

14:47

that keeps happening. Like that's how I would define it probably without even

14:51

putting like what it is inside. It's just a big, big, big repository and it can be flexible depending on your institution.

14:58

Yeah, right.

15:00

Yeah. I think another thing worth calling out is that sometimes data visualization is its own thing.

15:09

There is a datavis style guide, and it lives up separate from the brand guide

15:13

and the user interface guidelines and other resources.

15:18

But more and more, we're seeing all three of those things. And other things as well come to,

15:35

content guidelines in important ways that we need to account for.

15:37

Yeah. Yeah. Yeah, so there's a lot of overlaps with adjacent, maybe other design systems,

15:45

like the branding or the UI design, and we need to see how we fit in with all of that.

15:51

I guess what's unique to data visualization is often the extra design vocabulary you need,

15:56

like specific color scales that work, have certain functional properties or

16:02

or chart types and all the things we're all familiar with, legends and axes and whatnot.

16:10

Yeah, one of the challenges with writing guidelines for data is that differs

16:14

from brand guidelines and others is some of the other areas are just self-evident

16:21

and really easy to explain the guidelines for.

16:24

And data visualization has its own language and its own set of things.

16:30

I mean, it intersects with data literacy and some specific domain expertise

16:36

that you might need to be effective. And often I find myself in writing the guidelines, I'm like,

16:43

man, I need them also to read these books.

16:45

Or I find myself wanting to teach data visualization as a discipline,

16:51

and then I can give them guidelines on how to best use visualization.

16:56

And if you don't have that foundation, sometimes the guidelines come off a bit

17:01

short because they have to be so basic.

17:05

Yeah, same problem here.

17:07

Yeah, and maybe that's the first real learning I think we all share probably

17:11

is like, you really need to define really well what the purpose of the whole

17:15

thing is and what your audience is.

17:18

Like, is it skilled information designers that use it or should it be implemented

17:23

in an automated system or should it be for total novices,

17:27

like a foolproof system, because that will shape everything in terms of what

17:32

do we even supply people with and in which form, right?

17:35

And yeah, I think if you skip that step, it's going to fall on your feet really soon.

17:42

That's my experience at least. But maybe to make this a bit more concrete, maybe we can talk about some of

17:51

the projects you've been working on in that space.

17:53

That gives people a bit of an idea of, okay, what are the different challenges

17:57

and the different types of flavors that exist? So, Alan, do you want to talk

18:02

a bit about Adobe Spectrum?

18:03

Sure, sure. So Adobe Spectrum is our design system.

18:10

If you want to take a look at it, you can find it at spectrum.adobe.com. And,

18:18

Yeah, the first thing I want to point out is that it's a whole team.

18:20

There's a lot of people involved. And so I am a small piece of that whole ecosystem that builds and maintains that.

18:30

And the design system was about two years old before we introduced the data viz guidelines.

18:36

We really struggled to articulate and structure the guidelines in a way that

18:40

would make sense and be relevant to our users.

18:44

And we still have a long way to go. I feel like the guidelines right now are

18:47

pretty basic, but yeah, we have that. And the primary purpose of our guideline

18:53

is to help people who are building software.

18:56

Right.

18:57

So it is used for our, you know, dot com website and some other things,

19:03

but the primary focus is for how do we build, you know, really good software using that system.

19:09

Cool. Gabrielle, how about you?

19:11

So I worked on quite a couple and I can't talk about everything.

19:16

So I'll talk about the one I'm publicly allowed to.

19:19

I think the one that's the most public that you can see on the pentagram website

19:23

is the Deloitte insight. It's a guideline and templates, so it's not full design systems.

19:29

And so, DeLaw Insight is a magazine. It also has a web platform attached to it.

19:36

And previously, before I even joined Pentagram, the team with George Ilobby

19:39

had actually built guidelines for them before editorial database.

19:43

So, we're more creative application. So, that was used only by information designer

19:47

that already knew the roles and were pretty comfortable with it.

19:50

Talking about audience here. And the issue that came back when they came back

19:54

was that we cannot give those guidelines pretty much to our normal designers.

19:58

So the team actually use external, a lot of external designers that are around

20:04

the world with different backgrounds from different countries.

20:07

And they produce like hundreds of data viz per month.

20:11

And they're quite fast, so fast turnaround, you know, little supervision.

20:16

So we were in contact with more of the creative direction marketing data this

20:20

team within the organization, not so much the designers.

20:25

So we had to create templates and guidelines knowing that we have no contact

20:30

with the final designer that's going to use them. And they are not specialized in information design, not always at least.

20:37

And they have a high turnaround themselves because they're external contractors.

20:41

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

20:46

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

20:52

Of course.

20:53

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

20:56

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

20:58

And the law inside covers any themes, so it can be any type of data,

21:02

whether it's about people, but you know, economic, like anything,

21:06

everything, throw it in together in one package.

21:10

So that was probably one that I can talk quite a bit on. And the other one is

21:15

for a nonprofit organization that I cannot name.

21:18

They work in the gender equality space. And this one was tricky because we had

21:22

to do it and they hadn't produced any work yet.

21:27

It was made simultaneously to a brand. And so they knew what type of data they were working with.

21:33

But they had not produced anything. So we didn't have anything to even review.

21:37

We had to do from start and we had to make sure it would be used by designers

21:41

and non-designers for social media, PowerPoints, anything possible.

21:46

So that was another challenge on really sensitive topics too.

21:50

So definitely interesting different challenges here.

21:55

Yeah, so you can see already it's quite different requirements and you need

22:00

to be smart about what you do, right? And how that will play out.

22:04

So maybe talking about process, then how do you...

22:10

Address this? Like, do you first build a lot of chart examples,

22:15

like in your design team, and then say like, okay, what are the recurring patterns?

22:19

What seems to work? What doesn't seem to work? Or do you do it more top down in terms of,

22:23

okay, we have the following principles, we have the following project constraints,

22:27

you know, and sort of do it very like deductive in the sense that,

22:31

okay, only one solution, you know, seems to work anymore, now that we have like defined everything?

22:37

Or is it a mixture? Like, how did you address these? How did you approach this

22:43

project? Maybe Gabby, you can.

22:45

Okay, I'll start. It might be very different because we so we even me as an

22:49

independent or within Pentagram, we are external contractors.

22:53

So we don't have access to everything internally in the organization that might

22:56

be quite different than the way Alan works typically.

23:00

So the way I like to work is I start with what I call analysis phase,

23:04

which is just looking at obviously who the organization is.

23:08

The more classic design brief analysis of who the client is,

23:11

what do they know, what do they don't know.

23:14

So if they have data visits, it's great because it gives you a great insight

23:17

on what has been produced, what type of data do they work with,

23:20

what are the mistakes they keep making, what are the problems they keep.

23:23

You can even have a whole almost user research phase.

23:26

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

23:32

Yeah, a little bit. But just identifying existing useful patterns,

23:36

things that have worked too and things that are not working in the current applications,

23:40

and who is working with it. It's way harder when we have a project, like I was talking earlier,

23:45

where we don't have access to those existing applications, because there's none.

23:51

But there's always a base somewhere of what data are they going to use?

23:54

Where is it going to be published? So I like the science in space and understanding, again, who is going to use the guidelines and,

24:02

This is the audience of the guidelines. So is it designer or non-designer?

24:05

Because it's not always for designer. But also who's the final audience of the data visualization?

24:11

So there's a second layer.

24:12

It's a double hop.

24:14

Yeah, there's a double hop here of like, OK, typically, if you work for a nonprofit,

24:18

the final product is going to be a public, a very uninformed public,

24:22

or on a sensitive topic. So what are the constraints already that I impose on

24:26

the project? So there's all this analysis phase.

24:29

And then I guess it's a bit of a mix match. What I like to do is a bit more of like,

24:33

if it doesn't exist anymore, it's kind of like doing design first and then link

24:38

that back to the foundation of, I find it difficult to build the foundation

24:43

first, decide the colors, everything without testing them, because you're gonna end up changing them.

24:48

So I tend to, even if the project doesn't include making templates,

24:51

kind of templatize a little bit, like test out some basic charts or things they

24:55

use regularly to see if we can start finding patterns and put that back into guidelines.

25:01

So that's kind of how it works. The only added thing that I do and then Pentagram

25:06

does too is what we call creative direction, which is maybe a little different

25:10

than a traditional style gal, which we're trying to find what makes those these evolutions stand out.

25:15

How do we connect them to the voice of the brand?

25:21

And so it's not just through just colors and typefaces, but is there something

25:25

specific, a specific way of a specific shape you use systematically.

25:29

So not just basic charts.

25:31

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

25:36

Is there a metaphor that we can use throughout? Is there something that makes

25:39

it stand out that's just not a design decision, but that makes it unique?

25:44

And so that is a little more, on the creative side, that's less common.

25:47

And then it's even harder to explain in Style Guides. But it's part of that

25:51

thinking. And then usually you test that on basic chart and then you test that

25:55

on editorialized charts because all client usually needs editorial charts and not the most basic.

26:00

You know, the most traditional charts, just to check if it works in conjunction

26:04

with other organizational systems, like does it work in a magazine spread,

26:08

does it work in social media format? And then we systemize that and we put that all together in like extended guidelines.

26:15

Yeah, but there's an interesting tension because of course you and Georgia of

26:19

course are typically known and booked for a super creative, unique,

26:24

one of a kind work, right?

26:26

And now the expectation is you do that, but also make it repeatable. Right?

26:32

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

26:35

Yeah.

26:36

It's definitely a challenge. It's actually quite interesting because we end up creating,

26:39

to me, it's almost like I split the guidelines into traditional charts with

26:43

the most traditional bar charts, bar charts, whatever you need to have that

26:47

needs to be made in PowerPoint, like we've got custom design,

26:50

especially if we have users that are not designers.

26:53

So PowerPoint, Canvas, RowGraph, the easy building building blocks that can

26:57

be reproduced and used for anything we port. But then we usually have a second

27:01

section that's for designers, an information designer.

27:05

And sometimes it can overlap a little bit. It can be very simple things that

27:09

you can do. Adding a shadow, adding a texture, photography.

27:13

How do you use photography? Do you crop it? Do you not crop it? Is it textured?

27:17

Is it black and white? Does it use a color? So this is something that we add

27:23

that's almost branding and that adds customization into the guidelines.

27:27

Cool. Yeah, that makes a lot of sense. And yeah, it's super interesting.

27:32

Ellen, I could imagine your process is totally different because you don't work

27:36

in an agency, but it's more this ongoing big ship instead of the little dinghy

27:42

with the little party on it.

27:44

Yeah, yeah. Earlier in my career, I worked for agency.

27:49

And we did a lot of brand guides and things of that nature, which certainly

27:53

informed a lot of the work that I do now, but yeah, it is different.

27:57

And I do think there's no one process for this stuff. It really is,

28:02

part of the problem here is figuring out what an organization needs and how

28:08

you can best deliver that. But for us, and one of the advantages of being an internal team is we can deliver

28:16

things incrementally, right? It's not a single deliverable.

28:21

We can do something and then add to that over time.

28:25

And so that's the approach that we've taken is, and we try and prioritize the

28:30

most important, most valuable, the things that are gonna have the biggest impact

28:34

and then keep adding to that. And at some point we'll reach a threshold where, the incremental value isn't

28:40

worth the incremental cost. Be that, actually monetary costs are just costing complexity because as your

28:46

system grows, You can't grow indefinitely or it becomes unusable because it's

28:53

too big and too complicated. Starting to run up against the bounds of what we feel is an appropriate level of complexity.

29:02

But yeah, we do start with the end in mind.

29:07

So we'll often produce a lot of example screens and visualizations and UIs and

29:13

then write the guidelines that would produce those, if that makes sense. So we work backwards.

29:21

Retrofit, basically. What would have been the rules that would have made these

29:26

choice that obviously seem to work.

29:28

Exactly. I feel like that's a good approach.

29:34

But at some point you have enough guidelines that you don't have to start with

29:38

the end and you can just take what's existing and expand it a little and then

29:42

see what comes out of it. Yeah.

29:46

That's something we also struggled with a lot is you want to get started somewhere

29:50

and build stuff and see stuff. Otherwise, how could you even progress in the

29:55

project? project, right? You need something visual to work with and to debate.

30:00

At the same time, you feel like it's such a big system. And if we just keep

30:04

making graphics, you know, it's never be a proper system system, right?

30:08

And so when when do you introduce these rules? Or do you redo all the example

30:13

charts you did before if some design decision changes?

30:17

Like, you know, how do you keep it dynamic also? And one thing I found there

30:23

is this design tokens approach that I'm super excited about.

30:27

It's like, so if you're a bit technical inclined or you like coding anyways,

30:31

then I think that's worth looking into because it's a really neat way to sort

30:36

of store all the basic design decisions in the standardized format.

30:39

And then ideally if the brand color changes or if the background color changes,

30:44

it all trickles through your implementations.

30:50

There's also the risk that you could then keep perfecting that system.

30:57

And it becomes a little hobby to clean the token structure and rethink about the hierarchies then.

31:04

But I think that helped me a lot to think about, okay, what are the building blocks?

31:10

We need a background color. We also need a sort of a shaded background color.

31:14

We need two text colors or maybe three, right?

31:19

Them by how they look, but what they do. Oh, it's the high contrast or the low contrast version of it.

31:24

And that helped me a lot to think about it in a structured way on the basic

31:29

LEGO building block level and stay flexible in terms of, oh,

31:33

I think we should change the text color on all charts.

31:35

That was much easier because we had that system in place. So yeah.

31:42

That's the benefits of design systems. Because I think instead of the GAN line

31:47

constrained versus as a design system and tokens and components and patterns

31:53

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.

31:58

And here are just a couple of rules about big mistakes you could make.

32:03

And you know, at Pentagram we do a lot of just the rules only.

32:06

And I think that can be constraining and not flexible for an organization.

32:12

Yeah, on the flip side, I think it allows that creative work to have greater impact.

32:22

So if you have to design every chart by hand, you spend a lot of time designing

32:27

the same thing again and again and again and again.

32:30

But if you have a system and you're designing the system and playing with the

32:34

tokens, the output scales up really quickly. I mean, it's nearly infinite,

32:40

You have so many different outputs that can be automated.

32:44

And so, yeah, it's that flip. The other side of it, right, is that the creativity that is left to do is more

32:54

impactful and less menial.

32:57

Yeah, I love that. Because I think sometimes what you hear is,

33:00

well, we don't need one because we want to do creative things, but it's the opposite.

33:04

If you remove the small choices of picking the right font sizes,

33:07

font sizes, picking the right font away, then you can spend more time actually

33:11

looking for creative solution, but you have some blocks that are predefined

33:15

that makes it way faster. And repeatable, obviously.

33:18

So I tend to agree, I think it actually opens up more flexibility, if anything.

33:22

Yeah. But it's an ongoing thing. And I think another big challenge is,

33:29

I think the initial version is easy to build, right?

33:35

Like how do you make it grow? How does it evolve over time?

33:39

And how do you not have it end up like the German administration that has lots

33:44

of really good rules that in isolation make a lot of sense, but it's a bit too many of them overall.

33:52

And so how do you manage?

33:57

Complexity when things grow, right? Or even out of your hands at some point.

34:02

Like, what's the life cycle of the whole thing?

34:05

Well, my experience is the opposite. I think the first step is the hardest. Interesting.

34:09

The initial thing is so hard. Maybe it's just my nature that I want it to be

34:14

whole or complete in some way.

34:16

And just right from the beginning. Exactly. I have that kind of perfectionist

34:20

mentality. I don't want to put something out out there until it's ready and

34:23

I really am confident in it. But my, and so my experience is that part is the difficult part,

34:28

but once you do have something out there, then delivering incremental value

34:33

is a lot easier because you have a good feedback loop, right?

34:36

You know what people are using, you know what they like, you're hearing feedback.

34:42

I mean, designers have feedback, right? They'll tell you what is and isn't working

34:47

for them and you can spend time with them to get into the why.

34:50

And then for me, the rest of the process is more natural. It's a lot more service

34:55

oriented where you're like, oh, okay, well, this isn't working,

34:58

so let's focus on fixing it, or this doesn't exist yet, so let's create that thing.

35:05

And it's really just how many people need that. And that can be a little more

35:09

harder to determine, but you're just trying to measure impact.

35:14

Well, like, Gabby and I, we are brought in as external consultants, your in-house.

35:21

What do you think? What can the roles of external consultants be versus in-house folks?

35:28

I've also met people who said, design system? No, we don't work with external

35:33

people on our design system. That doesn't make sense, right? Because they've begun in three months,

35:38

then it takes care of the actual work that happens afterwards.

35:46

Or is there something we can do? I don't know. What's going to take on that?

35:52

Well, at Adobe, we treat Spectrum like a product, like any other product at Adobe.

35:57

It's a thing that we build. The differences, our user base is almost entirely

36:02

internal. We do have some external people, vendors and partners and so on,

36:08

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.

36:17

Not to say that agencies don't play a role in creating some of the initial work

36:21

or coming in and helping you audit it or bring new life to it, bring new ideas.

36:30

Sometimes things can get a little stale internally because you're just kind

36:34

of recycling the same set of ideas among the same set of people,

36:38

so fresh perspective can be really useful.

36:41

I also think it depends on the nature of your organization, how big it is,

36:44

right? If you are a relatively small startup, you can't spare even a single

36:49

person to run a design system. That would be ludicrous to consider.

36:55

And so having someone build something for you that you can just use and maybe

36:59

touch up every year or so might be a better route to go.

37:04

There's as many solutions as there are problems.

37:06

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

37:10

No, you raise a good point. Because I found it frustrating as a designer who

37:15

makes guidelines as a contractor, to just, we dropped it to a client and we're out of here.

37:21

Like, no feedback matters. There's a scope that's defined, there's a budget

37:24

that's defined. So if the scope was that we don't get feedback on it,

37:28

we don't get feedback on it. Even though it works or it doesn't work,

37:30

it doesn't matter almost because we get paid.

37:34

Unfortunately, that's how the business works. I hear you, Alan, and I agree. I think there's a space for it where a small

37:42

organization cannot afford, they don't have the time and the resources to set

37:46

it up, like the initial big phase of doing that work.

37:49

But I do think that the development and the incremental changes needs to be

37:54

done internally, otherwise you're going to end up paying an external agency

37:57

for everything and they are not as familiar to your organization needs.

38:02

Than the organization itself. As an extraordinary don't say that we have a value that we bring.

38:09

Maybe it's at the initial phase, maybe it's at a big review phase,

38:11

maybe it's just to, you know, nobody has time. So, you know,

38:15

you give them, you let them do kind of the work and then you take over.

38:18

But yeah, we cannot if you're going to maintain it, it has to be done internally.

38:23

I think, you know, oh, sometimes we can come at consulting to solve issues.

38:27

But I really think that, you know, our values are definitely limited here. We can't do it all.

38:33

Well, and I think that's part of the value of a design system,

38:37

is it needs to be a living thing. Because if it's static, it just doesn't continue to solve problems.

38:46

You need it to evolve to solve the different problems that you encounter.

38:50

So, yeah. Yeah, and I've been thinking a lot about that too.

38:55

How do we actually make sure people use the things that we design and keep using?

39:02

And they say like software is either maintained or abandoned.

39:05

And I feel like the same might happen with design systems.

39:08

If you don't like have somebody internally always pushing for this,

39:12

the system we use, it's cool. This is how you use it. Right.

39:15

And so you need also these these advocates and people who do onboarding with

39:20

new folks to keep it going and so on.

39:22

And yeah, and somehow you need to think about that whole social process around it as well.

39:27

Right. Yeah, the other thing I was thinking about, maybe it's good also not

39:32

to have so much rules, but more, maybe supply more templates or tools or like

39:38

really easy one-click solutions, you know, to do something.

39:42

So think about what's the threshold to even using your design system.

39:46

Like if it seems to be a big burden or like a big like, oh, I need to read this

39:52

whole book before I can make a single tried, you know, then that immediately might be off putting.

39:57

And if you're then not there to enforce it, it's like, yeah,

40:01

we don't care so much about this big rule book.

40:06

So yeah, but then again, you need to know really well what people want to make

40:10

with it. And maybe that's often not that clear.

40:13

It's interesting to think that... External contractors like me, for instance, are designer and use guidelines.

40:19

So we are often like the consumer of the product itself.

40:23

And so I guess the way I see it, I've changed quite a bit of the way Starguide

40:28

in agency work is often, Starguide only is a big PDF of 60 pages.

40:32

You know, PDF, all school, sometimes made for print. So vertical, right?

40:38

Also books, real books.

40:41

So it's interesting how you can just come in and be like, I know what I would

40:44

like. So to your point, I think sometimes we don't have access,

40:47

at least I didn't have access to the designer that would be using the book,

40:50

but I was like, here's what I wish I had. So, you know, text style, paragraph style made in advance in Illustrator.

40:58

Paragraph style made in advance in Figma.

41:00

Template documents, right?

41:01

Just that kind of thing. I don't want to have the copy paste,

41:04

the goddamn hex code anymore. Just things like that. So I think it's interesting how, you know,

41:10

But sometimes we forget also, we do things a certain way.

41:14

So it's interesting how sometimes having somebody new coming in can help with

41:19

that or can look at it being like, I'm not sure this is working for me.

41:22

Because I also find places where they're like, well, we do use the brand guidelines.

41:25

We don't really know what we need. So there's a balance in everything of asking the audience, having your own input

41:34

and being flexible enough to change how we do things every time.

41:38

For a new client, for instance, I change it every time.

41:40

Everything, including the basic charts or the decision charts,

41:44

and decided what chart to use when, It's different for every client, depending on the topic.

41:50

So it's definitely interesting how the audience can, can like force us to adapt

41:55

every time, even for just the initial brief. And then I can imagine internally how that changes.

42:00

Yeah.

42:01

I mean, I have a very similar experience. The very first foray I had into this

42:08

was like a 60 page PDF, exactly as you described.

42:13

And we printed it out and it actually, everyone loved it. Cause they had,

42:17

we didn't have anything like that before. And so people like engineers and designers had it at their desk and they'd have

42:23

it flipped open to pages, but they would be typing in those X codes and rebuilding

42:28

the buttons themselves. And so it was only a week or two before an engineer was like,

42:34

can we just get this in Git so that I don't have to rebuild all this stuff?

42:38

And we had designers that are like, where's the, this is how old I am as a designer,

42:43

where's the Illustrator template for this or the Photoshop template for this?

42:47

Or the palettes you can download and all that stuff.

42:50

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

42:52

Thank you. Exactly. And so we started to create those. And so it slowly evolved

42:58

from a PDF that people printed and kept on their desk to a website with downloadable resources.

43:05

And I think it's really important to meet people where they are.

43:10

There are times when you need to push people into new and different tools to

43:15

better do their job. But for the most part, they have the tools to do their

43:19

job and they just need you to provide the resources.

43:21

And so if your users are in PowerPoint.

43:25

Make it easier.

43:26

Exactly, if they're in PowerPoint and that's what they're using to build their

43:29

charts or Excel, you've got to provide those Excel and PowerPoint templates.

43:34

It pains me sometimes to say that, but it's true. And likewise,

43:38

if they're in R or Tableau, use the tools that they use, provide the resources

43:43

in that tool's format that form tools language and you'll be more successful by far.

43:51

Yeah, I think that's interesting. And I think that also, if you take that super serious means,

43:56

really, you can't be too picky about all this, the design details,

43:59

really, like, what the spacing is exactly, or, you know, what type of tricky

44:05

access configuration you have come up with, but really be more really clear

44:10

about these are our underlying principles.

44:12

And this is what, like, qualities all all of our charts should have in terms

44:16

of accessibility or voice or whatever, but then being really flexible about how that happens.

44:23

And maybe there as a designer, we need to be a bit more like,

44:26

the details don't matter that much, it's fine as long as the general direction is good.

44:34

Or am I being too generous here? No, there's a lot of truth to that.

44:39

But I feel like one of my roles as a designer is to never give up on the ideal, right?

44:45

So I always- It's facing matters. It does. That rounded corner makes a difference,

44:51

right? It's only a one pixel axi, but just round that corner and it just makes it sing, right?

44:59

And you can get that if they're working in one tool, but in another tool,

45:03

like it just doesn't support that. So there's a reality to what you're saying, but I do think we need to advocate

45:10

for the ideal and then compromise as needed.

45:15

Yeah, yeah. You can have one gold standard implementation also,

45:21

where you say this is how it really should look like.

45:24

That's how it's meant, but then maybe flexible on.

45:28

In a different context, it's fine if it doesn't hit all the design details.

45:32

I also found it, it's often that, to me, the pixel close, those precise details

45:39

helpful sometimes for specifically non-designers or people who are like not,

45:46

I think this, because we can't teach them design, we have to give them really

45:50

precise rules so that they don't have the understanding of what the right spacing in, text hierarchy.

45:58

And so we see it regularly when researchers make PowerPoint,

46:01

right? No offense to researchers out here.

46:04

We respect you, we used to be there, we know how it feels. But I think sometimes

46:08

they just don't have the sense, they don't have time to even learn,

46:12

and we don't wanna make them designers. So it's more, those rules can also be set up sometimes just to actually help

46:17

them without having to like give them free workshop on how to do database.

46:20

It's just like, here is it easy. You just have to follow this exact guidelines,

46:24

this exact pixel, this exact roundling corner in your software,

46:28

we give it to you so that you don't have to think about it really and to make your job faster.

46:34

Otherwise, interpretation is nice, especially as designers, we know how to do

46:37

things. So we feel more comfortable taking some freedom into interpretation of the guidelines.

46:42

But I think for other users, it might be really important to just help with

46:47

that and just give really precise guidelines that just makes their work easier.

46:50

But then I'm thinking if the exact one-to-one look really matters,

46:54

then maybe it's actually better to supply a software that creates the thing

46:58

as it should look, or a template, because otherwise you end up with really long, super detailed specs.

47:05

I think so, but it's hard to sell to clients sometimes.

47:10

At the industry level, I think that's what I run into is often we get scoped

47:15

for just the guidelines and no templates.

47:17

And they may come back six months later and ask for the templates.

47:19

That happens regularly. But you wish you could sell it and be like,

47:23

you're going to need this. Believe me, you're going to need this.

47:26

And the guidelines. Yeah, this is where this initial scoping comes in,

47:30

in terms of, okay, what do you hope to achieve? Who is this for?

47:34

What are the actual things we should supply because of that, right?

47:38

Yeah, interesting. And at the same time, the whole tooling landscape is shifting

47:41

too, right? It's like, what do you do your charts in?

47:45

There's a new answer to that every two years. And ideally, our stuff should

47:52

survive a few of these iterations as well in terms of tooling.

47:55

And so there are a lot of challenges there.

48:01

I think we need to sort of wrap things up semi-soon.

48:05

I have two more questions. So one is about are there any caveats,

48:09

traps, failures, things you wish you would have known before somebody sent you

48:14

on that impossible journey that you could share with our audience who might be new to the field,

48:22

like something valuable to avoid or just stuff that happened.

48:29

Oh boy, I would say be humble and listen.

48:34

I remember early on I had just discovered histograms and I'm like,

48:38

oh histograms, okay. And I thought I understood what a histogram was.

48:44

And I was writing guidelines and explaining to people and six months later I

48:51

realized I was wrong about some fundamental things.

48:56

And it was difficult to eat that crow and fix the wrongs that I had done.

49:03

Because people trusted me, right? I taught them things and I thought I was right

49:07

and they thought I was right. And I wish I had just been taking a little more

49:12

time to educate myself before I had put forth these things.

49:17

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

49:23

Yeah, yeah.

49:26

Yeah, I like that you said people trust me, because to my point,

49:30

I think, especially at Contractor, we get a lot of trust, and they hire us as experts, right?

49:36

So we tend to be trusted, and you know, whatever we say, it's going to be the

49:41

Bible. And I found it problematic. Not problematic, but I found that it's a lot of responsibility that we forget, I think.

49:50

And I wrote about this recently, but I think especially when we make guidelines

49:54

that are going to be used potentially by hundreds of people or templates,

49:58

it's, we have such a responsibility to do them properly.

50:01

So not just for the users so that they're usable, easy to understand,

50:05

et cetera, et cetera. But I think we need to meet the big caveat when I got

50:09

lines is we don't approach like ethics in database and guidelines.

50:13

We're like, here's the job. This is how you make it. Especially when you like me and you work with a lot of data that like social data. So bad people.

50:20

Of course, I think it's getting more common, accessibility, some kind of rules.

50:25

It's becoming more common, but I still see a lot of it as just like,

50:28

here's the colors, here's the thing, do whatever you want. And I just, I want to start this conversation with,

50:33

you know, maybe we shouldn't, the colors matter, but maybe we should also question

50:39

like, should guidelines also offer more guidance on when do you actually need to do database?

50:46

Which database should you be doing? Like should you actually emphasize differences

50:50

between social groups, ethnicity for instance?

50:53

Like we have research nowadays that shows that maybe it's a problem to raise awareness this way.

50:58

And I'm wondering, and I know it's a little further than what designers are,

51:02

I think we get caught into the detail of design, but at least designers like

51:07

me who work on guidelines for those big organizations that,

51:09

you know, approaches like sensitive topics, I'm just wondering if there's a

51:13

place for us to be more responsible and think twice about the work we do and

51:19

give guidance on maybe even terminology. Like, how do we use, you know, ethnicities? Yeah, texts. Like,

51:27

you know, how are we, can we promote transparency in how data is sourced within

51:32

the guidelines? Like, I think there's so much more we can do with it that's

51:35

not just design related. So I guess that's my big statement. I just want designers to be a little more,

51:42

but to also space is happening.

51:45

Think about more than decoration of numbers, right?

51:48

Yeah. And also have that humility, you know. I think he makes a great point.

51:52

We are a little bit approaching a top-down approach, like designers say something,

51:56

and we are problem solvers.

51:58

Yeah, and also the hope is with this design system, it's the Bible.

52:02

It's once and for all, this is how you do it. And we all know this is not how it works.

52:09

You can be brilliant at your job and do it for 30 years, and still every project

52:13

is new, and there's always uncertainties and doubt.

52:16

And you could always do it this way or that way, and in the end you just make

52:20

an informed judgment call. but there's no absolute truth in design, right? And so, yeah.

52:27

I love that point because I think there's so many decisions that lead up to

52:31

the final product of a visualization. And a visualization doesn't often acknowledge those things, right?

52:40

I think that's one of the most problematic pieces of data visualization is because

52:45

it's so easy to trust. That's why we see so many problems emerge around dishonest

52:51

charts and things of that nature. Even the most well-intentioned individual is obscuring the actual truth to some

52:59

extent in an effort to tell a story or to simplify a problem or illustrate a point.

53:05

So I don't know how to solve that, but, and it goes back to,

53:08

I guess, one of my earlier points about the desire to educate people,

53:12

not just about styles, but about data literacy and all the overlaps and intricacies of data visualization.

53:20

I just, I think that's an important thing. And to your point,

53:25

Gabriel, we can't lose sight of that.

53:28

Yeah, I don't know how to do that in guidelines. It's definitely an education maybe,

53:32

but it is about, I think we tend to focus designer,

53:36

we're taught for a long time that we are like solution maker,

53:40

you know, but we should focus on approaches, on like something that's flexible,

53:44

agile, and that gives space to others to give the opinion and take decision,

53:49

you know, give them the best tool, including an educative tool,

53:52

to make those decisions rather than just get really strict guidance that might

53:56

be also found false or harmful in 20 years, because I think we see a lot of that nowadays.

54:03

Yeah, that's a great point. Maybe it's related to my last provocation that I

54:07

want to throw in here, because maybe I'm just getting old, but I find that a

54:11

lot of design is really boring these days. Like web design is super boring.

54:14

Everything looks the same. There's like big round buttons.

54:18

You know, I feel like there's like five templates and they are just applied all over the whole web.

54:24

And I think in a way it's cool because everything's super easy to use now.

54:28

No surprises. It's like, cool, I know my way around.

54:34

On the other hand, I feel like if we streamline everything and everything gets

54:38

formalized and optimized and templatized and standardized, where's the fun in that?

54:48

No, don't we abstract away all the interesting, a bit uncomfortable,

54:54

weird, edgy things? If everything becomes formalized and standardized?

55:00

And are we contributing to that with our design system work?

55:03

That's something I've been thinking about.

55:05

I have a thought on that. So it's an interesting question because you said,

55:10

I know my way around, which I think most people do, and the idea of we've standardized

55:15

web design, for instance, is pretty standardized.

55:17

I think there's a question of like, it's standard that's for who?

55:22

Because we're in this conversation, right? We're standards, you're centric and then Americans.

55:28

And I think we need to ask this question of like, when we do that,

55:33

when we automatize things, when we do this thing of standardizing,

55:38

do we take into account enough people?

55:42

I think we all have this thing of like, this is how design is done.

55:46

Modernism, it needs to be clean and minimal and sensitive.

55:50

Like, why?

55:51

You know, when you look at design from East Asia, like, it might look very different.

55:55

And to the eyes of American designers like me, I mean, like,

55:58

it's messy. It doesn't respect text hierarchy. It's not albedica.

56:02

Well, no, albedica doesn't write like in the story, guys.

56:06

So it's interesting how I wonder, I'm not against it. I actually found it like, to me, automating.

56:11

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

56:16

Is it for the right thing? When is it used? How is it used? For who is it used?

56:21

Is I think those questions that, you know, are like, I find challenging.

56:25

Like, I want to automate my workflow. I want to, I think it's so practical to

56:29

have those technology, Figma components. Like, it's so great. I just wonder if we automate, we tend to repeat a certain

56:37

point of view in design that has been put by a certain type of population.

56:41

And maybe it doesn't apply to everyone, it's not fit for every audience.

56:45

Yeah, I agree with that. I think that I like that.

56:52

I think my take on it is that sometimes it's an enabler. We've talked about

56:57

that a little bit already. By systemizing design, it enables you to design a lot of things at once.

57:05

And that's really cool. And I think that's really powerful.

57:11

And typically, the thing that kind of design you're enabling is,

57:15

to your point, more it's pretty expected and not terribly exciting.

57:21

But it works and it's usable. But that's not to say you couldn't build a system

57:26

that is just wild and crazy and super creative.

57:32

So I think I'm really excited for the next 10 years because I think not only

57:38

are the tools that we to do this work going to continue to evolve and change,

57:43

and there's going to be new ones and things, I think the work that comes out

57:48

of those tools is going to be better too.

57:51

I think one of the challenges to being creative isn't necessarily the systemization,

57:57

it's the feedback loop, right? Right now, like I author my system over here, and then I see the results over

58:03

here, and it's very difficult to kind of connect all those dots.

58:09

And I think software is going to get better and better providing creative feedback

58:14

loops for all types of design, not just.

58:18

The kind of traditional print and web design that we've done up until now,

58:21

but the more system level design.

58:23

If you think about AI tools, they can generate hundreds of variations of something,

58:28

and then you pick and curate and combine.

58:31

That's a whole new thing. Exactly.

58:34

I think the idea of curating, I'm obsessed with AI, I think it's going to change

58:40

how we approach things. I think it's a tool.

58:42

It's just a tool. So we need to use it as a tool and it's not a finality.

58:46

It's not just you run it and then you just dump it and that's done.

58:49

And if we involve human beings in it and we still have a customization of it,

58:54

you know, and we we curate the result, then then that's the it seems like the

58:58

right approach to do that.

58:59

Yeah. Yeah. And maybe Lego is a good metaphor in a sense that it's super standardized.

59:04

Like Lego is the most standardized tool you could think of or toy you can think of, right?

59:09

Actually, each block is super boring, but you can build anything out of it.

59:14

It's like endless fun, right? And so maybe, yeah, thinking about more like,

59:18

oh, it's building blocks. It's something you can play with and build stuff out of, you know,

59:23

is a better thought than it's a book of laws. You have to abide to it. Yeah.

59:29

It might also help with gatekeeping in a way. Like, I wonder how much,

59:33

when I'm seeing AI mid-journey, like how much of now people who are creative

59:37

but never got the chance to be educated, have the time to learn Photoshop can produce art.

59:43

There's so much, obviously it's a little further away from a discussion,

59:46

but automation and all those tools that are going to make our work practical

59:49

is also going to allow more people to join the community of designers.

59:52

Like, designers are going to take a bigger, you know, a bigger umbrella,

59:57

maybe we'll have more people with different opinions and different backgrounds.

1:00:01

It's a good point. So the more people we bring in, immediately we have more

1:00:05

diversity because there's more viewpoints represented. Yeah.

1:00:10

Oh, now I'm thinking about AI plus design systems.

1:00:13

That's such a combination, right? If you had Infigma, like you have your little...

1:00:18

I've seen some.

1:00:19

Some people are working on some.

1:00:20

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

1:00:25

That would be kind of nice. Just write a little text. Make all the buttons we need.

1:00:30

And here we go. Yeah. You could also teach, as you said, a design idea or a

1:00:37

principle or a certain approach and then just see a hundred variations of that.

1:00:43

I think that's exciting. Cool. So I'm glad there's a positive spin to my slight doubt at the end.

1:00:54

But I think there is an interesting tension there. And it's what I also want to keep exploring.

1:01:00

Like how can we make work that lasts and is really like professional and solves

1:01:06

people's problems, but also still

1:01:08

keep things exciting and inspiring and provoking also sometimes, right?

1:01:13

So I think that's the the eternal design tension that we all have to deal with.

1:01:18

Wonderful. I think that was a great conversation.

1:01:22

I hope we didn't confuse you all with our design system nerd talk.

1:01:29

We'll put a few links in the show notes to the examples we discussed, a few resources.

1:01:34

And yeah, maybe we can do a follow-up episode on AI plus design systems now

1:01:39

that we're all excited about. Yeah. In the meantime, thanks for joining me and see you soon.

1:01:47

Thank you, Moritz. Bye-bye. Hey, folks. Thanks for listening to Data Stories again.

1:01:56

Before you leave a few last notes, this show is crowdfunded and you can support

1:02:00

us on Patreon at patreon.com slash data stories, where we publish monthly previews

1:02:06

of upcoming episodes for our supporters. Or you can also send us a one-time donation via PayPal at paypal.me slash data stories.

1:02:15

Or as a free way to support the show, if you can spend a couple of minutes rating

1:02:19

us on iTunes that would be very helpful as well.

1:02:23

And here's some information on the many ways you can get news directly from

1:02:26

us. We are on Twitter, Facebook and Instagram, so follow us there for the latest updates.

1:02:32

We have also a Slack channel where you can chat with us directly.

1:02:36

And to sign up, go to our own page at datastory.es and there you'll find a button

1:02:42

at the bottom of the page.

1:02:43

And there you can also subscribe to our email newsletter if you want to get

1:02:47

news directly into your inbox and be notified whenever we publish a new episode.

1:02:51

That's right! And we love to get in touch with our listeners,

1:02:54

so let us know if you want to suggest a way to improve the show or know any

1:02:58

amazing people you want us to invite or even have any project you want us to talk about.

1:03:04

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