How to talk about design in the agile world

How we improved design communication in the Retail Ops Team

With an agile and lean approach, most of us here at Zalando changed the way we build digital products. Design processes also evolved,  with  designers usually working alongside cross-functional product teams.

But, at first, one thing did not change too much: how we talk about the design.

Many organizations still believe that a designer is a salesman; that having the ability to convince others that their ideas (products) are ‘good’ or ‘great’ is the key skill. Yes, it is crucial for digital agencies, but you need a different approach when you are working in a cross-functional team. You must be a great Connector, focused on teamwork.

So how do we do it?

Convince others to participate in design

Let’s face it: designers do not own the design process.

In agile/lean-oriented teams, if you try to keep the design to yourself, you will be challenged or ignored.

To prevent that, ask others to join you in the design process. **Instead of being the owner, be the host of the design process.

**How does it work in our teams? All team members (developers, product specialists, customer care, etc.) can participate in research, design workshops or propose ideas and changes. Designers, Product Owners, and Developers — everyone can participate in the design process. But there is a catch; everything is prepared and driven by UX specialists.

This cross-functional approach will enrich design solutions with better business or tech input. What is more, it is much easier for team members to accept the design outcome — it is their works as well.

Unfortunately, it’s not as easy as it sounds.

Collaborative Design: Day 1

Managing the design process properly is hard. Managing it with non-designers is even harder.

People try to solve things their own way, get distracted by other activities, do not understand some of the design methods, or do not believe in the efficiency of those methods.

How can you deal with it?

Establish Design Rules

First, define your design process. Document it in a clear way and share it with your teammates. Do the same with your design toolbox — create a list of your methods with a clear description of every activity.

Ensure that they understand and accept the way you want to approach design. If there are any doubts — be open to dialogue and finding a common ground.

Make Clear Who Is Responsible for the Final Decision

Be honest about it.

Do not pretend that your decisions are democratic if they are not. It will not save any problems and may lead to frustration in the future.

Usually, the CEO or PO is responsible for a product and its potential failure so they make the final decision. Yes, it might be disappointing, annoying, even unfair. But this can, in fact, improve your position so long as you've had the opportunity to make yourself heard.

In a previous role of mine, we were dealing with a Product Owner who was changing design decisions without informing the team. We accepted that — as a PO — he had the right to the final decision, but we still wanted some clarity and transparency. We asked him for a confirmation email with all his changes, which in this instance worked! The PO preferred to find a solution that was accepted by the whole team. We felt heard, our input was considered and decisions were made with this in mind.

Focus on Informal Communication

Keep the number of scheduled meetings to a minimum. People usually have too many appointments on their calendars already. Replace meetings with short, single topic, informal chats.

Do not keep design artifacts to yourself. Share them with the whole team as soon as possible, and allow them to check them whenever they want to.

Be physically available for the rest of the team. Communication between people increases drastically if they are able to make eye contact with you. Be open to having a discussion whenever teammates need it. Yes, it can be inconvenient at times, but it will help you earn the team’s trust.

Draw

Try to make your communication visual. Drawing is a universal language, understood by people with different backgrounds.

Designers are considered as visualization experts, which will help keep control over the design process.

Wall behind my desk — we are trying to create visual artifacts for every design discussion

These changes are best demonstrated by yourself. Do not talk about design without having something to draw with in your hand. When a team member suggests any idea, answer: “Okay, let’s draw it!” You can visualize every problem, process or idea (including “non-visual” topics, like voice interfaces).

Finally, enrich your design toolbox by techniques that require team drawing (for example, a Design Studio Workshop or Storyboarding).

Separate People from Their Ideas

It's a common scenario:

People in a team have different ideas about how to solve a problem. Everyone has a tendency to think that their ideas are the best. They get attached to them. Things get emotional and people want to show that they are right.

When it happens, teams have a tendency to support ideas that:

• belong to a person with a higher role in the organization (HiPPO — highest paid person’s opinion),
• are presented better.

To avoid this situation, you need to separate people and opinions.

Start by drawing. When you move the idea from a person’s mouth to a sheet of paper, the solution becomes more independent. People sometimes realize that their idea on paper is not so attractive anymore.

If you have a little more time, you can try a solution promoted in a book I recommend, The Sprint. The author proposes that everyone prepares their design proposal separately. Afterwards, all ideas are presented and validated without revealing the author.

Define Clear Discussion Goals

Our design team started design critique sessions. At the beginning it was a disaster — every design was torn apart by hundreds of comments, all of which were more or less accurate. It was not only unpleasant but it was also ineffective. We generated long lists of errors without too many ideas on how to solve any of them.

We decided to put more structure in our design discussions. Here's what we do now: before a talk, we write down:

• What we want to achieve with this design,
• What kind of feedback is expected / What should the outcome of the discussion be.

Sounds simple, but at the time, it was a big change — our discussions became more structured, efficient, and now have a clear outcome. It also helps to quickly drop all discussions that are not leading us to a desirable conclusion.

Typical feedback session

Do Not Criticize

When we focus on generating solutions, we do not criticize at all. Others are then encouraged to share even the craziest idea. It also makes the process much more efficient.

This is something we learned from a Google Team we collaborated with from Hamburg on the Google Assistant Gift Finder project. During a workshop, we focused on generating as many different ideas as possible and chose around ten that were the most promising. They suggested we comment only on the things we liked and just ignore the rest.

We had a similar task a few weeks earlier, but we included criticisms. In the end, we had similar outcomes but it took three times longer.

When you focus on the positive and negative sides of every idea, it often starts a long discussion. Yes, sometimes it helps to rule out unrealistic or naive ideas, but with proper processes, those ideas will be ruled out anyway.

Change Critique into Questions

It is hard to ignore doubts when you are trying to choose the best option. Choices become clearer when we ask questions.

Example: Instead of “This button should not be here,” we ask, “Why did we decide to place this button here?”

Sounds subtle but it changes a lot. It starts the discussion. The presenter must explain the reason behind decisions. If we are not sure about an explanation we can go deeper with further question.

The goal is to reveal the whole process behind decisions. We unearth not only potential errors but also illustrate the process that leads to choices. And if we know this, it is much easier to come up with proper solutions and fix problems.

What is more, if you are preparing a design you need to be prepared to explain “why”. It makes our solutions more mature and well thought out.

Conclusion

What did we learn from our experiments with communication in design? Our design meetings require less time and have a clearer outcome. It is easier to communicate and reach an agreement with other designers, developers, and product specialists.

The proper design communication also limits uncertainty. When the team believes that design decisions are right, work is more efficient. This leads to providing a better product at the end; a win-win situation, you could say.

We're hiring! Do you like working in an ever evolving organization such as Zalando? Consider joining our teams as a Frontend Engineer!