Stuck? Diagrams Help (feat. Abby Covert)

Abby Covert discusses her book Stuck? Diagrams Help.

Sponsored by Watch City Research
Watch City Research is your trusted UX research partner

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Dan Berlin: 0:13

Hi, everyone, and welcome to another episode of the 97 UX Things podcast. Dan Berlin here, your host and book editor. I'm joined this week by Abby Covert, who will be talking about Stuck? Diagrams Help. Welcome, Abby.

Abby Covert: 0:26

Hi, thanks so much for having me.

Dan Berlin: 0:28

Thanks for joining the podcast. Can you please tell us a little bit about yourself?

Abby Covert: 0:32

Sure. My name is Abby Covert. I'm an information architect and an author. I live in Melbourne, Florida. I got my start working in information architecture through consulting. Then, I did some time in agency. I went out into independent consulting for a while. I went back into it in enterprise. And now, I'm back out as an independent author. So, I've been doing this kind of work for two decades now. Information architecture is the focus of my work, as well as the focus of my writing. Most recently, I wrote a book called Stuck? Diagrams Help, which we're going to be talking about today. I also wrote a book called How to Make Sense of Any Mess, which is an information-architecture-for-everybody book.

Dan Berlin: 1:13

Cool. Sounds like a very varied career path there. Can you dig in to that a little bit for us? How did you discover information architecture? And how did you wind up where you are today?

Abby Covert: 1:26

I went to undergraduate for graphic design. About two years into that program, we started to be introduced to a concept called information architecture. At that point, this was a print design concept, like we were designing things to be printed out. We were talking about the hierarchy on a page. We were talking about meaning of shapes, images, and words - and how we could get across the meaning of an intention with just those elements. But about two years in, I was also introduced to what they were calling"multimedia studies". At that point, it was starting to get into digital interfaces. So, I was recruited for that program and became the designer on a team working on a video game. Coming out of that program, I was really interested in tech. But to be honest, I was still looking for a print design job. My very first job out of school, I got this job designing an icon set for banking software in Bermuda. I found it on Craigslist, and it was as sketchy as that sounds. So, this was a really weird assignment. They sent me like a list of verbs, like print, save, create- those kinds of things. I just made icons to the standard. They all looked great on a page together. I never even saw the interface, Dan. It was really embarrassing. So, they wanted these icons. I had to drive the working files up to an office of this consultancy, that was doing this work. I had to drive it because we couldn't email it at that point. It had to be transported on a Jaz drive. So, it required a rental car. So, I got up there. I gave him my icons. They put them in the interface, right? Because they were going to show them off. It was horrifying. Just like, "Wow, this is not what you should do". The rest of the interface was a total disaster visually. But also, they were planning on putting these icons there with was no labels. They hadn't told me to work the labels into the icons. So I was like, "Yeah, this is a bad idea". They were like, "Well, why?" I'm like,"Because it's software. You have 18 things here. You can't just put them in a bar across the top and expect people are gonna know what they are. I'm a good icon designer, but nobody is that good. That's just bad." They were like, "Do you know what information architecture is?" I was like, "Yeah, duh. I'm a graphic designer. Of course, I know what that is." They were like, "Well, do you know how to do that for software?" I'm like,"What do you mean?" The guy that I was having a meeting with, gave me like a copy of the polar bear book from his office. He just was like, "Hey, you should like look into this. If this is a thing you're interested in, let us know because we need this. So, I went to Barnes and Noble and bought my own copy. I read it. I was like, holy crap. This is exactly the parts of graphic design that I really like - and exactly the parts of digital design that I really like, merged. Right? So, it became this interest of mine. Then, I ended up being hired by that same company as a junior information architect. So from there, I just went job to job and figured out what that meant along the way.

Dan Berlin: 4:33

Sounds like you did have that serendipitous moment, as a lot of us do in this field- where there was someone who introduced you to it. It sounds like you got really lucky there, in terms of finding that person and this company, who had the foresight to read information architecture.

Abby Covert: 4:48

