The Battle of the Product: Communication in the Design Process

UX DesignMarcin Treder • September 29, 2013 • 8 minutes READ

In this article Marcin Treder of UXPin – The UX Design App explains the principles of optimizing design process and spreading a design-centered culture across the organization. If you want to learn more on theory and practice of delivering remarkable experience with any product, download free UXPin’s ebook “The User Experience Guide Book for Product Managers”.

So you want to build a great product. Something that people will be obsessed with. Something that people will love. But are you obsessed with those people? Do you love them? The energy of a great product won’t generate itself.

I might sound like a madcap, but in reality those are the questions that are extremely crucial for the whole product development process and you’d better take them seriously. That’s my friendly advice. Without obsession and love, the user experience design will be lukewarm at best and the success of the product will be in question.

UXPin as a product and as a company is the result of pure obsession with the problems of the user experience design process and love of the design.

But that’s more of a starting point than the road itself. You know that products don’t grow on trees. Even the best apple if not placed in the context of eating or as a part of a recipe for a delicious apple cake, will be painfully meaningless. And the apple itself won’t even be close to the desired level of tastiness if somebody doesn’t spend quite a lot of time nurturing it.

I bet that in a professional apple orchard a whole team of people is working on the apple tree so it will be able to reach its full potential – giving the best fruit in the world.

Oh yes. There’s no great user experience without love and obsession. There’s no efficient product development today without multidisciplinary teams. And there’s no great multidisciplinary team without outstanding communication in the design process. Communication that is planned and brutally executed throughout the design process.

And no, it’s not easy. In fact it’s far from easy. A design usually generates extreme emotions. After all that’s something that everyone can refer to. It’s tangible, it’s facing you and it seems to be obvious. That’s an explosive mixture that must be properly handled. And that’s exactly the job of a Product Manager.

As a Product Manager your goal will be to:

• spread the design-centered culture across the organization
• optimize the design process through facilitating proper communication
• include and engage each and every team member in the design process

Let’s try to understand how to do it.

The rules, the rules are on fire

The first rule of communication in the design process is… there are no rules. Best practices may guide you, provide a starting point, give a broader context to your own situation, but will never (never!) answer all your questions and give a ready-to- implement solution.

Why?

Simple. Because communication (prepare for a painfully obvious statement) is an interpersonal process that almost entirely depends on the people that are participating in it.

If you want to optimize the design process in your team, start with careful observation of the team that will lead you to a conclusion about their communication needs. Some people require more of a conversational style and some prefer a predictable structure of communication that will leave no doubt about requirements and next steps.

Since your goal is to include and engage everyone in the design process you cannot exclude anybody from the communication. That’s why crafting the communication process specifically for each team is so important.

The structure that I’ll present below is something that just recently started to work for UXPin. It still needs plenty of improvements and testing, but it seems to be going in the desired direction. Hopefully, just by reading about the process of forming communication patterns you’ll have a couple of ideas about improvements for your own team.

Pre-product phase – working on the experience jigsaw

I bet most people think that the design process starts when drawing takes off. Nothing farther from the truth. The design process starts exactly when there’s a decision that something in the product (or the product itself) must be done. Formulating the business objectives, the customer development process, defining the scope of a project – these are all parts of the design process, just as wireframing and prototyping are. Although this broad definition of the design process is a counterintuitive statement, it is very important to present it as such inside your team.

Explaining the connection between design, user experience and business objectives should be the foundation of your product development process. It doesn’t only show how important the design is and why the whole team should care about it, but also immediately engages them in the process and that’s our goal.

That’s why in the pre-product phase we organize a meeting for the team at which we discuss together:

