An essential role in UX

Stumbling along my career path as a UX designer, I have arrived at its natural conclusion of being the Dumbest In The Room. It’s a thing. My wife tells me I have an innate talent for it, and I must admit it does seem to come to me naturally.

There are some critical elements to this essential role. It’s not a job for everyone. Counterintuitively, you need to be smart to do it well. But when done well, it can lead to successful collaborations, especially in complicated and expansive projects.

Here are the rules.

Claim the title of Dumbest In The Room at the earliest possible moment. Usually, there is a scramble in the corporate world to be the smartest in the room; this should be neutralized as quickly as possible. I do this, for example, during the introduction rounds of a meeting. I announce that I am the Dumbest In The Room. It’s not subtle, I know, but it gets to the point. It brings a little light-heartedness into the conversation, an icebreaker.

Explain that the role of the Dumbest In The Room is to advocate for the user who is not in the meeting. Now, don’t get me wrong, the user is not dumb. The user is distracted. The user is not working for the company, although there are exceptions to this rule — think enterprise software. The user is in a distracting environment, at an office or home, or even traveling. She’s on the sofa with a laptop after a hard day’s work. The kids are just in bed, the dog is trying to get her attention, and she’s half-watching Game of Thrones. That’s the user using your digital product to book a flight or buy insurance. The user’s journey started way before they started using your product and will finish long after they have finished. Your product will always be just a part of their journey (buying a ticket, ordering food, checking the weather); your product is a means to their end. Assume that the user may not have heard of your company, what it does, where it is, and who works there. They don’t care. I have seen many adverts announcing a product with a fancy name, but the marketing department has forgotten to add what the product does or is. They assume the user knows what ACMEVO is. They don’t. They don’t work there, they don’t care.

As the dumbest in the room, you now must ask questions. There will be siloed fiefdoms in the meeting with their own jargon. Often, those fiefdoms will have conflicts of interest. So when the tech guy states there are ERD issues, ask what ERD is. You get to do that. The user is not in the silos. The user doesn’t care about ERD issues: Ban abbreviations, anagrams, and jargon from the meeting. Double-talk can be used as a power play.

In one meeting, I set up a whiteboard and noted every acronym as they rolled out. I set this later in a spreadsheet and sent it to all the group members, creating a living document. I received additions and later requests from other people for the list. Some were senior management, which made me happy that those people were open to learning.

By asking questions, even dumb questions, you create an atmosphere where it is safe to ask questions without losing face. It is also a reminder that you are making a product for the user rather than for the tech department to keep its dev team busy or for the BAs to reach their budget goals.

Challenge assumptions, and there will be many. Then, offer solutions to validate or dispel those assumptions. There is a fine line between dumb (lack of knowledge of the subject matter) and stupid, which will lose their respect. The task is to focus the subject matter experts on their primary goal, not their departments but the users.

Set a meeting agenda, stick to the agenda, and get action points and notes. I have been in many meetings of large corporations where the meeting had no clear agenda, the smartest guy dominated the conversation, the subject drifted to their fiefdom, and no notes were made or shared—a waste. I’m sure trillions of dollars yearly are wasted on these nonsense gatherings.

I once said in a job interview that my role was to be the dumbest in the room, and I hoped I was the dumbest person interviewing. I got the job. If you are smart about being dumb, you will achieve an excellent working collaboration and a much better product and understanding of the user.