Articulating design decisions with Tom Greever
A transcript of Episode 119 of UX Podcast. James Royal-Lawson, Per Axbom and Christopher McCann talk to Tom Greever about how to discuss our designs effectively with stakeholders.
James: Hello to you all. This is UX Podcast, hosted by me James Royal-Lawson.
Per: And me Per Axbom.
Chris: With bonus track from Christopher McCann.
James: We’re balancing business, technology and users every other Friday from Stockholm, Sweden.
Per: So what are we doing today? We are doing an interview and the reason actually Chris is here with us is because he wanted to join us when we’re talking to Tom Greever, author of Articulating Design Decisions.
James: Yeah. It’s a book that came out in the autumn. We’ve all been reading a bit of his book but Chris is actually the one — the three of us — he has read it the most. He has already read it before and works in-house at EpiServer.
Chris: Right. I work in-house at EpiServer.
James: UX Lead? What do you call …
Chris: UX Lead. I don’t know. It’s under debate actually at the moment. I want to be called UX Director but they won’t give me that one yet. So it’s — I lead a team in a product development organisation that works with UX. Yeah, I read the book. I got a lot out of the book. It really resonated with me. I felt it was — almost I could have written the book and some of the bits of it anyway. I was really impressed by Tom’s writing style mostly and I thought it was really approachable.
So when they said they were going to do a podcast, I said, “Well, I want to join with that. That sounds like fun.”
James: I think it’s really nice to have you here and it’s really nice to have someone who’s in-house and working from a different angle with this kind of question, articulating design decisions and also working with teams, compared to me and Per who are consultants and have a different — well, working week.
Chris: Yeah. I mean I approached it from establishing UX culture. I view articulation as really good for that as well as part of leadership, which I find myself being thrown into more and more, being in the role that I have today. So from those two angles or the filters, I read the book and got a lot out of it.
James: Hello and welcome to the podcast Tom.
Tom: Thank you. Thank you for having me.
James: Why don’t you tell the listeners a little bit about yourself and what you’ve written?
I’ve found in my career that that can be a big problem for designers is getting approval for their designs. So I kind of look back on my career and tried to sort of synthesise all of these things into a coherent timeline in the hopes of helping other people overcome some of the things that I’ve had to overcome in my time working in design.
Per: I think the topic of your book is really well-kneaded and it really struck a chord with me because just recently, I read a blog post, one of the big user interface or UX agencies in Sweden where — talking to their employees about how would you describe UX to someone else. It really amazed me about how they could not do it, how they always struggled to explain what UX is, what UX design is and they were reaching and thinking about things.
Well, I make stuff easy to use. But none of them were explaining what the benefit was to the customer, which really amazed me. What you’re discussing in your book is that gap between designers and stakeholders and how really crapped basically we are at describing what we do. So there is a need and I think you’ve done a really good job of describing what the next step has to be when you go up that level and become a more senior designer.
James: I think all of us as well have been in that situation where we have meetings and presentations where we think we’ve lost — to put it in blunt terms. You felt like you were going into a meeting with a really good idea, really good solution and then you come out with the complete opposite.
Chris: Well, and it’s complicated by the fact that not only do we have a hard time explaining to other people what UX is. But even if you were able to come up with a succinct response that demonstrates the important of UX and organisations, most people — I mean everyone has a different answer about that. There are all these discussions about UX and UI and interaction and then you throw in content strategy and information architecture and it gets very confusing to people who don’t work in our field and yet those are the people who are writing our checks. Those are the people that we need to approve our stuff.
If we can’t help them understand what we do, why it’s valuable, then we’re not going to get anywhere. We’re not going to be successful at creating a great user experience because they’re going to override us and they’re going to force us to make a change that we disagree with that could be a lesser experience for the end user and the people using our products.
Chris: Yeah. I think that’s a good point. When I read the book, I was — I had a lot of this “aha” moments. I mean I’ve been doing the sort of thing even when — and from school when I studied architecture because it was the same sorts of things and being able to explain why you did what you did in a way that people can understand. That sort of strips away all this sort of vernacular — this jargon that you use for design. It’s the key to being able to — to do a couple of things. For me, I’m working in-house. So it’s part of building a culture.
If they can understand why you do what you do, and how you made a decision, it opens up the process and makes it more accessible. So they don’t — maybe don’t ask that same question the next time. So I’ve been looking at it from a culture leadership perspective and being able to communicate things well is critical if you’re working with UX in an organisation.
So I got a lot out of it. I thought the book was really good and spot-on and a lot of good insights. Before this, I started to look at some of my highlights from my Kindle and I am looking at a couple of these, some of these great quotes that you have here Tom, and I’m going to probably steal and reuse it on a later date.
Tom: Yeah, please.
Chris: It was a really good book and I think it also blends in — because I read two books at the same time. I read this book and I read the critique book by …
Tom: Discussing Design.
Chris: Discussing Design. Both of these books I felt complimented one another in some ways. They kind of approached the discussion of design from two different angles and they really worked really well together. Do you have any thoughts about how these two books work together or did you — I’ve seen on Twitter that you and — I think it’s Aaron have had some …
Tom: Aaron and Adam. Yeah.
Chris: Adam, sorry. Have had some kind of connections there.
Tom: Yeah. I know Aaron and Adam and their book Discussing Design is also published through O’Reilly and we were both working on our books around the same time and they were released within just a few months of each other. It’s interesting to see different perspectives on this topic and their book, I would highly recommend it.
You’re right. A lot of people have told us that they pair really well together. But they come at it from kind of different angles. I think the thrust of their book is that when you’re on a design team, one of the most important things is that you have a set of common vocabulary, that you have these ground rules for how we’re going to critique each other’s work and here’s what’s effective and here’s what’s not.
This is how our team works together and they have a lot of really great frameworks and exercises you can go through with your design team for making that time together effective.
I’m coming from the angle that you probably also have other people outside your design team. Probably executives but people who don’t respect or value those same design principles and those exercises. In my experience, the CEO doesn’t care about your rules. He doesn’t care about your vocabulary. He just wants to come in and tell you what he thinks should be done. Your job is to respond in the moment and come up with a way of bringing him over to your side and seeing your perspective and helping him understand the logic behind your design decisions, so that he won’t overrule you.
I think both books have value in different ways. I would highly recommend reading both of them together. Maybe even at the same time for sure.
James: I think there was an example in the book or is it — you talked about the CEO thing and you had a story about the CEO who was I think prodding you in a certain way during a meeting and he wasn’t really interested in what the outcome was. He was just building. He wants to know he could trust you.
Tom: Yeah, and I think that happens a lot. People, executives, maybe they see something. You’re not going to be able to stop someone from providing you feedback in the moment, right? Even if you sort of have these established ground rules. If the CEO sees something that he thinks is out of line, he’s going to point it out. In the example that you’re referencing James, that CEO was kind of nitpicking on a very small — it was like a filter menu and he was making some specific changes about kind of the size and the way it was placed. Just this really small like UI details and I felt like it was — I could tell it was misplaced for someone at his level.
That’s not why we were there to meet. He just noticed this one thing on the view we were showing him and he decided to obsess over it. He was distracted by it and distractions are a huge problem. I talked about how to avoid distractions in-depth in the book. But in that particular case, all I said to him was I completely agree with you that we need to find a solution for this UI control.
Something in that statement, I was agreeing with him that there was a problem to be solved. I was reinforcing that I listened to him and I heard what he was saying. It’s like a light bulb went off and he just — he almost immediately just stopped and said, “OK, great. I trust you guys to come up with the right solution.”
It’s like I reminded him that we could be trusted with those things and he didn’t have to go on and on about such small nitpicky things that really didn’t matter.
James: You onboarded him into your team.
Per: And the fact that he said yes.
Chris: Well, you all talk about the — leading with yes and then using that as your opening and then working with the improvisational theatre and all these things. So I recognise that example in that …
Tom: Yeah, the “lead with the yes” in the book, I get more great feedback from people on that section of the book probably than anything else. So I guess if you take anything away from the book, the one thing you should take away is this concept of leading with a yes and a lot of us are familiar with the idea of the yes and in improv, in comedy, what one actor brings to the other. They have to say yes to each other because if you say no, if an actor comes to another and says, “Hey, you want to go to the grocery store,” and the other guy says, “No, I don’t think so,” well, curtain close. The sketch is over.
There’s nowhere for that conversation to go and the same is true in our conversations about design. We have to be able to lead with a yes even if we disagree. Yes, I see your point. Yes, that’s a great perspective. Yes, thank you for bringing that to our attention. We will work on that. Sometimes just staying positive and reminding everyone we’re all on the same team. We’re going in the same direction. We have the same goals. That’s really, really effective at helping people see our perspective and allow us to lead and make choices that are important for the UI.
James: When you’ve got those opposing opinions or opposing issues that come up in a meeting, you can take them and reply back almost in a way that builds — starts with a hypothesis. So you take what they’re saying and you say, “OK. So that means you’re saying — you think that this will then lead to that.”
James: So you can then lead into, “Shall we try that?” But you’ve worked through it with them in a more controlled manner rather than just kind of …
Per: I think that’s a concept that relates to that. You had it in your book as well that when people say something like, “I don’t like the colour of this button,” you say, “So what I hear you’re saying is if people want to schedule a meeting, that they may have a tough time based on the design of that button. Am I hearing you correctly?” So you’re again confirming that person and hearing them and saying that you understand them and you’re willing to meet or — yeah, do something about what they’re seeing.
James: Yeah. You’re transforming it into something that would be more workable or more actionable.
Tom: Yeah. In the book, I call that converting likes into works, right. So when people say that they like something, that’s too subjective. We have to move away from that. So we can repeat it back to them as you noted Per by saying, “OK, what I hear you saying is you don’t like the colour of this button.” But why doesn’t it work to have the button be this colour? Right.
When you do it that way, you allow them the opportunity to talk about the function and the usability of that request as opposed to what just our personal preferences are because we’re not as concerned about their personal preferences as much as we are the usability and effectiveness of our designs.
That’s a really effective way I think of helping people kind of see that what they’re expressing and the change they’re asking us to make is maybe just a personal preference. Sometimes people will catch themselves and be like, “Oh, well, no. I just …” It works just fine for that button to be this colour.
Chris: Well, I think that’s interesting because it — to me, doing it that way also introduces the real goal of design which is to solve a problem. If you word it in a set of terms that says, OK, how — you know, the colour. OK. If our goal is to increase conversions or to do something, I will say — and to bring it back to that discussion, I think it’s a lot more valuable because people start to realise that, OK, this design stuff, it’s not about the colours. It’s not about I don’t like blue. I don’t like red. It’s about what that blue and red will actually do towards this solution.
So I’ve used that same technique as sort of a — again, a communication and cultural — as an educational tool more than anything because you can say that, “Oh, no. UX design, it’s not about the colours.” You can say that like a hundred times. But it’s not until you say — not until you sort of weave that into a problem that the business wants to solve. Someone says, “Ah, now I get it. I understand the colours and the solving of the problem.”
Tom: I think that’s an important point because it doesn’t matter how often — I mean we have these conflated terms now like UX and we have all these fancy titles that we’re trying to help people understand like we talked about earlier in the show. But what happens is people still think that design is all about just what looks good or what I like or what I don’t like.
No matter — like you said, no matter how many times you say it and we need to bring that stuff to the forefront. In the book, I talk about appealing to a nobler motive which is what you made reference to in like solving a problem. We almost always have these goals or these problems we’re trying to solve and so our job is not just to just take their feedback and kind of swallow it, but instead to like rephrase these things in the context of that problem.
We can appeal to those nobler motives by pointing at those goals and saying, “Hey, if our goal is to increase conversion, then changing this button colour is going to negatively affect that.” We’re not very good at doing that. I mean oftentimes we say, “OK. I mean if you think blue will work better, maybe we will run an A-B test,” right?
That’s also an appropriate way of like trying to figure out which one works better. But I think we need to point to those goals more often and by the way, appealing to a nobler motive, that phrase, that word is — it’s a principle of communication that come from Dale Carnegie’s book How to Win Friends and Influence People.
I find that it’s especially effective in design because we always have those motives. We just need to bring them to the forefront and allow people to see that that’s what we’re designing for. We’re not designing only for an aesthetic or for our personal preferences, but also to achieve those goals and solve those problems.
James: Also in the book, you talk about the importance of understanding who you’re going to be — well, your target audience, who you’re going to be talking to. Who’s going to be — who are your stakeholders that you’re going to be presenting to and being able to understand where they’re coming from, their angle, their take on it. How would you go about getting or gaining that knowledge or information before you walk into the room and start talking?
Tom: Well, it’s really, really hard no doubt. I mean it requires a lot of social skill and just being able to very quickly size people up. I mean if we’re talking about people that you’ve never met with before, then you just have to be really flexible and you have to go with that. A lot of it has to do just with listening and talking less, allowing them the opportunity to talk.
I always suggest letting people talk as much as they want without interrupting them, because it’s really important that they know we’re listening, that they feel like they were able to express themselves well. And believe me, it — because sometimes people will repeat themselves over and over again. That can seem annoying but usually when they do that, they’re trying to find a better way to say it because remember, they’re not — they may not be designers, right? They may not know how to tell us what they need or want.
So if there’s a better way for them to explain the problem I was trying to solve or to explain their request to us, we want to hear that and we want to allow them the opportunity to talk. I always tell people to even pause for two or three seconds after they’re done, right? To allow them — to make sure that they’re done talking, right? You don’t want to just jump into this defensive posture and respond immediately. You want to give it time. You want to let their words kind of sit on everybody’s ears. It gives you a couple of seconds to process it before you jump into a response.
But honestly, once you’ve met with someone, even just a few times, it gets much, much easier to know what to expect. A lot of people are going to respond to our work in similar or the same ways every single time, right? Their role, their job on our team affects their perspective. The more we can do to kind of think about, OK, this is a developer type or this is an executive type or this is an accounting person, right? We can think about how their role affects their perspective, right?
A project manager is probably only really going to care about the deadlines and when it’s going to be done. So we don’t need to focus on the details of why this — what we’re working on. We just need to focus on getting to the point of, “Well, if we do this, it’s going to take longer,” right?
We want to appeal to the things that you know are important to those people. It gets easier with time.
Per: As a student of coaching now, what I’m reading into that chapter when you’re talking about that, that is — you’re actually coaching people into describing their real problem in a better way. So you’re actually trying to uncover what the real problem is.
Tom: That’s right. We become facilitators in a discussion about design with people that don’t know how to talk about design, right? I think if we see that as our role, it becomes a lot easier to jump into that meeting and be effective. The problem is that we don’t always see ourselves in that role. We see ourselves as being there to receive feedback from them.
Then when we don’t like the feedback, we get defensive and we argue with them and we try to tell them why that’s a bad idea, right? If you think of yourself as more of a facilitator of discussion, then it becomes –just that mental shift, that simple mental shift can help you I think bridge that gap.
Per: There was one section of your book that I found really intriguing. It was when you were talking about — and this relates also of course to how other people understand design is when you were talking about describing your design in words only because that’s something I don’t think a lot of designers spend time on.
It’s something that Nicole Fenton talked about at UXLx last year when she was talking about interface writing or words as material where you’re actually trying to describe what you’re doing, but just in words, because that makes you think about, “Well, how does this sound like to other people?” But I can confess to that. I rarely do this or basically never.
James: Well, it’s very challenging to do completely, solely by words. Yeah.
Tom: Yeah. Well, when we’re talking about a medium that is mostly visual, it becomes difficult to describe to someone. So the tactic in the book or the practice in the book is meant to help you understand the rationale behind your decisions because I think that’s an important step. It’s hard to explain your decision to someone else if you don’t yourself understand why you made that decision.
As visual people and as people building visual interfaces, we may build that and we make these unconscious choices but we don’t always know why. So that’s meant to help you kind of connect those dots, right? If I can write down why I did what I did or if I can describe the interface to someone else who doesn’t have the ability to see it, that’s going to help me uncover my own thinking.
James: I guess you also need to be better at keeping track of what you’ve done on the way.
Tom: Absolutely. You have to do it throughout the process. Yeah. You can’t wait until five minutes before a meeting. You got to — we have to be in the habit of connecting those dots all throughout the process when you’re designing …
James: …Annotating your design work.
Chris: You wrote a good blog post about this, I remember, about documenting your design decisions, which I thought was really good. I think maybe that’s how I first got a hold of your name because it just — about six months before that, I started — I worked on a product, worked with a team and I realised that we were making design decisions every day. I realised that over time, I was forgetting what these were. We would work really quickly in a team. We would have discussions. Does it fulfil the goal? Yes, no. How are we going to do that?
We’re making all these decisions and then half a year later, I will look back and say — someone would say, “Why do we do that?” and I could sort of kind of reconstruct some kind of great thing after the fact. But I realised that that was probably not the best way to do it.
So I started creating a designs decision log which I have as a document and most of these — most of these decisions — I usually try to be practical on most of the big decisions. I write down and say what the decision wants, why we did it, who made it and so you have some kind of — you have some kind of track record of what — how you made your decisions and why you made them. But I think that blends really well into what you’re talking about Tom.
Tom: It does, yeah. Writing those things down is critical because like you said — I mean I’ve been in dozens of those situations where — just like that where someone says, “Why did we do it this way?” and if you can’t remember why, then you’re doomed to just make those same mistakes again. You’re not going in a complete circle, back to square one where you were six months ago with the very first design that you had. You start over again and then you realise, “Oh, yeah. That’s right. This is why we did it that way. We just wasted a bunch of time.”
So I usually — a design log is great. The decision log, you know, making a list. It’s about taking good notes at meetings, right? OK, James said that we should change the button to red. So that’s what we’re doing and he said the reason we have to do that is because red buttons have higher conversions, right?
I mean it doesn’t have to be long. We’re talking about a few bullet points. Once on one client project, we had so many different people involved and they weren’t always all in the same meetings, that I ended up creating a separate page on our prototype called the “change log”.
I mean you think about like a software version change log, right? When software companies update software, they usually have a bullet list of everything that changed for the new version. It’s basically just like that, right?
So every time there was a new version of the prototype published, I would just write up a bullet list of what we changed and why and who told us to do it because what happens is six months later, there’s a new manager or a new executive. Someone who has no context whatsoever comes in and they say the same obvious thing that you thought in the beginning. Well, why can’t we just do it this way, right? And if you don’t have those notes to go back and look and say, “OK. This is the reason why we did it that way,” then you’re probably going to have to just start all over again and make those changes and learn from those mistakes at the same time. It just wastes time without that information.
James: I think it’s also applicable too to other aspects of the work we do like research work. Good note-taking during researches as well or annotating or making logs of what you found lies behind maybe certain decisions or if you found — you found some evidence, some data that backs up a certain approach, then making notes of that as well. I mean it’s — many times I’ve been caught out by — I found something in like analytics where it’s segmented and found a really good piece of information that led to a change.
But then when you’re in a meeting and you kind of say, “Well, why do you want to do that?” well, oh, because — how did I work out those figures? How did I come to that bit of data that was so blindingly obvious that we need to do this change? But now it’s lost in a sea of segmentation and Google analytics.
Per: I recommend to people or anyone who works with an agile methodology as well. You have demos. Don’t just describe what you’ve done. Describe why you’ve done it as well because then you have more people listening. You have more people who can help you remember why you did it as well.
Chris: You talked about expertise and credibility in the book too. To me it also supports that because if six months later they say, “Why did you do that?” and you’re like, “Ah, you know, I don’t really remember. It seemed like a good idea at the time.” It somehow …
Per: Very unprofessional.
Chris: I won’t say it’s unprofessional but it deteriorates that — using a word that’s probably overly used, that persona of the designer who has things, who knows what he’s doing or she’s doing, knows why they did it and can articulate it well. I think it adds to the articulation level by being able to go back and say, “OK, we did it because of this.”
Tom: Well, and giving our stakeholders confidence in our expertise and our skill. It’s maybe one of the biggest benefits of being articulate about design decisions because yeah, that’s a perfect example. If someone says, “Why do we do it this way?” and your response is, “Oh, well, at the time, there was this thing and I’m not sure why. But I remember that John said this.” It just erodes that credibility.
But if you respond with confidence and like a well-articulated position, it gives the other person confidence. If you’re confident, they are too and they go, “Oh, wow. This guy really knows what he’s talking about. OK. So yeah, that sounds great. We will keep it that way.”
There’s a logic there and I think you — that piece is missing if you’re not able to explain it.
Per: Sometimes we’re thinking about, “Well, how do I get the confidence and the ability to describe and be that articulate about my design?” and you also introduced the concept of the dress rehearsal. I’m actually doing presentations before you do them, which helps you — sometimes you get feedback from whoever is listening during the dress rehearsal about things you can change. But it also gives you confidence. I’ve done this before. It will be easier to do the second time when I actually do it in front of the client or whatever stakeholders I’m meeting.
It has helped me a lot doing dress rehearsals and the health environment where I work now, where I work with people who have specialties that I have — I’m not aware of and you can get these — we were talking before about distractions in your presentations. Like, I had a picture of a doctor having a long-sleeved shirt and somebody called me out on that straight away. You can’t have a doctor with a long-sleeved shirt. They have to have short-sleeved shirts. Otherwise, people are going to point to that and say it’s wrong.
So anything that you can get away from — get away those distractions from your presentations, do your dress rehearsal and make sure that you get that out before the actual meeting.
Tom: Yeah. Well, and practicing — in the book I say that practicing for a meeting is the usability test of explaining design decisions, right? Because we — I don’t think that’s a term we all kind of get and understand. Before we take this design decision to production, we’re going to test it just on our own in our own little space, on our own team, in the shower, on the train, wherever and that — and it helps you understand the rationale too.
I mean if you have a chance to just pretend that you’re already talking to that executive — and I do this all the time. Just right here in my own office, I just stand and talk to the wall or the mirror and I practice that presentation. I find myself saying things in a different way and sometimes I uncover logic in my decisions that I didn’t even realise was there.
So it gives you that confidence to like go, “Oh wow, I’m actually kind of a smart person. I actually did this for a reason and I’m able to talk about it,” right? When you do that, you’re going to be so much better prepared and I would suggest doing that even for shorter meetings. I think sometimes we think that we only need to do this to meet with the CEO. But I mean even if you’re just having a daily stand-up to tell somebody, “Here’s what I worked on yesterday. Here’s what I’m doing today and this is why,” that’s going to give your whole team confidence that you’re doing a good job and you know where you’re going.
James: It’s an excellent point. Can you imagine a world where no speaker at any conference ever practiced their talk before getting on stage or any actor in any film in order to learn their lines? I mean the whole world with kind of TV, theatre and presentations and so on would just be chaos if no one bothered to actually test what they’re going to do and try and learn and practice what they’re presenting.
Chris: I think that also goes back to the design process itself. I mean there are many times that I have created something in my head. I’ve even done a little sketch and then you call a buddy over there and you say, “Come on over,” and you say, “Here’s my thing,” and you have to articulate it.
You realise this was really bad. It was — I really — I don’t know what I was thinking. But it’s not until I said it or you had to say it because you’re using a different part of your brain and you’re thinking of things differently, that you realise that this is good or sometimes, occasionally, I will say something and I will stop and have my inner monologue and say, “That was really good.” That’s much less frequent but that happens.
James: Halfway through, you will stop yourself and realise the actual good answer. You realise, now, this wasn’t that good. Now I’ve got it. I will come back to it. You come back five minutes later and pretend …
Tom: Well, have you ever had a conversation where you walked away and you thought, “Oh, darn it. I should have said this a different way,” right? Someone hurls an insult at you and then it’s not until two hours later that you think of a really good comeback, right?
Chris: I got the right comeback! Come on back.
Tom: That’s exactly the same principle, right? You give yourself a chance to think of those things in advance. It doesn’t have to be complicated but I do think that we need to work that into our process. Our process is design, iterate design, iterate test and then demo. There’s a practicing for the demo stage in there that is sometimes missing.
Chris: I mean a lot of good advice. I work with a team and I usually encourage presentations and you mentioned facilitation. I think these are all essential skills for any UX designer. I would say sometimes even more important than the actual design skills themselves.
Tom: Yeah. I have a lot of people that say that — oh, maybe this is just for new designers, right? Who are new to the field. But I know a lot of senior well-experienced designers that don’t do this well. So just because you’ve been designing interfaces for 10 years or so doesn’t mean that you’re good at explaining them to people. You maybe have more practice talking to people. But it doesn’t — it’s not automatic that you can be good at these things. I think — we all need to practice it. This is something that I think we can all improve upon.
James: I think as well that the teamwork, making sure your team — you got to make sure that you’re batting for the same side because it’s not fun where you come to a meeting and you end up being isolated. If you go there, it’s part of a group. You’ve got to make sure you feel like your troops are with you. They’re going to stand by you and support you or fill in the blanks when you actually do have that moment where you can’t remember or can’t remember how you came to a certain decision. Someone is going to cover you.
Chris: That’s why with my team, I usually make the presentation to them first because they are the harshest critics ever. They will cut it up so bad and I know if I can get through those guys, it will be good.
Per: That’s excellent.
Chris: I do that a lot for — before I do presentations or presenting a concept to someone or something like that.
Per: Plus it shows that you have confidence in them. So it’s mutual. They get respect. You get respect from them.
Chris: Right. Also it works the other way. Sometimes I have done presentations and they’ve come back and said, “You know, you didn’t really hit it quite right on that one,” even though we had practiced. So it’s good to have someone that gives you honest feedback along the way.
Tom: Yeah. In the book, I talk about the idea of having a ringer in your meetings with you and the ringer is the person who already knows the answer to the question that is going to be asked. It’s actually pretty common on like a news format where the anchor in the studio is interviewing someone who’s out on the street, reporting about something happening live and then they cut back to the studio and the anchor asks one more question which the guy on the street just happens to know the perfect answer to, right?
They figure those things out in advance and it may seem a little bit underhanded but that sort of thing can actually be really effective in our own meetings with stakeholders when you have other people that are there to back you up and ask good questions about why you did what you did, because it demonstrates that there are other smart people in the room that agree with us, right?
This isn’t just my idea. This isn’t just my thing. This isn’t just what I like. There are other intelligent people that agree with me and I think anytime you can bring someone on board like that — and I should emphasise, I’m not just talking about design teams because there may be people who are on a design team of one and you need to get the person from marketing to come to your meeting with you because you know that they’re going to support you in those design decisions even if maybe they weren’t invited or weren’t initially a part of that project, right?
You need other people in the room to support you and ask good questions that you will be able to effectively answer in front of the people who will approve your work.
James: That’s an excellent way of tying it back into one of the earlier parts of the podcast there, when we said about — about learning to know your audience or who’s going to be in the meeting. That’s the thought process to bring in people but you do already know something about that — it allows you to internalise some of the situations that you’re going into.
Per: The whole rationale for doing this is actually to get the best design decisions or get approval for the best design decisions and not get stuck in those conversations where you don’t get anywhere.
Chris: I’m curious how you came about to decide to write this book. What was your thinking and over what period of time? I mean did you just wake up one day and say, “I know what. I know what the key to all these 15 years of experience is”? Can you guide us through your thinking process there?
Tom: Sure. Well, I mean I think probably my whole life or my whole career, I mean I’m — if anything, I’m good probably at talking. I just have the gift of being able to make stuff up as I go and so in that sense, this is a skill that I probably have more — that I’m more naturally inclined to. But I remember talking to a colleague once a few years ago and him telling me, “You know, it’s one thing to be able to design really well. But it’s another thing to be able to teach other people how to design really well or to explain to other people what good design is and what it looks like.”
That stuck with me for a long time. So then I was actually — so I live near St. Louis, Missouri and they were doing a UX conference. I had been asked to submit a talk for that conference and so I actually submitted at least three different ideas and Articulating Design Decisions was one of them. But believe it or not, it was my least favourite of the three because it seemed so obvious and so just kind of boring to me. This is something I do every day.
I’m a designer but I probably spend 50 percent of my time telling people why I did what I did. It just seems so mundane. But that was the talk that they were interested in having to give. So I spent some time kind of just thinking about, “OK, how do I explain my design decisions to people?” and I started writing down some principles and trying to kind of organise it in my head.
As I submitted talks for future conferences, this was the talk that other conferences continued to want me to give. So it started out as a conference talk and then I was at one conference where O’Reilly was the sponsor and my editor was sitting in the audience when I gave the talk. It was really well-received and they asked me if I would consider putting it into a book and there’s actually a video series as well.
But going from a conference talk to a book is challenging too because now you kind of have to look at each individual piece and break it down even more. So I think the process of reflecting on my own career and how I do what I do and why I do it that way and what are some best practices for explaining things, it’s difficult. It’s difficult to do. But it was very rewarding I think to be able to look back and hopefully help some other people overcome some of the same things that I have dealt with in my own career.
I know all of us can relate to having these conversations with people about design. So it has really been fantastic to hear from people about how the book has helped them. I hope it will help you guys too.
Chris: Well, it has definitely helped me. I can say that right away. So …
James: And I think it’s clearly from the attention that you’ve received from conferences. You found a pain point out there that people have and hopefully helped them come closer to solving it.
Per: So well done and thank you very much for joining us and talking about it as well.
Tom: Hey, no, thank you. I had a lot of fun. Thanks for having me.
Per: So that was a really good question you asked at the end there Chris because it’s fascinating sometimes that when you know stuff like Tom obviously does, you don’t realise how little other people know. You think that, well, everyone is doing the same thing. So when you put these forward to conferences, they actually realise that not everyone does it the way Tom does it.
So this is something that we can learn from him and I think all of us are in that position. I mean when I first came into HTML design, in fact, this is really simple. A lot of people know this. Why would anyone pay me to do this for them?
You realise, oh, so not everybody does this. So it can really matter because then Tom’s mission then is actually articulating how you articulate, which is quite fun.
James: I also reflected on the fact that — you asked the question about writing a book and why and Tom said about how — or implied the therapeutical process of doing it. They gave him the chance to reflect upon his work and his creative processes and considered them and put them to paper.
Then of course allows him to share that knowledge and sharing the knowledge is such an important thing in our young industry and one of the reasons why we do this podcast is to learn ourselves and to share knowledge. But we’re all the composite of our experiences up to this point and the knowledge we’ve picked up. So we’ve all got something to share if we can just articulate it.
Chris: Right. And I really like that Tom has made the reference to teaching as well because I have recently been involved in a little bit of teaching and realised that you really need to be able to articulate your message very, very well. Just starting out, you think you can do it really well but you realise after doing a couple of trial runs that people don’t get it. So I think the exercise or articulation is one of refining your own thinking and your own thoughts to be much sharper and effective. So yeah, I really liked it.
Per: It’s good to have people who are able to give you honest feedback. I mean I don’t think everybody has that. I mean I get so much feedback saying, “Oh, that was really good.” But then there’s something that wasn’t quite right, that people are somewhat afraid of telling you sometimes.
Chris: Well, yeah, because they think that you’re the expert and they don’t know anything. What do they call this? The Dunning–Kruger effect where they — the experts don’t think that they know anything and novices think they know quite a lot.
James: That’s the kind of opposite thing, the Impostor Syndrome.
James: I actually tweeted a quote from Tom’s book the other day. “Stop. Take a look at the people around you and remember one thing. They’re human,” which — I mean I’m not trying to summarise his book in one line. But that’s one of the things that always stood out for me there and we’ve even brought it up with Whitney Hess when we talked to her and the whole empathy thing and remembering that we’re all just people and you actually have a much easier job I think of communicating things or even giving feedback if you remember that we’re all just people.
Per: And don’t be too quick to judge.
James: Yeah, yeah. And don’t be afraid of people. I mean the CEO is also just human.
Chris: Good point James.
James: Thanks Chris.
Per: Almost a little therapy session here.
Per: Next week, we will be having a call-in coaching session.
James: We’re just going to hug.
Chris: We’re just going to hug. You can’t see us now. But it’s a group hug going on here.
James: If you’ve enjoyed the show, then — well, that’s absolutely excellent. It makes us a bit happier.
Per: Yeah. Go into iTunes and give us a recommendation.
James: Or just tweet the show.
Chris: Or send a check.
James: To Christopher McCann.
Per: I like how you think Chris. I like that.
Chris: If you contact me on Twitter, I will send you the bank account number and all the other things that you need.
James: It’s a wild cannon this one. I can’t take … he just keep chirping on here.
Chris: I mean, you know, if people really want to support us, support us so we can keep on going.
James: Unplugging. So we’re UXPodcast on Twitter and everywhere else all one word and the show notes for this show will be available on our website which is UXPodcast.com. We’re your hosts James Royal-Lawson.
Per: Per Axbom.
James: And …
Chris: Christopher McCann.
James: And this is all going to go wrong now.
Per: Remember to keep moving.
James: See you on the other side.
[End of transcript]