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.

1. People are still figuring out the best way to collaborate on building complex software products. Digital product design as a discipline has only existed for two decades (since the mid 90's mainstream adoption of PC’s) and is constantly evolving with new platforms to adapt to all the time. The real ramp up has been the last five years, where software as a medium has truly begun “eating the world.” In the grand scheme of crafts, that’s really nothing. It’s not like writing or woodworking with hundreds of years of knowledge to pull from. Product design also combines a lot of disparate roles: UX, UI, user research, product strategy, data analyst, interaction design, visual design, sometimes coding, and more. Attempting to be so holistic comes with a lot of complexity. Uncharted territory abounds.
2. Designers are often very young and don’t have much experience collaborating. It’s not uncommon to see the average age of designers at tech companies to be 23 or 24. Although young designers can showcase beautiful work and get hired because of it, they lack industry experience/knowledge and don’t know how to collaborate effectively yet. Unfortunately (or fortunately), being a good designer is more than pushing pretty pixels.
3. Overzealous usage of agile can compromise a designer’s ability to execute their design process effectively. Tech companies are huge fans of agile product development, and rightly so when done right. But more often than not agile and its ilk are just an excuse to move fast, sometimes too fast. It becomes easy to miss things and design is often the first thing thrown out. If you’re a designer and this describes how you feel, fight for your need to slow down. A compromised design process will come back to bite everyone in the ass later.

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:

1. Who are we designing for? Are there multiple groups of people?
2. What are their goals and motivations?
3. What are their biggest pain points?
4. What tasks are they trying to accomplish?
5. If this design project builds upon existing work, what is its current state?
6. What are some comparable designs or products?
7. What are the goals of the design? What problem does it solve?
8. What are the constraints?
9. What is the design optimizing for? What would success look like?
10. How should people feel after using the design?

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:

1. All engineers have an opinion and ideas they want to contribute: some are just louder than others. Your job as a designer is to bring engineers into the design process and coax feedback out of them so they feel involved and are fully invested in the ultimate outcome, just like you are. Not just willy nilly involving them either: you have to actively involve everyone and not let the loud engineers drown everyone else out as there is always a spectrum of introversion among peers. Keeping this balance is easier said than done, and definitely takes practice.
2. Relatedly, you’re not just involving your team just so they feel good about themselves. Product design is complicated. Knowledge that will guide you to the right solution is distributed, and the team you work with holds a lot of that knowledge such as a deep understanding of the technical constraints. They also possess different perspectives that can help you think of solutions you wouldn’t have thought of on your own.

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