Before we get to the meat of this post, I want to say a few words to kick off a new series of posts that I hope will be amusing as well as helpful: Developer Archetypes. Each post will cover a type of developer one might encounter and tips for better working together with that personality type. Obviously, everyone is a unique individual with their own mix of talents and quirks, but as I’ve gone on in my career, I’ve started to notice some patterns and common strengths and weaknesses. When we pick out patterns, we can look at certain common situations that arise, and try to figure out how to best tackle them when they come up again. You know, learn from our experiences and stuff. So this kicks off the first Developer Archetype: The Better-Designer-Than-You-Are.
Okay, some designers might not believe me when I say this, but I swear to you, they exist. There are some developers out there that have a spidey sense when it comes to UIs. Perhaps there’s a dash of common sense too. Sometimes it’s because they’ve been staring at UIs for so… damn… long….
Still other designers might be thinking, SHHHHH, don’t tell them! They’re already insufferable enough. Trust me, guys, they already know what they are.
I’m talking about the developer who’s a better designer than you are.
If you haven’t worked with one of these, I wish you the pleasure of doing so soon. This type of developer tests a designer in a lot of ways we’re not used to. You’d think this would be easy street, right? And two designers on a project always are easier than one, right? Hah. Yeah. Right.
This developer ups your game, and also tests your ego. You may have mastered by now how to calmly defend a design you know is solid. How well do you handle realizing your design could be better in front of a room full of people? Do you freeze up? Get angry? Or do you get excited?
Because you should! Teams that can improve your work are new friends and allies! The fact that the people around you are good enough, smart enough, and vocal enough to give you feedback that elevates the team’s product is an awesomely fantastic thing.
Why so much Will Farrell? Is it a coincidence? Ask the animated gif gods! I don’t know. Both gifs via the amazing UX Reactions.
Working with this type
The biggest difficulty that can arise in working with this type is that it can sometimes be hard to accept their excellent critique and ideas. Of course, it may sometimes be easy—you were kind of hating what you came up with anyway, or the new idea is a exciting and trendy new interaction pattern.
But even the best of us can get caught on an off day. The day you didn’t get enough sleep, or you adored what you came up with, or they happen to present their critique in an especially harsh fashion. It takes practice to learn the ju jitsu of embracing even negative critique with enthusiasm. If you want to get better at this, here’s the first step. The next time this happens to you, simply take a breath before you do anything. Observe your reaction. Feel what your body does, what emotions jump to mind. After the meeting or discussion is over, think back on it again. How did you react emotionally? Were you afraid, frustrated, angry, annoyed, sad, a little happy, a mixture of many of these? Did you have an instinct that your design was still better? Or did you have an instant realization that the other person was right? How did the way they phrased their feedback influence your reaction? Observe how different people cause different reactions in you, even if they might be delivering a similar message.
Sometimes this developer type has great ideas, but delivers them in a shitty way. In this case, knowing they are right, but being frustrated or angry is totally normal. How can you improve the situation? It’s your job to model for them how to give good critique. Teach them how to talk about design objectively and not personally. (Because you are a teacher of design in every choice you make.) Make sure they know you are receptive to their ideas. (Because you are, right? Easier said than done sometimes, I know!) Sometimes this is all it takes to change their tone or attitude. It can be incredibly disarming to people when you simply listen to them, and that attitude may be the result of being ignored in the past. Seeing the shock on their faces can also be weirdly rewarding. 😉
Dont be this guy.
Sometimes, the problem is you. It’s natural to love what you do and cling to it. Part of maturing as a designer is rising above that, but I know I still have times when it’s a serious internal struggle. Sometimes you know someone else has a better idea right away. Sometimes it will take you time to realize that they were right, and it’s only after working with them for weeks or months that you realize that you consistently find yourself coming around to their opinion time and again. Consider giving their opinions more weight next time or talking to them earlier in the process. If you have a knee jerk reaction to their personality, try talking about their ideas in a setting where you have more control, such as approaching them at their desk. This can give you more time you work through the discussion and take an audience out of the equation.
If getting this kind of feedback makes you feel afraid or embarrassed, don’t let it. Your job as a designer is ultimately to get the best product into the hands of users that you can.
Noone has a monopoly on good ideas.
If you believe in interdisciplinary teams and the power of collaboration, or if you’ve ever seen it truly at work, you know how much better the end result can be when people work together. It is a fine line between too many cooks in the kitchen and interdisciplinary nirvana, but I’d rather be in the kitchen than in the design silo. The work will be better, and therefore what the users get will be better. When you feel a reaction like this arise, re-focus your thoughts on what’s best for the users. What matters is the best work, not who came up with it.
What if…?
Imagine this scene. You’re in a meeting, ready to show your work to the new team you’ve just joined for their review and discussion before the team begins building an initial iteration. You discuss how you think the first feature should work. One team member, with that slightly cynical gleam in his eye, pipes up with a different way to do it. His face and voice says he’s ready to be rejected and fight for his point. He knows he’s been right before. And he’s been argued with before. What do you want to happen next?
Let’s say you immediately realize it’s an improvement. What if you could exclaim your appreciation and immediately start adding his ideas to the mix? What if you simply said, “Great idea—let’s do it.” Remember, he got to his idea with your design as a starting point. And when your team sees that you care more about your users than about your ego, they will respect you that much more.
Of course, maybe it’s only a partial improvement. You explain the pros and cons of each idea or propose a combined new idea. Doing this on the fly can be challenging, but it’s worth trying. The only way to get better at that is to get started.
Other Common Pitfalls
Do you already know how to embrace this kind of feedback with positivity and enthusiasm? Well, at least most of the time? 😉 There are a few things to watch out for when working with this type, especially on more established, long-term teams.
Don’t rely on your developer-design-allies too heavily. You get busy, we all get busy, and you may be tempted to work with them less or specify less, because they have such good judgement. Sometimes this works okay, sometimes it doesn’t. It’s a roll of the dice. As someone who is sensitive to design, they may realize you’re slacking a little, and they’re playing the design role at least some of the time. They may or may not appreciate that. Also, sometimes this type relies on iterating on your ideas and doesn’t often come up with ideas from scratch. Those can be two very different things. If you collaborate less, you may find yourself in the awkward situation of now needing to tell them their designs could be improved. They, however, are newer than you to receiving design feedback and may not have been practicing being positive and enthusiastic like you have been. Plus, worst case, it may already be built or even in user’s hands by the time you discover an important choice slipped through the cracks. (I feel like a heretic acknowledging that sometimes things slip through the cracks, but let’s be real here.)
So don’t use their sensitivity to design as an excuse to neglect them, if at all possible. Instead imagine how stellar the features will be that you both work full steam together. Or, if you’re drowning under a sea of multiple teams needing work from you, acknowledge it openly and invite them to give you a nudge if something is slipping. Perhaps you need more time for getting your work done, but that’s another story.
