Earning It: On Respect and the Software Developer

A developer friend of mine told me a story once. He was approached by his product manager who asked him, “Why won’t you build what I want you to build?” I suppose we could give the PM credit for being direct, although we’ll see later that he’s not being as direct as it may seem. But is that any way to win friends and influence people? Nope nope nope.

Unfortunately, all too many designers find themselves thinking this at times, if not saying so. You work your ass off getting that wireframe or comp together, you’re inspired and in love with what you’ve done, and reactions are a mixture of:

      

AND OF COURSE

Let’s set aside for a minute whether your design is good or not. Let’s set aside your ability to sell it. And let’s not worry for a moment about whether or not your colleagues can give you useful, kind, productive critique. (We’ll get to that another day.)

Sometimes you just want to say, OMG CAN YOU PLZ JUST TRUST ME AND BUILD IT OMG.

This is most likely a side effect of exhaustion. So don’t say it. Go get yourself a nice latte, maybe even a nap, or if you’re still stuck in that meeting, take a nice deep breath.

There, feel any better? No? Okay, well then keep reading.

I do want to throw in a caveat that there are some collaborators out there who will not cooperate with you no matter what you do. On every team, there will be people who are a joy and people that you struggle to work with for one reason or another. But the majority of people want to spend their time making something good, or even great, and are interested in any ideas that let them do this.

So, why won’t he just build what the product manager says? (Or what you designed?)

First, maybe he or she doesn’t think your idea is good. Or great. There’s the obvious implication that the developer doesn’t want to build the proposed solution because he doesn’t agree that it is the right thing to do. The obviousness of this is why that isn’t really that direct of a question on the part of the PM in the first place. The real question to ask is, “Why don’t you agree with me?” By simply asking for blind compliance, the PM is strongly asserting that the developer’s opinion does not matter. That it couldn’t possibly help the situation or be valuable. So we could say the PM is implying, “Why do you even have an opinion? Just do what you’re told.”

People do this to designers, too.  How often has that happened to you? How often does it happen to developers you work with?

More often than it should.  (I’m willing to bet you lunch on it!)  And they bring that baggage into their discussions with you.

The thing is, the PM is asking for respect, but not giving it.

 

But you can’t ask for respect. You have to earn it.

 

---

 

So how do you do that?  Below are some ideas for you, but to summarize: do the work, have reasons for your choices, show your heart is in the right place, and most of all—give respect in return.

DO THE WORK

If you half-assed this design, people can smell it. They might even immediately think of a better solution. You may have had a good reason–having 12 other projects–or maybe you just weren’t inspired. In this case, it makes sense to gather up ideas to make the design better. You might consider starting off the discussion by explaining that this is a small start that you hope to finalize later (although never put your work or yourself down).

Another option? Don’t half-ass it, if you possibly can. People grant some respect to people who have put in time and effort, sweat and tears, whether they crossed the finish line or not. Effort alone won’t make you a perfect designer, but it won’t hurt anything either. However, you can’t expect people to not question your designs if you haven’t thoroughly questioned them yourself.

ASK THE REAL QUESTION

Back to those mixed reactions. Maybe some are nodding, and some are scowling. Now is the time for you to teach. What makes a good design? Why did you make those decisions? What goals was the team trying to achieve with this interface?

These are all ways of working through the real question—why doesn’t your audience agree? Then work through disagreements together.

One of my favorite tools for this kind of discussion is the design pattern. A design pattern is a common solution to a problem that comes up again and again. Tabs, menus, radio buttons, and checkboxes are all design patterns. The interesting thing about patterns is that there is no single right answer. Multiple patterns are likely to solve the same problem much of the time, and they each have pros and cons.

A doubting developer may simply be thinking of a different UI pattern that could work even better than your proposal. Sometimes, there’s a tradeoff she hadn’t considered. Either way, talking about design in terms of patterns has one huge awesome side effect. It changes the discussion from being you versus them, to this pattern versus that pattern. It allows the team to consider and weigh options as a team, rather than feeling like the team is divided into different disciplines. It opens up your thought process, and can make it feel justified if not inevitable.

To learn more about design patterns, UIPatterns.com has some great UI patterns for reference, as does the classic book that’s I’ve recommended so often it’s disappeared… Designing Interfaces (affiliate link).

STATE THE GOALS AND TARGET USERS UP FRONT

