Design-Splaining

What it is and why you need to stop doing it.

David Stewart
4 min readApr 21, 2016

During the #Gamergate fiasco, I realized that details of the conversation overlapped with my knowledge of the tech world and I found myself at times explaining the background to my teenage daughters. Thinking my knowledge of gaming and technology brought a different perspective, daresay insight, to the discussion, I eagerly offered up my opinion on how wrong the male community was in the way they bullied and terrorized the women involved. I was ready to explain how #GamerGate represented the mysogynist underbelly of our society and how it is creating a culture where women aren’t treated as equals.

Which is exactly when my daughers sighed heavily and rolled their eyes at me.

I was Man-splaining. The problem was that I can never fully empathize with the plight of women. Explaining concepts of feminism to an adult woman never comes off well. Ever.

Essentially, X-plaining something is explaining without regard to the fact that the explainee knows more than the explainer.

What is Design-splaining?

As a designer, I have come to realize I have been guilty of ‘Design-splaining’ many times. Chances are, you have too.

Here’s how I first did it. When I first started working at McAfee as a UX Designer, my first assignment was with the firewall team.

I was eager to prove myself. I did a heuristic analysis of the existing UI and came to them with a list of UX improvements and concepts I wanted them to start working on.

It needed to be more intuitive. A clear mental model needed to be defined. The app was full of drop-downs and shuttle controls that were just, well, antiquated and boring. The information architecture was completely off. Wayfinding was non-existent. We needed to interview users, create personas and create a user journey that would enable us to make user scenarios and wireframe concepts. The interface was totally unusable from a UX standpoint. Jared Spool and Don Norman would both totally back me up.

Crickets.

Just like when I man-splained #GamerGate to my daughters, the true facts I was talking about didn’t resonate. I was describing the problems using my own language from my own perspective. I was explaining real problems, but I was ignorant of the knowledge the engineering team had that when beyond the UI.

The team nodded and entertained my suggestions but they also told me how they wouldn’t work and proceeded to build their own solution. They would be happy if I would provide a visual design for the UI.

I was extremely frustrated. This team had an attitude. They didn’t understand UX and the app was doomed if they didn’t start respecting my role. Why was I hired anyway, if not to lead the app design process through UX?

I even went to my boss and asked him to tell them they needed to implement my solutions.

The problem was that although I was an UX professional with years of experience, I knew next to nothing about firewalls.

Speak the language

After my boss told me that he wasn’t going to tell the firewall team what to do, I decided I needed to approach it from a different angle. I got a copy of the firewall software and installed it on a PC at home. I set up firewall rules and set priorities. I looked at the impact the Sarbanes-Oxley Act had on them and the difference between IPv4 and IPv6.

I totally nerded out on firewall protection.

The result was a conversational understanding of the language. I probably sounded like a dumb American speaking 1st grade level Spanish, but at least I could ask where the bathroom was or order a beer.

Understand the Culture

I also hung out with the firewall team. If I saw a couple of engineers having a conversation I would just hang out and listen in. Eventually, I would be able to throw in a suggestion. I was still speaking rudimentary firewall, but I now knew the right time to say the right thing.

I went on to do user research, personas, user journey maps, wireframes, and even user testing at McAfee. Jared and Don would be proud.

The key was understanding the language and culture of the team I was working with. As User Experience Designers, one of the essential things we do is build empathy for our users.

When we design-splain things to people in general usability/UX terms, we aren’t doing that. We’re explaining their situation from our point of view.

How to Not Design-Splain

  1. Learn the launguage. At McAfee, I set up a network and installed the software. At Webtrends, I made fake marketing campaigns with my Twitter account and set up conversion goals on my website. At Intel, I used (shudder) an Android phone for 6 months. Even when I am Endorphin apps for running, I run (and I run all the time) with different running apps.
  2. Understand the Culture. Figure out how things get done. Embed yourself in the team. UX for the sake of UX is fine, but if you want to actually make something, you need to be hand-in-hand with the team who makes the experience. They want and need your perspective, but they aren’t going to wait for it. They don’t have time to map your highfalutin UX terms to practical concepts they can build.
  3. Shut Up and Listen. Just like I can never, never fully understand what it is to be a young woman, we can never really develop complete empathy for our users. What we can do is respect them and listen to what they are saying. We can observe their lives and figure out how our UX fits in to it. Even as a runner, I have to realize that I don’t represent all runners. In order to create a UX that resonates with different types of runners, I need to develop empathy for beginners and elites alike.

If you are not a feminist, you are part of the problem. If you are not a user, you are part of the problem.

--

--

David Stewart

Product Designer. I run, design products, drive a 1964 Buick Skylark, and raise my kids in Beaverton, Oregon. Not necessarily in that order.