The Evolution Of The Design Critique At Pipedrive

Inês Louro at UXDX Community: Europe South. Video: https://www.youtube.com/watch?v=suO0i5qn_G0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What a design critique is

[00:00:00] Hi everyone, and thanks for watching. Also, thank you to UXDX for inviting me today. I'm going to be talking about this exciting topic, which is design critiques. Before I start talking about it, I would like to say a few words about myself. Hello, I'm Inês. I am Portuguese, I'm based in Lisbon, and I'm a product design lead at Pipedrive. I've been at Pipedrive for almost four years now, so it's been quite a journey.

[00:00:25] I'm really looking forward to telling you the story of how we mastered design critiques from day one. Unfortunately, I'm not going to be able to tell you that story, because that's not how it happened. So what are we going to cover today? We're going to have a look at the definition of design critiques, why we do them, how we can constantly evolve them at our organization, and some possible pitfalls and solutions.

[00:00:49] A design critique: I think by now most of you who are watching are already doing them in your organization. That's great. But perhaps some of you haven't had the chance to introduce a design critique in your process, or don't really know how to go about it. That's OK. We're going to cover the definition, the value, how we can start doing it, and some practical examples.

[00:01:15] Let's start with the definition of a design critique, what it is to me. If you read it: a design critique is a safe, recurring and structured session of analysis, with the objective of improving design towards a goal in a collaborative way. I know this sounds very long, but hopefully it is clear.

[00:01:43] Some of you are probably wondering, OK, isn't this what I do in my day-to-day? For example, when I'm in the office and I turn to my colleague next to me and I ask, hey, can you have a look at my design, is it better than yesterday, can you give me some feedback? This is different. It's not the same as the daily, organic, healthy feedback that you have in the office or with your team. It does not replace those sessions. It does not replace usability tests, or even heuristic audits or evaluations. If you look at the definition, it's a little bit different, and we don't want to replace these ceremonies with design critiques.

From feedback and critique to a safe session

[00:02:18] If we focus on the word critique, we might be associating it with negative criticism. That's perfectly normal. At Pipedrive we actually started with design critiques first, named it critique, then review, then we changed it to critique again. Let's have a look at one of the first slides that I used to show my work and to ask for feedback. It actually says "feedback and critique session." How confusing can this be? I know why I decided to put feedback before critique: it was to encourage some positive feedback as well. I didn't want it to be just negative.

[00:03:11] So I have my presentation ready with this lovely first slide, and I'm sitting there totally comfortable and feeling confident about my work. And this is what I look like in the recording. Oh my god, it's totally the opposite. I'm sitting super straight, I have this fixed smile on my face, my body language is weird, and I'm probably panicking right now, just thinking, please be gentle when criticizing my work. This is not how it needs to be. A critique can be fun and totally safe.

Why we do critiques

[00:03:49] So why should we do it in the first place? Ultimately, because we need feedback from others to improve our designs. This is logical. We're not experts at everything. We have different knowledge, different perspectives, so we really want to encourage everyone's participation and collaboration in building a better product. It's important for the product, because we are encouraging consistency through continuous iterations.

[00:04:26] It's also good for the team, because we're not only contributing with our own area of knowledge, but we're also gaining more knowledge of other areas, and we're working on team bonding. For the presenter it's great, because we're building more confidence in what we are designing. For the organization, it fosters a collaborative environment. We all want to work at a company that fosters this type of culture, where we all get to work with different roles and different people, and we're all building something in common, and also a shared language.

[00:05:03] Also, this is important: we are so lucky that we can be doing this with all these lovely colleagues, professionals and resources. Sometimes when we interview designers, they're looking for the next challenge because they are lacking this feedback. And we know we need this feedback and critique in order to grow as well.

How critiques evolved at Pipedrive

[00:05:16] So how did we start doing this at Pipedrive? When I started in 2017 we were more or less 15 designers, and right now we're more than 40. So we grew a lot. The company grew, and so did the processes. Our first design critique was an open session. It had all the design team in there, and also researchers, who were part of the department. The problem was that the format was not well defined. It was an open session. Everyone would join and show things if they had something to show. One of the problems was also that they were showing just the pixel-perfect stages, just before the handoffs, and this is not something we wanted to encourage.