The other common disagreement around design comes from the team members having differing ideas of who they are building for and what that person’s goals are. One way to approach this is to set the stage with a discussion of user goals and characteristics. If you have already established the business and user goals for the work you’re doing, written personas, or done any similar work to get started, now is the time to trot it back out and apply it—or iterate on it if need be!

This is also helpful to show that this isn’t about you or your ego. It’s about the bigger reason why you’re working—to make something great for your users. If people know that you are sincerely trying to argue for what’s best for the people that will use your application, it helps diffuse conflict.

Being committed to a shared mission and serving it faithfully naturally earns people’s respect.

COME UP WITH IT TOGETHER NEXT TIME

When I spoke about design patterns, did you notice the point about talking about the design as a team rather than us versus them? That’s big. That’s important. Seriously—this is such a great habit and mindset. If you don’t already, start thinking of your team as contributors to the design, and you are their leader, teaching them the ways of the UX Ninja Master.

What if you talked about this before the moment that you proposed a design to the team? What if you generated the ideas together? You may already be doing this. But if not, go buy this book: Lean UX (affiliate link) and try out a design studio exactly as described. Honestly, the first time I read Lean UX, I felt like it was a big DUH! Of course you should do all these things! Isn’t that just doing design? It was only later that I realized that while I had felt like I already knew the ideas in the book, I wasn’t following them. I wasn’t applying them. It took telling myself to follow the processes step by step to feel something new, altogether scary, and awesome.

While you’re waiting for that book to arrive via Amazon Prime, you could also simply take some time to consider these questions and jot down your answers:

• How could I work more collaboratively with my team?
• What fun techniques could I try?
• How could I involve developers and other stakeholders earlier?
• Could we generate ideas together next time?
• Could I show team members whiteboard or napkin sketches? Individually? Over coffee? Informally? At lunch?

Consider your audience. Your mileage may vary, so tailor your process and technique to your audience and their own individual styles, preferences, and personalities. Not everyone is a great collaborator right off the bat, but people might surprise you given the chance.

WHO’S RESPONSIBLE?

In your organization, what happens if users find your proposed solution difficult, confusing, or unappealing? Is it the product manager who is going to take the heat? Is it the developer? Is it you the designer? Is it all of the above, the whole product team?

This should play into the decision making. I spent most of my career in a situation where designers were most held responsible for difficulties in using the software—even if we proposed building something different or the solution built was specified before we were ever involved. That was okay with me, because I consider influencing developers and making sure the right thing has been planned as part of my job. Many of my coworkers were sensitive to this, and while we might not always agree in the moment, they sometimes recognized that since I was the one going to be held responsible, they would build my proposal even if we couldn’t quite agree. This wasn’t frequent, but it was a huge display of trust (and respect) when it happened.

I tried to deserve their trust by trying to remain unbiased as we gathered feedback, and specifically take time to look for feedback that indicated that an alternate solution would have been better.

TRY IT AND SEE

There’s nothing like a user testing something to suss out what’s really good and bad. It’s more effective than discussion and debate, and far more scientific and real. So one strategy is, build whichever solution—yours or an alternative—and then test it. Or build them both and A/B test them, if you want to get really fancy!

Be careful to be scientific and use best practices around user testing and evaluation. Don’t inadvertently skew results in your favor. Get another designer to test your design, or at least review your methods and protocol. Ideally, have team members see the users using the interface with their own eyes—in person or on video. It’s much more visceral.

Depending on the issue, you may also be able to look to data in your application to inform debate. How have users behaved in the past? How are they behaving now? What metrics could you collect to inform the best UX in this situation? Team members may be even more keen to add the infrastructure to collect metrics, if it’s a risky or unclear decision.

ISN’T IT IRONIC?

People respect people who show them respect. Hm, yeah—I don’t think that’s ironic. It’s just common sense. But it’s all too easy to forget in our day to day actions. We all know respect must be earned, but we don’t necessarily think about it consciously when we’re interacting with others.

So take a few moments this week to consciously think about it. What could you do to show people around you that you respect and value them as equals?

When you show openness to the ideas of others, you earn it.

When you show fairness in weighing all ideas equally, you earn it.

When you show skill in identifying which options are better, when you can articulate yourself, communicating why you chose what you chose.

That is how you earn it.

Know what’s actually kind of ironic? Often after you do these things, people will actually just build what you say, because they trust you. But they still know, if a better idea occurs to them, you will be ready and happy to listen.

 

Please note this post contains affiliate links, which means that a portion of the cost of the item goes to support this site at no cost to you. Thanks!