Yeah. It was so interesting, because that was 2004. So, it was a couple years into the community of information architects, starting to meet and form as groups. So, there was a lot of discourse online. There were a couple of conferences. There were mailing lists. So, there was a lot for somebody like me to reference; I was able to go to Boxes and Arrows, and learn how to write a controlled vocabulary and how to think about taxonomies. I didn't know any of that stuff from my design degree. So, I had to pick up the information-science side through the community and through the literature, which has been a really interesting path for me as well.

Dan Berlin: 5:28

Do you remember how you first approached that initial problem? So, now you had this bar of icons. What's the next step there? How do you approach that?

Abby Covert: 5:38

It's interesting. Because myself as a designer, at that point, wanted to have an immediate solution. So, I was like, give me a whiteboard and a marker. I'm going to show you right now. Let's put together a menu. I made a two-tiered menu system, with an adequate number of options at the top and at the secondary levels. That's what anybody would do if they were trying to solve that problem. What I didn't do is say, "Well, I would really have to know more about this, in order to recommend something." That would take me a couple of years to really get the sense - that was part of my job too: to get validation from the users of the thing. It seems really strange now, because I feel like I've helped a lot of organizations go on the journey to become user-centered. But I think it's really important for us to remember that we all have to go on that journey ourselves; becoming user-centered in your design practice. It's something that all of us have to learn. The earlier you learn it, the better for your trajectory

Dan Berlin: 6:39

100% on this same trajectory that the industry took. It went from "best practices" to incorporating"best practices with what users actually want/need" - actually talking to users.

Abby Covert: 6:54

Yeah, exactly. Then, we got data. We were like, "wow, we can actually look at what happens. I know what happened as a result of what we did." Pew. Rocketships.

Dan Berlin: 7:05

So, thank you. Thank you for that. Thank you for sharing your journey there. Tell us about your book, Stuck? Diagrams Help. Tell us about that, please.

Abby Covert: 7:15

As a teacher of information architecture (IA), one of the easiest-to-grasp mediums of practicing IA is in diagrams. When people see diagrams, they inherently feel like "okay, I get that thing". But after years of teaching diagrams, I really started to realize that people were not quite sure how to make diagrams. The best way to be taught to make them seems to be give-them-a-template type of diagram. Have them fill in the template for their current context. The problem with that is not all of the diagram types apply to all contexts. Often, it becomes a limitation based on your toolset. You only know about three types of diagrams. So, all problems look like those three types of diagrams. So, I really started to think for my own students about, how do I really introduce diagramming as a practice? Also, is there other places where that's done? Because diagrams are everywhere. They're in the medical field for diagnosing things. They're in the design field for planning things. They're in the technical field for planning and discussing things. You see them in teaching. You see them in law. You see them in technical illustration. There's all sorts of places where they are helpful objects to get a point across. But how do you actually learn outside one of those contexts to create a diagram? That was ultimately what created the idea for writing a book about it. My first book touched on diagrams and provided these 10 examples. All based around the simple concept of pizza. It broke down pizza in 10 different ways, showing different types of diagrams. People love the pizza diagrams. But they would also say things like, "but how do I make my own one of these?" That was giving them templates. So, I started to do research in late 2021, about what exactly makes up a diagram? What's the salient definition that is across all of those contexts? What I came to is that a diagram is any visual representation that helps someone. By that definition, so many things fall under that umbrella. But it really allowed me to go wide with the application of this idea. So, I started collecting stories, examples, and academic sources. I brought on a research librarian to help me dig into that next level. Jenny Benevento, shout out. We just started to really uncover all of these amazing layers. There are some universal things that we can agree about what makes diagrams effective - understanding who your audience is, understanding the intention that you have for the actual diagram, understanding the scope that makes sense for that diagram, picking the right scale for the medium that you're going to put that diagram in. Then, doing the actual diagram part - deciding what shapes make sense, deciding how to use lines, deciding what the labels are gonna end up being. Then, ultimately, what are you packaging that in? How are you making that a thing that is then delivered to your audience? That journey is a really interesting one to take people through. To slow down time, right? Because a lot of diagramming happens in the mind. Then, when it gets to the paper, it's sort of already done. So, leading people through that whole thought process is a big part of the book.

Dan Berlin: 10:43

