Friendly discourse is at the core of great of product design and . How can we get over our fears and use it as a tool?

I was designing an internal tool for a fairly large internet company (who will remain nameless… for now). I’d been at it for about 4 months straight. My desk covered in ideations, lo-fi sketches, audits, interview notes and I’d produced close to 40–50 different screens (I know, 40–50 is way too many screens. It was a massive piece of software okay?)

Two weeks to go and I had to have this project turned over to developers. Users were waiting, their problems mounting.

I’d review everything with the design lead, the stakeholders and the user researcher. “Looking good!” We’d all agree.

So we get our designs together, clickable prototypes our research summaries, journeys—everything and get ready to do a final review of the work with the whole team.

Sometimes it just takes one person’s views to change everything.

I’m showing the work, walking everyone through our testing and bang! The one stakeholder who hadn’t been around throughout the project starts throwing wrenches into nearly every one of my design decisions.

“Why did you put this here?”

“Why is that important? Isn’t x more valuable?”

“You asked that testing question wrong. It’s leading!”

“I’m not sure users will enjoy doing their jobs with this. It doesn’t feel delightful.”

“But how will people do x with this? Isn’t that something we want to solve?”

I pushed back. I reiterated our user research data. I defended my design decisions. He conceded on a few things but damn he was very right about a lot of what he was saying. He wasn’t arrogant. He wasn’t rude. He was just… correct.

Now, if only I’d gotten that feedback at round one, not round 17.

We weren’t “wrong” about our design decisions. What we designed would have worked. Decently. But I looked at my designs now with this new perspective and I realized what I was feeling in my gut for the last month or so—this thing still needed a lot of work.

Who’s fault it was doesn’t matter. Who takes responsibility for fixing it is what matters. Be wrong. Fail. But you better dive back in and make it right once you’ve realized that. In my opinion, this is a quality that differentiates a great team member from one I would never pass the ball to.

That’s the kind of team member I’d want to play with so I decided I would try to be that person.

Well, that was humbling…

At first, I felt resentment. Who was this person to come in at the end of the project and throw a wrench in everything? What right did they have?

It’s hard not to take feedback and arguments against your work personally. You put your work out there, someone steps on it. Ouch. If you really can’t take it, you may be in the wrong industry. But, I bet you can. Even if you can’t right now, you’ll learn to channel it and use it as energy.

I swallowed my embarrassment, put on my cloak and wizard cap and dove back into my wireframes. After a few whiteboard sessions, some additional (and rapid) user testing, taking into account all of this late-in-the-game feedback, I landed on some of my proudest design decisions yet.

After a few late nights and early mornings, I was finally proud of my work. Truly. I liked it before. Now I loved it. No more lingering doubts. I felt renewed, energized.

The more I worked, the more I respected this person’s willingness to the work and my decisions. They seemed like some enlightened prophet. How did they see what I and the rest of the team couldn’t? The truth is, they didn’t. But they weren’t afraid to use argument and respectful discourse as a tool to dig deeper.

This isn’t just about design. It’s about getting to the core of any problem.

If you ask “why?” enough times, you should eventually arrive at a basic and axiomatic truth.

Sure, it works wonderfully in product design and UX. But it works pretty well with just about anything. The more you flex this mental muscle, the stronger it becomes and the more adept you become with it.

Sure, you may sound like a 4-year-old, but I’ve gotten to some pretty profound truths chatting with kids.

Okay, there are a few guidelines though…

This isn’t a dissertation on the debate. I’m not formally educated on that (though it does sound interesting!)

  1. Be kind and be respectful. Having your work questioned is tough as it is, checks your tone and argue accordingly.
  2. Ask before you argue. If you don’t understand the other’s viewpoint, question it until you do and THEN make your argument.
  3. Don’t argue for the sake of arguing. Yes, it’s fun. It’s also self-indulgent and wastes everyone’s time. Make your points and move on.
  4. It’s not personal. Usually. Try not to take arguments personally. I usually find that people are coming from a place of care for the work and desire for understanding. They have a stake in your success.
  5. If you can’t land on an agreement, take it to your users! Talk to your developers. Your BD people. Your leaders. Weigh the pros and cons. Just land on something.
  6. Don’t let that gut feeling go unchecked. This is incredibly hard, especially as you get further into the work. Try to find those wondering doubts and turn them into questions. Your future self will thank you.
  7. Please, please, please make sure everyone is in the room for the important moments. It’s your responsibility as a designer to ensure you have consensus from those who have the deepest understanding. Easier said than done I know.
  8. Aim for deeper understanding. Encourage friendly discourse with the purpose of creating new ideas, understanding deeper meanings and iterating on your work.

So, what do you think? Argue with me. Please.

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here