1. What the experience goals of the project are (in other words, what we are doing for our users
2. What the business objectives of the project are (how the business should be affected
3. What we know about the problems of users and how we can improve this knowledge
4. What the current scope of the project is (what we know at the very beginning that should be done)

Number three is especially important and I’d like to share a remark with you. Of course this is the part of the process when we’re conjoining our analytical results, interviews with customers, knowledge from previous projects, etc. That’s probably very obvious. Something non-standard that we’ve learnt at UXPin is that our customer service team should take an active role in every project. They know more about the problems of our users than any of us. Their role is absolutely indispensable.

In a recent project of redesigning our dashboard this pre-product phase was started by gathering all the knowledge that the customer service team had been considering for this part of the product and grouping it into meaningful chunks. It helps us better understand what the challenges are that we’re facing and the opportunities.

That’s exactly why you want to engage the whole team in the design process. Suddenly, the opportunity for the success of a project grows to an enormous size.

Democratizing the design process is the way to go!

And yes – a really important thing is to start with a meeting, not an e-mail exchange. Build the communication based on a common understanding of user problems and the product development process that you want to introduce.

Communication on the run – design feedback loops

When you have the first meeting behind you, it’s about time to move farther down the road. What happens now is all project-dependent. Sometimes this is the time for a usability study, sometimes some customer development work is necessary (customer interviews) and sometimes your UX Designer moves straight to the wireframing phase. One thing never changes for us. Each stage is reported to the whole team.

If we’re doing the usability study, we explain why and how to the team. If we’re wireframing, we share the project with them in UXPin, so they’ll be able to see how this part of the work gets done (thanks to our google docs like live collaboration) and they will be able to contribute to each stage.

Multidisciplinary collaboration must be constantly facilitated in the team. You want to have a team that naturally communicates within itself and deeply cares for user experience design. There’s no other way to this point than through sharing the whole design work and inviting others to share their ideas.

I’ll give you a personal story.

When I started my career in User Experience Design, I was convinced that the key to my success would be establishing the highest possible role of UX in the organization that I used to work for. And I was thinking about my role (damn, I must have been annoying). I was eager to fight for the good name of design with the whole developer-driven company. And I did. Unfortunately, the result was far from my expectations.

As a young and aspiring user experience designer I was a part of an IT frontend team and… my work was always fiercely questioned. No wonder that when I joined the company as the first UX Designer their world was shaken. Somebody was messing with their product development cycles! No matter whether I delivered wireframes or prototypes or results of usability testing – the developers remained unaffected. I was anxious.

They believed that technology is what matters while interfaces are a kind of ornament decorating what, for them, either way, was beautiful code. And since analytics was business-oriented (instead of being user-oriented), they didn’t even know exactly what worked and what didn’t in their products. I just couldn’t stand it.

It took me a couple of months and lots of nervous breakdowns to realize that fighting was futile. Endless discussions over the role of design in product development weren’t leading to any reasonable results, because fighting always

comes up against resistance. If you instigate a fight, expect your ”opponents” to defend their positions. In a company that wants to create amazing products, constant fights with other departments and specialists are just silly. Dangerously silly. They waste time that should be used for developing products to solve the real- life problems of users.

Finally, the Product Manager advised me that there’s no point in fighting. The only reasonable thing is to engage engineers in the design process.

Gosh I needed a lot of time to digest that. When I finally did, we all started to work together. My friends from the frontend team were invited to participate in planning the process, advising on the interface, watching usability studies, etc.

The result for the final product was mind-blowing.

Final advice: collaborative design takes no hostages and leaves no man behind.

What does it mean? It’s quite simple:

• You won’t take any hostages if you ensure that you convince people that they are needed in the design process even if they are not designers.
• You won’t leave any men behind if you welcome everybody in the process. And yes I actually mean everybody.

As a Product Manager it’s your responsibility to facilitate open collaboration in the design process and constant knowledge sharing.

The Decision Day – final frontier

Finally, at the end of the project you will face The Decision Day – a day in which the whole team must decide to go with one option or another. To launch, or not to launch, to pivot or not to pivot, etc.

That’s the day on which you’re pushing the ship into new directions.

The easy way is to decide on your own, ask people to do that and wait for the results. The hard way is to, one more time, play with teamwork.

The way we do it at UXPin – the team sets the final frontier for the project. The team must review the whole project and answer one question asked by our Product Manager – is this the best thing that we could do? If all are in favor, we ship the code to production.

That admiration of quality and of achieving our personal record of great user experience – lays at the heart of the whole product development process. Great products are created by great teams with great leaders.

Spreading the design-centered culture

In today’s design-oriented world, great Product Managers are fighting for process efficiency. The road to efficiency goes through the collaboration of people with different perspectives and experience in one multidisciplinary team.

As a PM your deepest concern should be to make great user experience design possible for each project (in the short term) and for the whole product (in the long term).

If you consequentially enhance communication and collaboration in the design process, your projects will not only attain better results in less time, but also the whole company will reach the much desired level of a design-centered culture.

This culture cannot be artificially built. It must be a result of constant care for the product.