I imagine there's a continuum of what constitutes a diagram. I'm thinking about what you said at the beginning about icons. Icons almost seem like they are a diagram. Then the other end, there's a full on infographic. Is there a continuum? How does that definition of a diagram work?

Abby Covert: 11:03

I think that if it is a representation that helps someone, then it is diagrammatic. If you're providing an icon that is so clear, that it is projecting the meaning of what the thing is - I would say that it is playing that part. It's also playing the part potentially of an interface, right? Those things can be one of the same. I think that that brings diagrams to a level where they're not just things that look like boxes and arrows. That's a really important point, like maps of the world are diagrams. There's some of our first diagrams are maps of the world, cave paintings that they've recently discovered that early humans were tracking the ovulation cycles of animals, all these crazy things about birth patterns. They were using those drawings diagrammatically to communicate information to help one another. So, I think that diagrams are one of those things, similar to information architecture, that existed without a label for a really long time. Now that we have a label for it, it's on us to decide how to teach other people about it. I've been really lucky to see a lot of people have the light bulb about what diagrams can do. Often, the part that I like the most is weeks later, when they come back; they're like, "Oh, my gosh. I made a diagram, and it really did help." Because we've all had that stuck feeling right? Back to the title of the book, STUCK is actually an acronym. It's an acronym for what I think the superpowers of diagrams are. So, they provide "stability", right? They can be very volatile out there. Diagrams really can give us a place that we can kind of land. It can be about"transparency", right? When we're looking at information visualizations, it's often about transparency. It's about providing a transparency to a dataset that, otherwise, would be hidden to us. Because it's in a medium that we don't understand. There's things for which "understanding" is really the center of the diagram, right? We're explaining something to somebody when we're educating them or teaching them."C" is for clarity. So, there's some concepts that, without pictures, are just inherently more difficult to teach. Imagine teaching somebody about a human-body makeup without a picture. Imagine teaching somebody to play chess without a picture. It's just not easy, right? Then, the "K" is for kindness. Because I think that, ultimately, diagrams provide a really kind respite from the complexity, ambiguity, volatility, and uncertainty that drives the need for diagrams, right? It's like a place that we can put our thoughts, so that they won't get lost. It's a common page for us all to get on. It's an amazing collaborative tool. But it's also an amazing tool for introspection and use for yourself. One of the core things about the definition of diagrams is that it helps someone. I try to remind the reader many times that someone can be you - just you is enough for the audience of a diagram. That frees us from what the medium has to be. Or how formed it has to be. Or how beautiful it has to be. Or how well designed. It's really just about the helpfulness. That determines whether or not something's a diagram.

Dan Berlin: 14:23

You bring up an insertion point I had never thought about - in the kindness part, in terms of how diagrams can bring communities together. In particular, one that comes to mind is the double diamond, which we've been talking about for years in UX. It's that visualization. It's that diagram that has done such a wonderful job of explaining UX processes to others. I feel like it has brought our community together and expanded the community to others outside of UX.

Abby Covert: 14:52

I would say that most professional practices have frameworks, where diagrams are the star of the show. Yeah, It's just it's a very common wisdom to make things visual. I think a lot of people shy away from diagrams. Because maybe they're not like design minded, or they're not visual people, or they can't draw. Those are all reasons that I've heard. But I think the simple fact is that they're still helpful. Even in their most crude form. Even in their most like messy form. They can still just be really helpful objects of discourse. And I think a lot of professional fields have benefited from that.

Dan Berlin: 15:30

So how do we make amazing diagrams to help us get unstuck?

Abby Covert: 15:35

