Why designers fight with other product departments
Avoiding fist flying in software development
Most people have seen at least some variation of the trifecta of a software business — Design, Engineering, & Product (or business). Each one represents a discipline that’s necessary for the successful delivery of value to the consumer.
To everyone around us we love to say that as product departments, everyone holds hands and sings Kumbaya on a daily basis with beer in hand. Truth is, it’s (almost) never Kumbaya we’re singing. Secondly, behind those courteous, fleeting production conversations is more often than not a teeny bit of resentment.
The engineer is slightly annoyed that the designer keeps pushing for small user features that have big engineering cost. The product manager is annoyed that the designer takes too long with the designs because he/she is insistent on designing 5 iterations into the future.
Are designers just annoying people, hell bent on creating problems for everyone else? As one myself, I can see where the sentiment comes from. I find myself apologizing on a regular basis because of the compromises and groans I’m causing for everyone else.
Other than apologizing because I’m Canadian, I believe there’s a deeper reason why design has historically been put to the side when product & engineering need something shipped.
A Divergence in Goals
The Lean Startup methodology stipulates that entrepreneurs (in this sense interchangeable with business people/product people) should isolate variables and test one specific hypothesis at a time.
For example, if the hypothesis is “People want a green signup button.” Then we should not change anything else in the product except making that one button green. By isolating the variable, we can measure the impact and be able to draw a direct causal link to the change.
Likewise, engineers want to ship small chunks of code at a time. Again, it makes perfect sense. Code is an incredibly complex thing, and with multiple people working on multiple parts of the same code-base, it’s easy to accidentally trip over something that was built in the past and create bugs.
Deploying small chunks of code at a time reduces the risk that something is going to cause catastrophic failure. And if catastrophic failure still happens, the source is easier to pinpoint as there’s less code to sift through.
..And then we have designers. If the goal for engineers and PMs is to be reductive, the designer’s job is to be holistic. If the goal for engineers and product managers is to ship in as small increments as possible, then the goal for a designer is to map out and test the entirety of the experience. Of course, the end goal for everyone is to mitigate risk, but the stepping stones to get there are very different.
Design vs Product
As a product manager your job is to find out which problem it is that the team should try and solve. So you go about your day, talking to users and finding out that you want to solve the problem of people having a hard time signing up for an account. You bring the designer in, and you discuss how to solve this problem.
The designer goes away, meditates in a cave, and returns with a vision of a solution which actually solves the problem you wanted to solve, but also 3 other problems as well. Oh boy.
Think of it in terms of puzzle pieces. Typically, you should not have more than one solution for one problem. But it’s often very effective to have one solution solve multiple problems! Think of Instagram. Not only can I follow my friends to keep up to date with their lives, but I can also follow cartoonists to get daily updates on their work. Two different problems, one solution.
Your job a designer is to be holistic, so it would be a complete waste of time in some cases to only solve one problem with one solution!
The product manager however will have a bone to pick with trying to solve that other problem, because that requires additional investigation work.
What do we do?
Unfortunately there’s no easy answer here. Because there aren’t any clear cut rules in software development, there is constantly going to compromise, doubling back, revisiting requirements, etc. Basically, headache and wasted work will to some degree be an inevitable part of the software development process.
To mitigate it however as a designer, is to talk in the language that the other departments understand. Figure out what they’re concerned about, and explain the implications of making compromises. For example, let’s say product wants to test the changing of a single button color to green, but engineering wants to ship one change to all the button colors across the entire product first because it’s a single CSS class.
It’s design’s job to speak up and say that hey, there hasn’t been adequate user acceptance testing done of the green in other parts of the product. Present it as a risk, and see how the other person responds. If the whole team is aware of the risk and still wants to take it, then you’ve done your job. As long as everyone is aware of the tradeoff, there shouldn’t be any conflicts down the road.
All too often designers make the invisible compromises in their heads and let things slip. That’s what causes conflict, that’s what causes churn in the process. It’s very likely that the ideal solution could solve 3 more problems than the one the team originally wanted to solve. But the PM may still choose not to position it that way. Technically, it’s the PM’s call. As long as the team is aware that there’s customer value left on the table however, fist flying will be avoided.
At the end of the day, it’s really just a matter of communication. Maybe by improving it, we can all finally perfect our rendition of Kumbaya.
Speaking of product development, I work for a fast-growing esports startup called Battlefy and we’ve been hunting for a Senior Product Designer. If you’re excited by the potential of video games, esports, and tech startups, take a quick look at this job description and see if it’s something you’d be interested in!
