Collaboration between Designers and Product Teams
Yes, you’ve read it right!
If you work in a product team or in a digital business, you’ve probably heard a lot about this topic, or might even have lost some sleeping nights due to the lack of it in your daily basis. I think that there is no doubt whether designers and product team should work together and if both of them are essential to achieving great results. This is common sense (at least should be). The real question we struggle to answer is: Why is it so hard to happen in a smooth flow and be something we do not even need to talk about? I have some thoughts about this and I will share with you in the following article.
Different ways of thinking in the workplace
Working with somebody that sees things in a very different way than you do must be taken as a constructive challenge, not as an issue. Having good discussions with different points of view and no pointing fingers is great for doing a good job. The hard thing is that, if you really want things to happen that way, it demands a lot of empathy and also knowledge about yourself. And when I say empathy and knowledge about yourself I really mean it, deeply. Know our background and things that make us who we are is a task harder than you think. It seems pretty obvious that designers and product teams have different ways of thinking, but have you ever wondered why? Nobody is meant to be a designer or engineer as soon as he is delivered from his/her mom’s belly. We are all born human-beings, with some characteristics already inherited from our parents/grandparents and they do matter shaping our personality. However, the choices we make throughout our lives and how we deal with the problems we face are the ones that really shape our character and how we see the world. A designer, for example, may have been interested in arts as a kid and loved to exercise his creativity. An engineer, on the other hand, is someone who may have been interested in math and loved to find solutions for problems. I might be stereotyping a little bit, but this is just to clarify why sometimes it is so hard to reach an agreement with someone who is so different from ourselves. This is just the tip of the iceberg and I will give more examples in the following topics.
Duncan J. Watts’ book “Everything is obvious: *once you know the answer” is a very good read if you want to dig deeper into human behavior and psychological differences between humans.
Education and working skills
So, well, you decide to work as a designer and go find formal training to get your first job, that’s great! Here are some things you are going to learn from day one:
- Think problem first, not solution first;
- Have empathy for your users, try to be in their shoes;
- Whenever you design something, test it with users;
- You are not your users, so your opinion on what works best is not the rule.
All those lessons are great and I agree with all of them, but let’s now take a look at an engineering training.
You attend to your Computer Science undergrad’s first class and the teacher asks you to:
- Study programming logic;
- Study Object Oriented programming principles;
- Find the best algorithm to solve a specific problem.
So, have you noticed a slight difference between those educational backgrounds? It is one more way of blossoming those differences of thought among people. Things just get worse while working. The main job of a designer is to find the right problem to solve (no matter how much time or effort it takes), the one that is going to make users want to use the product developed by the product team to address this need. Once this problem is established, the product team has the goal to find the best and fastest way to solve this, choose the right technology, develop the best algorithms and a scalable solution with the less amount of effort and time possible. In the meantime, another thing happens and is the next one I want to point out:
Metrics means different things for designers and product teams
One who has already been in an agile environment is aware of agile team metrics, such as the burndown chart, user stories lead time, story points delivered per sprint, the CFD diagram and so one. If done right, they can tell a lot about the team and help finding improvements or even help to estimate how much time it takes to develop something new. While the product team is looking for ways to improve its metrics, designers are trying to design a new onboarding flow that decreases the user quit rate, or a new flow that reduces the time needed to accomplish some task. All those metrics matter and you shouldn’t think otherwise. Trouble just comes up when they happen to be mutually exclusive, and this happens a lot.
Expectations that does not match
Talking about mutually exclusive metrics, it comes to my mind also what’s behind them. Why designers measure such things? My point of view is that they expect long term outcomes: Having great reviews in the app store, creating something innovative, shift the way users used to do something. They don’t really care about the outcome of each team’s sprint. The product team, on the other hand, expects to improve its metrics and have a faster lead time, so that they can release features and products with an excellent time-to-market. They know that the outcome of each sprint is an opportunity for learn something. So the team expects that designers understand this and deliver the prerequisites for the team work.
All that being said, you must be now thinking that designers and product teams came from different planets and they are fated to not be able to collaborate. I would say no, indeed no. Deep inside, designers and product teams share many goals, but they often don’t come to the table as a shared interest, that’s why I call it “Hidden similarities”
Hidden similarities between designers and product teams
The picture above shows the UX Umbrella, and it is possible to see some roles of people that are usually inside product teams. How a product experience can be good if the front-end developer has chosen a programming language that does not support the animations proposed by the visual designer? Or un the other way round, the product team works with a legacy product that does not support heavy visual design and the process of migrating the code is long. What is the point for the visual designer to focus on animations and perfect micro interactions in the short term?
This last sentence is a good example for short-term outputs x long-term outcomes. It is not something bad when designers envision long-term outcomes and product strategy, but product teams need to break this vision into short-term outputs so they can do small pieces of work that will eventually achieve this long-term vision.
At last but not least, I strongly believe that none of us has won the sperm race to be here on earth doing something we are going to be ashamed about. If you disagree with me, maybe your company has hiring problems. So, when you, product team member, is talking to your fellow designer our vice-versa, try to keep this in mind.
Those similarities leads us to some key success factors that, in my point of view, dictate whether you will be able to reach this collaboration or not.
Key success factors for collaboration between designers and product teams
- Working (actually) lean
Working lean means you will have cycles. So it is pointless to be stuck in the think part or in the make part, you have to commit yourself to go through all the steps, regardless the one you like the most. All those steps must be time-boxed and measured. Designers must hold their anxiety to see that long-term vision implemented and trust the product team that its short-term iterations are the best way to achieve long-term results. This kind of anxiety can be explained by a human cognitive bias called “Hyperbolic discounting”. We tend to attach ourselves into something in our hands instead of something that is yet to come. The product team must not fall in love into a solution already developed, changes are going to happen in the process and they are normal. Our world is dynamic, user’s expectations changes on a daily basis and we need to adapt ourselves. There is another cognitive bias called “Commitment Bias” that explains this. Both designers and product teams must reach together a conclusion about what is the less amount of work that can generate the highest value.
2) Foundational research can’t be a block in the process
Products with no meaning tend to be a huge and fast failure. One of the techniques to reduce this risk is to have good foundational research, with user interviews and market research. However, this process can’t last forever and/or block team’s work. Designers must organize themselves to do this during some project setup step or in parallel to their work with the team. I know this gets even harder nowadays, we are exposed to a huge amount of information that is close to our hands, so the feeling that the perfect research could have been done if we had one more day to do so is hard to avoid, especially for creative minds. This is when the “Paradox of Choice” comes to the table. The double diamond is a good framework designers can use to know when to discard hypothesis and move on to the next one without getting stuck into the same question again and again. I would also suggest designers can have a cup of coffee with some engineer friend and ask how to be more focused on solution :)
3) Iterations of the product team
Iterations of the product team must not be all about measuring burndown charts and story points. The team must ask itself if the product is still solving a user’s real life problem, if real value is being delivered and even if all product’s features are worth to be kept alive. The Pirate Product Metrics (AARRR) from Dave McClure can help the team answering those questions. The team can also talk to designers and learn more about empathy and being in the user’s shoes :)
4) The Product Manager
With all the things I pointed out here, maybe this picture does not need subtitles. If there is somebody who can facilitate work between designers and the product team is the product manager. Product Managers are the ones to understand about UX, Tech and Business, but not being a specialist in none of them, though. This gives to the Product Manager the ability to understand both designers’ and team’s expectations and coordinate activities towards a common goal.
5) Business Leadership
Business Leadership might hurt someone’s ear, but it is essential to have leaders that pay close attention to this collaboration and try to facilitate such dynamic of work. It is not about bossess trying to impose their opinion, but people with experience and sensibility to help designers and teams achieve their results.
I hope this article gave you insights on how to improve your work and how your team or company structures itself to do the job. Collaboration between designers and product teams is a hard topic and there is no silver bullet.
Have any thoughts about it? Like, comment and share!