A big part of it is understanding that there is a lot of thinking to do before a diagram is effectively made. So, one of the points that I think is really important to bring up early is that - if you just start making something with boxes and arrows, you're going to struggle. You're going to feel even more stuck, because you haven't actually identified what it is you're trying to do. What also happens is that diagrams kind of sneak up on people. They're thinking about a thing, working through a thing, really agonizing on a thing. Then, the next thing you know, there's a note card out on their desk. They're scribbling some shapes. They're like, "Oh my gosh. I finally figured this thing out." So, I feel like I'm acknowledging that both of those circumstances are still on the same process - you are picking why you are diagramming, and you have an intention behind it. You know who you're diagramming, what you're diagramming, and the scale at which you're doing that. All of that is going to massively improve your ability to make those shapes and lines mean anything at all. A lot of people get stuck. They get stuck in their head with the first part of like, "Oh my gosh. I have to think about the audience. I have to think about the scope I have to do." It's like they don't allow themselves to be messy in that beginning part. So, I think that that's a big part of is like figuring out how to acknowledge that non-visual part of the diagrams. On the cover of the book is a venn of two circles. One says"Visually represented". The other one says, "Helps someone". The visual part is only 50% of the diagrams magic. That isn't crucial part of the process. It's acknowledging that other side - who does it help? How does it help them? And being really dog, it's not just about that in the coming up with the idea for the diagram and the execution of it. But also, in the testing of it. I think the diagrams are interfaces, just like anything else that deserve attention from a research standpoint. If you can't have a member of your audience describe your diagram back to you, and have them get it like 80% right- it's not good enough yet. It's just not so. So, it's acknowledging all of the other stuff behind the diagram, as well as improving the basic craft of the visual part. But honestly, once you get through the people part and the scope part, the shapes and lines is kind of easy part, to be honest. There's some patterns that are outlined in the book and some recipes that you can rely on when you get to that part. But a lot of it is actually preparing the reader to be in that uncertainty - of figuring out who their audience is, what their scope is, and how they're going to scale that for their intention.

Dan Berlin: 18:14

Embracing uncertainty is just huge in UX and IA in general, right? Yes, it's that image that comes to mind of the fuzzy front end of design. That's all messy and squiggly. That eventually smooths out over time. It sounds like diagrams take that to heart, and its own little subsystem.

Abby Covert: 18:34

I think diagrams can be useful at pretty much any of the points in the design process, right? Because you could be using diagrams at the beginning to do discovery work. You could be using diagrams along the way to work out back-end, and front-end details. Then, you can be using diagrams at the very end, actually explaining concepts to your end user potentially. So, there's the end, there's different audiences for all of those diagrams. The expectation that you would make one diagram to serve all of those audiences is also not going to work, just like any other interface. Right? So, I think that there's a lot of wisdom that user-centered professionals can already apply to diagramming. It's like some people come to it with the visual side, and you have to remind them about the people side. Then, some people come with the people side, and you got to remind them about the visual side. So I think, ideally, the book does both.

Dan Berlin: 19:23

For folks like me, who are researchers who need help on that visual side - it sounds like that would be a great use. So, thanks for that. What else were you hoping to convey here today about diagrams and your book?

Abby Covert: 19:34

I think that there's sort of a myth out there; that all of the diagram types have already been created. In that, we should be spending our valuable professional time trying to find the example to emulate, right? Trying to find not only an example, but one that's actually been shared openly, which is an even smaller pool. So, one of the things that I really used every opportunity that I get a microphone to tell people - it's just that we're very early in. All of these industries that are working themselves out. Diagrams are the core product of a lot of that work. They're changing over time. The one that is sort of like the diagram du jour that morphs over time, too. So my biggest piece of diagrammatic advice, in terms of learning, is to jump in and learn the practice of it. Start to make your own types of diagrams. Start to mash things up for your unique context. But be really dogged about that user side. Don't be inventing things in your Batcave that you think are a good idea to mash up different diagram types. It's really just showing off how much you understand a really complex thing. Figure out actual practical uses for diagrams. Then, find unique forms, just like interfaces. I think there's times where we should be using patterns and design systems, for consistency, efficiency, and all these things. But there's also times where we do come up on a unique design need. I think people have to be reminded of that in the diagram circumstance. Because we want our hero diagrams to always work, but they just don't. I've made, I estimated, over 1000 diagrams in my career. I am telling you, most of them do not adhere to being categorized as one specific type. That you could just be like, "Yep. That's definitely just that." There's always like a little thing, right? Like I'll be making a sitemap, for example. That's mostly a hierarchy, but this one part needs a bit of a flow. So, I'm going to put it in there. That's more useful for the audience that I have, than breaking those two things up. Because one is supposed to be a flow diagram, and one is supposed to be a hierarchy diagram. So, I think that that's the permission that people need. I am here. I am on this podcast, and I am giving it to you.