[00:06:08] Then we wanted to create groups, so it would be more focused, more continuous feedback. The problem with this is that we had silos. Why? Because the teams were organized either by proximity of the area of the product they were working on, or by location. So of course we were having these silos. And for the people who were joining these sessions, say Lisbon has a session on a Monday and other teams come and join the critique on a Monday, it was very hard for the critiquers to give feedback, because they were lacking context.

[00:06:49] Then we changed the format again, because we wanted to avoid those silos. We opted to have buddies with each designer. And again, the session would have everyone, so we would know again what we were all working on, and at the same time we were ensuring that the designer had continuous feedback through this buddy. You would pick a buddy, probably someone who had some sort of expertise in a particular subject, so the buddy could change depending on the project.

[00:07:31] We also introduced more rules. We had to prepare an agenda in advance, so we had to know the day before that we were presenting. The buddy would have priority in giving feedback in the session, and we had a moderator really paying attention to the times. This was not optimal, because not everyone was getting a chance to participate.

The critique of the critique

[00:07:43] We knew this, and we decided to have the critique of the critique, following a standard retrospective format: what went well and what was not working. We came across a lot of positive feedback. This was working for designers. They were feeling confident about their work after these sessions. They would get feedback, for example, from the design system team. They were feeling that they were influencing the designs. They were getting that overview of what we were doing, and we were ensuring design and experience consistency and coherency.

[00:08:31] This is great, but there was also something that was not working that well, and we had to pay attention and listen. It seems that we were still only showing polished results, and it was requiring a lot of effort during the preparation phase. Some designers did not have a voice. Sometimes there was just not space. And a lot of critiques were being cancelled, which is not a good sign, of course. It wasn't a nice environment. It felt really hard to be receiving that negative feedback. It wasn't clear when we should be presenting our work, and it felt like a review: yes, you're going in the right direction; no, you're not. We didn't want this gatekeeping.

[00:09:10] So what did we learn? We learned that we definitely had to work on new guidelines and a new format, and we wanted to pay attention to four aspects. When it comes to cancellations or poor attendance, we wanted to make the goal and the value of the sessions very clear, and that they were going to be not optional, and recurrent. When it comes to having those extroverts in the room, or giving priority to senior designers to speak, we don't want it to be like that. We want to facilitate the session and pass the mic.

[00:10:04] Regarding the pixel perfect, or "it's not ready yet": we want to evaluate the whole design process. We want to catch things early. We want to fail fast. So yes, we wanted to see not just the pixel perfect. And when it comes to the unhealthy etiquette, it needs to be a safe environment. We really should be working on how to receive and also give feedback to others.

Preparation and facilitation

[00:10:30] Now we're at the stage where we have these phases in our critique at Pipedrive, and for each one of these I'm going to talk about what you can do to make it run smoothly in your organization, in your groups: preparation, facilitation, presentation, critiquing and following up. Just for you to have an idea: we are spread across several locations in the world, and we have several design groups in our department. My design group is more or less eight people, and our critique happens every week, once a week, for one and a half hours. And this is how it goes.

[00:11:09] It's really important that someone takes ownership of this session. It doesn't need to be your design operations manager or your team leads. It can literally be a designer looking at how the session is going to look, because you really value everyone's time and you want it to be effective. If you like organic, invite people and make sure you pass the mic: you have half an hour or 45 minutes to speak in this session. Or you can opt for a more dynamic way of doing it, for example in Miro, using a quadrant with likes, dislikes, critiques, using your post-its. Just make sure you have a format defined.

[00:11:58] And invite your audience. In our design group we already have the calendar invite, we know we're going to attend. But you might need feedback on something else. Maybe you would like to invite a design system designer or a content strategist, so make sure that they are there. And prep your artifact in any fidelity. Remember that we want to evangelize the whole design process. It's really beneficial when we learn from others how they're working, so feel free to bring a problem statement, your initial flows, low fidelity, high fidelity, prototypes.

[00:12:43] When it comes to facilitation, it's really important to keep it time-boxed. We always start our sessions, again in an organic way, by asking who has things to show today. In our session, because we have one and a half hours, if we have three people, it's half an hour each. That's very easy. Sometimes there might be more people wanting to present. That's OK: you can use t-shirt sizes, asking how complex a project is, so you can adjust the time in a smarter way.

