Product Design Collaboration: You’re Not Thinking About It Enough

You’re a product designer for hot software startup X. Your team is midway through implementing a design you came up with. Suddenly, one engineer exclaims “I really hate design detail Y, why are we doing it that way? Can we do it this way instead? Or get rid of it?” Your heart drops. Why are they bringing this up now when we’re so far into implementation?

The above problem can be boiled down to this: Your team should rarely be debating a new design after beginning implementation. Yes, there are occasional times when there really is something you didn’t think of. However, if it happens consistently you have an actual problem.

Let me first point out that while this problem can be demoralizing to a designer, it’s actually the sign of a healthy team. It means your engineers care about what they’re building, they’re not just Code Monkeys.

The unfortunate flip side is it means you failed as a designer. You didn’t fail at the design portion, but you failed at consistently getting buy in from your team. A designer that doesn’t know how to work cross functionally is just as bad as a bad designer.

I don’t think this problem is that uncommon because for many designers the collaboration part of being an effective designer is actually harder than designing itself. I’ll talk about one method I use to combat this problem, but first let’s examine why they may occur in the first place.

Encountering this problem can be jarring for newer designers because to become a designer in the first place requires a bit of hubris. You believe you have amazing taste and are the definitive voice for user empathy. “I was hired for a reason” is a phrase I’ve heard before. However, it’s never that black and white. Ego gets you into design, but humility keeps you there. That’s where learning to collaborate comes in.

Why does it matter to fix this?

Designers love romanticizing the idea of designing within a vacuum, aka “I wish I was designing off in a remote cabin, where no one can compromise my pristine vision.” If only this were practical. In the real world, you design with a team that helps you build out your vision because you can get exponentially more done with a team. The best, most impactful products you’ll ever produce will be made with a team, not by yourself. Having partners doesn’t just increase your output capacity, but it also brings different perspectives that can unveil completely new ones.

Only one cook in the kitchen here

Thus it isn’t enough to ask the most commonly posed and answered question: How can I design good products? Instead, you need to ask: How can I design good products while working within the context of a cohesive team? How can I design in a way that brings excellence out of the people around me, not just myself? This isn’t optional. It’s a requirement, and it’s what sets apart the good from the great.

What to do?

Back to the problem: so when another team member questions the design that’s already partially built, what can you do?

Well, let’s talk about what you shouldn’t do. The temporary bandaid is to just tell them to trust you point blank or provide some pithy rationale just to keep them trucking along. You’re the designer after all and they’re the engineer. Admittedly, this is easy and I’ve been guilty of it. Short term, it might work. Long term, it’ll lead to resentment. Who enjoys being told to blindly follow orders? Minions, maybe, but not people.

The first time it happens though, you need to just work through why they brought it up. Did you miss some edge case? Do they disagree with the goal you were designing for? Was there a constraint you forgot about? Is it a subjective point like the color or border radius? You have to identify if the reason they’re bringing this up now is if it’s because you truly dropped the ball in a certain area, or because they had ideas the entire time but you just didn’t involve them. Getting to a mutual understanding here is just honest communication.

For the future though, it ultimately comes down to having a good process that actively involves your entire team. A playbook you can execute time after time again.

It isn’t enough to ask: How can I design good products? Instead, you need to ask: How can I design good products while working within the context of a cohesive team?

I’ve met designers who scoff at and eschew process. It may work when freelancing or working by yourself, but to design effectively with a group requires a more deliberate system, not a flippant attitude of going about it whatever way, because consistency in process builds trust among your colleagues.

One method I use is simple in theory. It’s centered around having a brief, which have been used by designers for ages. I define it as the essential questions any good product designer would ask before they begin designing. Everyone’s brief is different, but here are the top questions I use on mine:

The reason you need to answer a comprehensive brief is because understanding the unknown is the number one thing a good product designer does. Not fancy animations or typography. It’s understanding why this design is even needed in the first place. If you knew the answers already, you’d just be executing a known plan. That’s called planning, not designing.

However, it’s how you build out and use the brief that’s key. You can start it with basic answers, but never answer every question fully by yourself. Instead, have a kickoff meeting where you fill out each question with your team, even if you think you know all the answers.

Here’s why:

As you fill it out, team members will likely have ideas on possible solutions. Write these down in a separate brainstorm section and don’t rule anything out, no matter how ridiculous. However, avoid prescribing concrete solutions in this kickoff meeting. That’ll be your job. Some of their ideas can feed into what you come up with.

Ultimately, the goal is for the brief to become a living document that your entire team gets to shape and agree on before you go off and do all your design exploration and thinking. When your team feels they had a say in what you end up designing, it should minimize unexpected blowback later on.

After that, continually re-reference the brief. When reviewing the designs you came up with, go back through the brief to remind your team of what they all agreed to solving and point out how certain parts of your design coincide with certain sections. Have them give their feedback in a similar fashion.

The point is that by the time your engineers get to implementation, it would feel like they’re questioning themselves to question the design. After all, they were a big part of the reason it was designed that way.

If a design detail does still end up getting questioned during implementation, the conversation should be much easier to have. Once again, tie it back to the brief. However, if it’s something everyone missed, then it’s a shared responsibility to get it fixed, not just 100% your own.

Multi-species hands unite!

The process I describe is just one potential way to improve product design collaboration. The key point though is to consciously use a framework for collaborating in addition to the actual designing. It won’t guarantee results 100% of the time (what can?), but I’d bet money it’ll give you consistent results a majority of the time. Plus, working with peers will just be more enjoyable because there are fewer surprises for both sides.

Collaborating on design isn’t easy and can leave many feeling frustrated. Here’s an alternative mindset that may help: think of collaborating on design as just another problem to solve, just like when you’re figuring out a new design. The payoff of figuring it out is worth it: a team that not only builds great products, but does so in a way that’s harmonious and efficient.

Agree? Disagree? Have other methods of collaborating on product design? I’d love to hear any and all thoughts. Strong beliefs, loosely held as they like to say. Find me on Twitter: @jobosapien

Working on something new

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store