Dan Berlin: 22:00

Nice, nice. Well, I mean, it's a matter of what works for the audience, right? Same example goes for service design, where we have journey maps, service blueprints and ecosystem. They don't have to be separate. They can be one document if it works for the audience.

Abby Covert: 22:17

Exactly, exactly. If you need to change the labels of those frameworks to work with your context, or your audience - that's fine, too. One of the things that I think, as an information architect, was the hardest for me to write about in the book was labels - like the just the role of words, in general in diagrams. The reason was because I had to acknowledge how fundamental the "word" part is. But also, how bad we are at it at the beginning of our process. We are so fumbly about what we call things when we first start exploring them diagrammatically - that if we don't acknowledge that our labels are sort of placeholders, we can get stuck in them, right? Then, they can just become the label because everybody looked at the diagram so long, they convince themselves that the label makes sense. So, actually lay out kind of three phases that I think labels go through. Because at the very beginning, you're kind of just clunky getting through it. But in the middle, you want to start making sense to people; you want to start to iron things out. At the very end, that's when everybody comes out of the woodwork - "I gotta change this. You got to change that. That label doesn't make sense." So, labels are just what a fascinating subject. They also happen to be the thing that other people give a crap about in a diagram. I don't know why they never care about shapes. They don't care about lines. But goodness me, a label; that will get the attention every single time. That's where all of the feedback in a diagram is.

Dan Berlin: 23:39

Well, Abby. You've given us a lot of great information here today about diagrams and how they can help people's work here. So, thank you for all of that. The final portion here, we'd like getting a "Career Tip" for folks in UX and AI. What career tip can you convey?

Abby Covert: 23:55

Okay, I thought really hard about this. Because there was a lot of potential options. But I think I want to go with network with your peers. I know that network is a very common - like, go network. Whatever. But I think that sometimes when we go to network, we try to can like connect with people that have achieved things, that we want to eventually achieve. We're sort of doing the pick-my-brain request. I think that those can be really effective for a fact finding mission about career paths. Or making some high-level connections in an industry. But I think there's this other thing about peership that I'm just really interested in. I feel like over the years, most of my guidance in my career has come from these peerships that I've developed with other people - that are going through the same thing as me at the same time. I've just found so much long term value in those relationships. But I wonder since I'm not currently building that network anymore, are people being told that part that. It is valuable to meet with people that are doing the same thing as you. Not like already got the job, or already wrote that book, or already speaks at the conference like you. There's a lot of value. Not only in meeting people that are doing the same thing as you and talking about it, but also growing that network. Knowing those people as they grow in their careers. Because guess what, those are the people that are gonna go off, write the books, go to the conferences, start the companies, and maybe hire you for your dream job. So, I feel like that's something that maybe also goes in the permission-needed category, because it gets weird. Making adult friends is hard. Making them outside of the workforce is even harder. If you're going to a conference this season, or you're like in a Slack group or something like that - put yourself out there. Have a coffee date with somebody who seems like you, in terms of what they're doing with their career, with their life. Pick each other's brains, figure out how you can help each other. Because I think that that's really valuable stuff.

Dan Berlin: 26:01

No, it totally is. Honestly, I've never heard that piece of advice before, where it's okay networking. You're always talking to the folks who are going to hire you. But what about learning from all the people around you? And the pitfalls that they ran into? And sharing your pitfalls? That's very cool. Thanks for that.

Abby Covert: 26:17

Thank you for the venue to share that. Yeah, no problem.

Dan Berlin: 26:20

So, my guest today has been Abby Covert, who has been chatting about Stuck? Diagrams Help. Thanks for joining me today, Abby.

Abby Covert: 26:28

Thank you so much.

Dan Berlin: 26:30

We hope you enjoyed this podcast episode. Thanks for listening, everyone. You've been listening to the 97 UX Things podcast - a companion to the book 97 Things Every UX Practitioner Should Know published by O'Reilly, and available at your local bookshop. All book royalties go to UX nonprofits, as well any funds raised by this podcast. The theme music is "Moisturize the Situation" by Consider the Source. I'm your host and book editor, Dan Berlin. Please remember to find the needs in your community, and fill them with your best work. Thanks for listening.