[00:13:09] And feel free to say, I'm sorry, your time is up. Actually facilitate. I cannot stress this enough. This is important to me because there was a time in my team where I was not cutting people off. Sometimes in that half an hour, the last five minutes are the most interesting ones and the most fruitful for the designer who is presenting. But it's really important that you do it and that you keep it time-boxed, because this is actually expected and it helps bring structure into the session.

[00:13:49] These are some of the things that can help you facilitate. You can say, OK, we will now present in this order, and you say who will go first. After someone presents, you can say, OK, let's start with the questions round now. This implies there's going to be a round of questions before the actual feedback. And feel free to say, I'm sorry, but this is not related to what was asked, would you like to ask something else? This happens when there's a derail in the critique.

Presenting and critiquing

[00:14:29] When it comes to presenting, it's super important, before jumping straight into the mocks or the solution, that you share context with the rest of the team. Share the goals or the pain points you're working on, and it could help to use a simple user story. This is also a good time to bring any research or data you might have. Keep it focused. Remember, if you have half an hour, you have half an hour to present and also to receive feedback.

[00:15:02] At the end of presenting, repeat what you would like feedback on. Keep it focused too, because we are designers and we will want to give feedback on every single detail. To make it more effective for you, and for you to get that actionable feedback, repeat the one, two, three things you would like us to comment on.

[00:15:29] Whilst critiquing: don't ruin other people's days. This is one of our Pipedrive values, and it's a simple one too. We want to create a safe environment. We want to give constructive feedback, not destructive. We want to listen more than we speak. We have to make sure that everyone has a voice in the session whilst providing feedback. And talking about a safe environment, people perceive us in different ways, and our words are just a small bit of it. So be attentive to your tone of voice and also your body language.

[00:16:11] And feedback: this is a very well-known format on how to give feedback. This is to avoid the "OK, this feels like a slap in my face." We want it to be safe, we want to come back again next week, and we really want to see the value in this session. It's good practice to use a sandwich format, for example, when giving feedback. Start with a positive, then negative or constructive feedback, and then positive again.

[00:16:40] And then we really try to give feedback through questions too. What does this mean? These are some examples, and these are guidelines too that help me give feedback. The why, for example: why did you think this was a good idea, or why did you pick this color? It will invite defense, because the other person will start replying with "because," already trying to justify. So we prefer the how or the what. If you ask, how did you choose this entry point, it invites a methodology. What was the reasoning behind it? Have you considered?

[00:17:21] And keep in mind that we're not criticizing the designer. We really need to keep it focused on the goal, on the problem, and also on the user. Do we know if users might find the goal difficult, because... These are some guidelines that might help you give feedback in this session.

Following up and checking your critiques

[00:17:51] When it comes to following up, just a little bit of good practice: keep the recordings. Whilst we're presenting, we're probably not going to be taking notes, so it's good to go back and watch the recording, and document your decisions. This does not mean that you need to change the design straight away. You can take it to your team, you should take it to your team, and make a decision together. But document those decisions, and then share them not only with the team but also in the next critique: what happened, what did you change, how did the discussion with the team go.

[00:18:27] What would be lovely is if you got to ask these questions, if you're already doing critiques. Are they working for you? Are you getting actionable feedback? Is there effective facilitation? Is there a common understanding of the goal of the session? Is everyone participating? Does it feel structured and safe?

[00:18:55] And remember, we must show our work to be appreciated and to grow. We'll only expose ourselves if we are in a safe environment, but it's super important in order to grow, and for people to recognize our work. We all want to be recognized, and we want to help every team member become a better designer. And isn't everyone a designer? So let's embrace that thought, that everyone is a designer, through these collaborative sessions, and share what we know, and also work and contribute to a better product.

[00:19:37] At Pipedrive, maybe our next step will be to start inviting other roles into these recurring sessions, but maybe you can start doing that now. Thank you. I hope this was insightful. If you have any questions, or if you would like to share how you're doing it in your organization, please reach out to me. Here are my contacts. Take care.