Tom Greever on articulating design decisions

In this week’s Design Podcast, I sit down with Tom Greever, UX director at Bitovi and author of Articulating Design Decisions. We talk about how to effectively explain your design decisions, avoiding the CEO button, and how saying ‘yes’ is a facilitation superpower.

Here are a few highlights from our conversation:

The CEO button

The CEO button is an unusual, or otherwise an unexpected, request from an executive to add a feature that completely destroys the balance of a project and causes designers to cry themselves to sleep. You hear this referred to in other areas as the ‘Swooping poop,’ or as the ‘Hippo,’ which refers to the highest paid person in the room.

It’s this very common sentiment that there is someone who doesn’t know anything about design, they are in charge of us and our projects, and our destiny, and they’re paying our bills, and they get to make that ultimate decision. They are the people we have to convince, and often it feels very much like what they’re asking us to do is irrational, or it’s the wrong choice, or it doesn’t make sense to us, or they’re not trusting our expertise.

In the case of the CEO button, there can be a disconnect between what the stakeholders and the business want or need, or what their felt needs are, and what we think needs to happen. A lot of it is because we focus so much on the user, on say usability, may be even on the visual design, or the beauty, or simplicity of our work.

I think we spend so much time, rightly, focusing on the people at the other end of our products that we forget about the people who are also in our meetings, and who have the authority to say yes or no to our positions.

Leading with a “yes” and the IDEAL framework

Using the word ‘yes’ is meant not to do anything, and everything stakeholders say, if they can just have their way with your work, but again to foster this idea that we agree we’re going in the right direction. That’s definitely part of the first step. In the book, I go into a lot more detail, but I have this acrostic that I call the ideal response to design feedback. It’s an acrostic where each letter of the word ‘ideal’ stands for part of the message that you want to deliver to them. The I is to identify the problem, that the first step is to talk about, ‘Okay, here’s the problem that we’re chasing after, right? This is the thing that we’re trying to solve.’ The D is to describe your solution: ‘Here’s how I’ve solved this, and this is what we believe is going to actually fix that problem.’

The E, then, is to empathize with the user. Again, we still have to bring the user into it because we may be the only window that our stakeholders have into the lives of our users, so it’s absolutely important that we bring that to the table. Sometimes that is in the form of data, or a user test, or an interview, or something, but we need to remind them of the person on the other end. In the next one, which is the other side of that coin, is that the A is to appeal to the business because it’s not enough to just say, ‘Here’s the solution for the user.’ We have to let them know how that’s going to help the business. This is going to be more about some sort of metric, or KPI, or goal that we have as a business. If we make these choices, we actually believe it’s going to help us improve conversion.

Then the last one, which is absolutely critical, and it’s kind of the crux of the book, the L is to lock in agreement. Getting agreement at the end of this process is super important because if you leave that meeting without agreement, then you’re just going to languish in indecision. Even if you’re not sure of the direction, it’s better to do something, even if it’s wrong, than to do nothing at all. You have to be direct in saying, ‘Do you agree with this? Can I get your approval?’ I think it’s okay to be that direct and be sure that we force them to give us a clear yes or no, because if it’s no, we need to restart that discussion and figure out where we went wrong. If you don’t have that L at the end of the word ideal, then all you have is an idea, and we need something more than just an idea, something that we can actually get out into the marketplace and help people.

What you like vs. what works

One of the things that I hop on a lot is this concept of helping our stakeholders convert likes into works. That is, to get people to move from talking about what they like and what they don’t like, which are just their preferences, and this purely subjective concept of design, to what works and doesn’t work, which speaks more to the effectiveness of our work, or the usability of our applications. It’s way too easy for people to come in and believe that our design’s subjective, and what they like matters the most. ‘Oh, well, I just don’t like it, and so we can’t do it that way.’