Designing The Design Critique

Gianni Clifford at UXDX Europe. Video: https://youtu.be/DC5K0-X9TyQ

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.

Introduction

[00:00:00] Hello, everyone, and thanks for joining me today. My name is Gianni Clifford. I'm a product design manager at Zendesk, and I'm going to be talking about designing the design critique, or in our case, how we redesigned our design critique. I think design critiques are really important, but never more than now, in the world we're living in, with people working from home and many people being remote from the office. I am going to talk about how we overhauled our design critique, but if you're not doing a design critique yet, I think the same lessons can still apply to how you get one off the ground for your team or in your office.

[00:00:39] Thanks to the UXDX team for inviting me back. I talked last year about UX research, and the talk seemed to be really well received; I got lots of really positive comments and questions coming into my LinkedIn. I think the main thing I tried to do then, and I'm hopefully going to be able to do again, is really pull the curtain back and show how we actually go about these things. This is going to be a hands-on, step-by-step kind of talk, and hopefully there are real things that you can take away from it and apply straight away to your team or to your design critique.

[00:01:18] Before we start, let me quickly introduce myself. My name is Gianni Clifford, a cinemaholic [?] design manager at Zendesk. I've been here about two and a half years, based in Dublin. I'm from North Dublin, really proud of that one. Before I was at Zendesk, I had a startup called FillIt, which I did for two or three years, and before that I worked in many different design studios and agencies across Dublin. So that's about me.

[00:01:52] Let me give you a steer on what exactly I'm going to talk about today. First of all, I want to touch on why we would do a design critique and what a design critique is. Then, to give you a little bit of background, I'm going to talk about the problem that we had with our design critique; maybe you'll see some similarities with your own team. And then finally, the solution that we deployed and how we overcame the problem that we faced.

What a design critique is, and isn't

[00:02:24] The first thing: when I was preparing this talk, I Googled critique as a word, and I found that really interesting, because what came back to me was "criticism" and "criticizing." These are the words that really stood out to me in this dictionary definition, and essentially that's not good. Those words come with a lot of weight, and they don't seem very positive. But a design critique is actually a really positive thing. Sometimes people can be uncomfortable in design critiques, and it's fair to say that the process of giving critique and giving that strong feedback is a muscle, and it needs to be flexed. That's something I'm going to try to cover: how we went about resolving that as an issue with the team.

[00:03:12] This is not what we want any office to look like, even if we were back in an office. It doesn't need to be this kind of fakeness; it just needs to be real. I think team members can have radical candor, as Kim Scott would say: how do they give that feedback to each other? And we're not even in offices anymore. A lot of people don't have immediate plans to go back to offices, and I think the world looks a little bit more like this: nine Giannis working on a call. But even in this remote world, I think it's more important than ever that you're getting your team together and people are giving each other feedback, supporting each other, giving that critical feedback to keep the whole design work on track, and being mindful.

[00:03:56] Zendesk is a big multinational company. We have designers all over the world, but people are in different time zones, in different seasons, and they have different personal situations. So this talk is not just about remote; it's about the solution we came up with, and about that solution being flexible: flexible in the remote world we're in now, but equally flexible so that when we go back to our offices, the same solutions will apply. It's been a really good example for us that when we went into this new remote world of working from home, our design critique didn't stall. It just continued as normal, really positively, because we had that flexible solution in place.

[00:04:49] Wait a second, you're talking a lot about design critiques, but I don't even know what one is. What is a design critique? Really simply, it's an opportunity to bring your designers and team together, with some cross-functional people, to give feedback and discuss designs, ideally before the designs are actually built, because then it's going to be too late. The earlier you can do a design critique, the better, but it depends. You can do a really early design critique with pencil-and-paper sketches, or a much later design critique with a higher-fidelity design. Those are slightly different things, and you'd expect the presenter to be looking for different types of feedback on a high-fidelity design versus a low-fidelity paper sketch, but they're both equally valid. It's good to get the feedback in early and often.

Why we do design critiques

[00:05:44] Why do we do design critiques? There's the obvious reason I just touched on: it's going to make the work better. But I look at it in a slightly different way. I think there are three main areas where any team gets value from doing a design critique. First of all, expertise: getting people from different cross-functional areas, content strategists, localization, PMs, engineering, people who are experts in accessibility. Bringing all these people together pushes the boundaries of the work; no one can be an expert in all the areas. Second, we have many different teams working in different locations, so consistency is a really big and important thing for us. One person could be working in Copenhagen and another in Montpellier, and it's important that they're using the same components and UI tools and are aware of the work each other is doing. So consistency is a really important part of why we do them. And finally, just getting fresh eyes: people looking at your work, making sure that you're not too close to it, and some people playing devil's advocate to really test your design decisions before the work goes forward and gets built.

[00:07:10] There's also value to the presenter. First of all, there's value in upskilling: how they go about presenting, how comfortable they are bringing their work, and having the confidence to speak to what they've done. Then there's the storytelling aspect. There's a high possibility that these designers will have to take the work they're presenting to their design peers here and present it to senior leadership or, depending on what company you're in, to clients. So by presenting it and finessing your storytelling and your design rationale internally, it's going to really help you excel at your storytelling. And finally, confidence. I know I touched on it with the other two areas, but I think it's such a big and important part, and it covers more than just the presenting and the storytelling. As individual designers, this gives them the confidence that they're going about their work the right way and using good design thinking processes. It's been hugely valuable for us to see how our designers have grown and gained that confidence.

[00:08:21] It doesn't just stop with the presenter; the team giving the feedback also has a lot to gain. First, there's the opportunity for them to give feedback, learn how to give feedback the correct way, hear their peers giving feedback, and learn from how they're giving it. There's knowledge to be learned: they're learning how the designer who presented made their design decisions and the process they're carrying out, so there's a lot of cross-pollination of general learning in these sessions. And finally, there's contributing. You could be contributing to a product, or an area of a product, that you are normally a few steps removed from. A design critique gives the team an opportunity to weigh in, give their opinions and thoughts, and really shape and contribute to that product. So there's a really good opportunity for collaboration as well.

Our problem: a stale critique

[00:09:20] So, redesigning the design critique. I mentioned already that this is about how we redesigned ours, but just to reiterate, if you don't have a design critique yet, I think there are still things here you can apply to help you get one off the ground. We had a problem with our design critique. I'm going to talk about all the things we had wrong in a moment, but the TL;DR is it was just a little stale. It was lacking organization and it needed to be shaken up. I'll go into detail on all the different parts of that in a moment, but that's essentially it. We were trying to think: how will we fix this problem? How will we come together and solve the design critique? I think everyone really wanted a good, strong design critique, but we didn't know at first how we would solve this. And it was simple; the solution was right in front of us. We would come together and do what we do best, and that's apply some design thinking to solve problems.

[00:10:31] The first thing we needed to do was understand what was broken and why it was broken, so this is where I'll go into some detail about solving the problem. The first thing we did, and I touched on it in my talk last year, was a really quick stop, start, continue retro. For those of you who aren't familiar with this process, really simply, it's a way to collect Post-its from your broader team, asking them the things they'd like to stop in the current process, the things they'd like to start to improve the current process, and the things that are working well that they'd like to continue. This gives us a good idea of what's working well and what's not, and also captures ideas from the team to improve. The next thing we did was some interviews. The interviews were really just chats, because this is our internal team. Sometimes it was one-on-one discussions with some of the designers, sometimes we'd have multiple designers in the room together, and we'd all talk about how we could improve the situation we had.

[00:11:37] With that, we got this list. First of all, structure: the design critique we had lacked structure. Secondly, prep time was far too long. Designers were spending a lot of time preparing for design critique on stuff they didn't really need to spend time on. They were creating fancy decks, and that really isn't what a design critique is about; it's about being scrappier and focusing on the work. The frequency was erratic; we weren't rigid enough with our schedule, and there wasn't enough transparency. It was insular: a room of designers with the doors closed, and that's never a good thing. Critical feedback is vitally important to a design critique; without it, people are just patting each other on the back and the work's not going to be improved, so it's really important that people learn how to give critical feedback and do it in these sessions. Lost feedback: even when people gave the right feedback, sometimes it just got lost; we weren't documenting well enough. Confidence: people were afraid to present, afraid to contribute, afraid to give feedback, all because they weren't doing it frequently enough and there wasn't enough structure in place. And finally, capturing all of those things, it was just a little bit stale and needed to be reassessed. It needed to be shaken up.

[00:13:14] So we took these things, the takeaways from the stop, start, continue retro and the interviews and chats we had with the team, and decided to try to solve them one by one. I'm going to show you what we did.

Guiding principles, a template and a schedule

[00:13:27] First of all, structure. When we looked at the structure, it was quite easy: we just needed some guiding principles in place that would help us figure out all the other things. Without these guiding principles, these core areas, all the other things would be on unsteady ground. First, we wanted to make sure that everything we did was going to be easy: easy for people to contribute, easy for people to present, easy for people to know what's happening. Just make sure it's easy; don't make things more complicated than they need to be. Dynamic: this needs to work for everyone. Like I said, it needs to work in a working-from-home or remote world as much as it does in the office. Even before we broke up, we had designers from many different countries in the same design critique. So it really needs to be dynamic for the different presenters' styles and the different types of work people may want to present. Collaborative: everyone needs to be involved. If it's not a discussion, it's not a design critique; it's just someone presenting their work with nothing coming back. It needs to be a conversation, and everyone needs to be able to get involved. And finally, energized. If it's not energized, it's going to quickly go stale again, and you're going to spend a lot of time trying to fix it. So we want to get people excited and encouraged about it, essentially wanting to be involved in the process.

[00:14:59] Next, prep time. As I mentioned, people were spending way too much time preparing fancy presentations and decks, which is really not what a design critique is about. It's purely about the work, the rationale and the background. This large prep time was a huge blocker: designers were saying, "Oh, we don't have time for a design critique." Or they were spending the time, and it was wasted time, time they could have spent solving the design problems they're trying to solve. So we needed to replace that with something simple, flexible and scrappy, and that's a template. We decided to go with Miro, which is essentially a digital whiteboarding tool, and it's really great. One important thing about Miro is that it's not perfect. It feels scrappy, and that encourages people to be scrappy: dropping in screen grabs of the work they have, pencil sketches, screen grabs from desk research. It doesn't need to be perfect. What needs to be there is the background; those things are more important.

[00:16:06] So we created a really simple Miro template capturing things like the problem space and the background, an area for research, and the actual work itself, and made sure people know they can mix and match these different sections. They can add more sections, some sections can be bigger and some smaller. It's just a loose template, and people can drop things into it. This has saved a huge amount of time for our team.

[00:16:34] Next, frequency. We had issues with frequency, and this is probably one of the easiest things we had to solve: it was just about having a schedule. There are no major brainwaves here, no completely new thinking. We just had a schedule that everyone could see. It was consistent in people's calendars: we do it at the same time every week, it's always in the calendars, and the schedule is there for upcoming weeks. So people can book themselves in; even if the schedule is filled up for the next three weeks, they can book in for the week after. It's there for all to see, and it keeps us all honest. This is a super simple thing, but the impact it's had has allowed us to be consistent in how frequently we do our design critiques.

Opening the doors to cross-functional peers

[00:17:15] Next, it was insular. We had a room full of designers, and that's not what we want. It's important that we have our cross-functional partners there, and experts in different areas, to also give us feedback on our designs in progress. Again, like the schedule, this didn't take a whole lot of genius to figure out; it was just about opening our doors to our peers. This allowed us to get in other designers from different areas, make sure we have content strategists to give us feedback on the words, and make sure we have research, localization, engineering and PMs all in the room together. The pulling in of different people depends on what's being presented. Sometimes, if the work is really, really early, we may not have engineering. Sometimes what's being presented has a heavier lean towards research, so maybe we have more researchers in the room. Again, it's about being flexible: making sure we have a dynamic mix of people in the room, knowing who to pull in each week, and making sure it's not just designers in the room.

Critical feedback with the de Bono hats

[00:18:34] Critical feedback. This is probably the beast, one of the biggest areas we had problems with. Maybe some of you watching this talk are thinking, "As somebody who gives feedback, I need to learn more about this," or "My team has an issue with this." Hopefully what we rolled out here will be able to help your team. What we did is use the de Bono hats. Edward de Bono was a Maltese physician, and he came up with this notion of having six hats. By bringing in this six hats principle, we were able to have a lot of fun in our design critiques. We didn't physically wear hats, but it made for a lot of good gags.

[00:19:18] Edward de Bono had these six hats. First of all, the white hat, which stood for facts. Anyone who was assigned the white hat that week would try to focus their feedback on facts. The blue hat was trying to be objective. Their role each week was to keep the session running, try to be neutral, try to understand what's happening, keep the time moving, make sure everyone's getting their comments in, and if there were any big disputes, keep things moving: be that objective person in the room. The black hat was a difficult role for many people to play, and that's exactly why we assigned it to different people every week. That is to give negative feedback. Again, like the word criticism, negative doesn't have to be bad; it's just about being really critical of the work. That critical black hat feedback is essential. That's what's going to push the work forward. That's going to be the radical comment that the presenter is going to want to hear.

[00:20:23] The red hat was intuition: they went with their gut. The green hat was creative. And the yellow hat went the opposite way to the black hat: it was positive. A lot of things in the designs can be really positive, and it's really important that those things are called out. Celebrate what's working really well and call it out, not just to pat the person on the back, but to make sure they don't then remove it from the design. Something that's working well in the design could get removed if it's not called out.

[00:20:51] With these six hats, we would assign a different hat to everyone in the room at the start of the session. We normally have more than six people in the room plus the presenter, so sometimes there'll be two people wearing white hats or black hats or yellow hats, but we use an online tool to randomize who gets which hat each week, and we make sure that every hat is represented in the feedback. We didn't want to do this forever. After six months of doing this, we started to really see a clear trend that people were getting very comfortable giving feedback in all these different areas, and also hearing that feedback and not taking offense at it. So then we reduced it to just two hats: the black hat, sometimes the most difficult feedback to get, and the yellow hat as well, just to offset that. We ran these two hats for another two months, until we felt we didn't need the hats at all, and then we ran it with no hats. We feel our team are still giving feedback in all these different areas, and that has been such a big win for us. Of all the things I'm talking about today, this has probably been one of the most powerful things we rolled out in our design critique.

Capturing feedback and building confidence

[00:22:08] Next is lost feedback. Again, like some of the things before, the schedule and inviting our peers in, the solution was very simple, and Miro was the tool that allowed us to do it. It's just having a bit more process in how we captured those notes. This is essentially what our template looked like once it had some content in it, and we just allowed people to leave their feedback as comments directly on the board. Something that was particularly powerful for us was being able to apply the same color coding we used for the de Bono hats to our comments. So when the presenter went back to the Miro board after the critique to go through all the feedback again, they had all the notes there in front of them with the hat color tied to each one. This also gave the person leaving the comment confidence that the presenter would know what kind of feedback they were trying to give. We also make sure our sessions are always recorded, and we document them really well within the board. So the presenter can go back and watch the video and hear any detailed playback, and doesn't have to worry about note-taking during the session. They can just be involved in presenting their work and being part of a discussion about that work.

[00:23:29] Confidence. As I mentioned at the start, confidence is a big thing to gain, not just for the presenter but also for the people contributing to the crits. Every week we can only really have one presenter, unless we do multiple crits in one week, of course, but in every crit there can only be one presenter. So we looked at ways we could build people's confidence in different ways. Of course, the hats really helped with that, making sure each hat was contributing each week. But another thing we did was hosting. We have a rotating host each week, which means the MC, who welcomes everyone, introduces the presenter, keeps us honest with time and brings the whole thing together, is on a rotation. Given that we're all remote, we've had some really nice touches from hosts of late. For example, most recently we've been running "on this day": while we're waiting for everyone to join the Zoom, the host normally brings some facts about what happened on this day. Or my colleague Magic [?], he won't mind me saying, is big on animal facts. When he was the host, he always used to bring some animal facts. It just starts the whole thing off on a light foot, and it really helps to share that MC role and gives everyone the confidence to present to this bigger audience. It's a small thing, but an important thing nonetheless.

Keeping it fresh

[00:25:01] And finally, as I said, stale. There's not one single fix for this area; there are multiple fixes for being stale, and you need to be constantly on your toes, looking at how you can improve and make your design critique better. Because the things we have in place now might be totally stale in another year, so we're always trying to stay sharp and on our toes. Some things we do to keep it fresh: we do regular surveys with the team, asking everyone what they think is working well. It's just a Google Form: send it to the team, ask for feedback, ask them to rate some of the things, and if they have any ideas, bring them back to the crit and we'll try to improve on it.

[00:25:44] People have used their critiques to share user testing sessions they've done, for the whole design critique audience to contribute on top of the feedback that the customer has given. Also, expert testing sessions: using one of the designers or PMs in the group to do a live testing session, and everyone else leaving feedback as notes as those comments come in. People have used a design critique to present their background and some of their research, and then get the broader team to do some rapid sketching or Crazy 8s sketching. People have even done some rapid wireframing. It normally doesn't take up the full allotted time: we'd get eight or 10 different designers in different parts of Europe all coming together, doing rapid prototypes, and seeing if they can solve things together. These are exercises that people really look forward to, and the presenters normally get a lot to synthesize afterwards, a lot of great ideas, and they can obviously pick up any discussions with whoever did the wireframes afterwards. As I said, we're always looking for new ways to keep it fresh. These are just some of the things we've done recently, but I think as a team we're all focused on keeping it fresh and always pushing it forward.

Recap and results

[00:27:13] To recap on the different things we had: with structure, we added guiding principles. When prep time was too much, we created a template that was flexible for all different presenters' styles and different work at different stages, but also had structure to allow people to pull it together a lot quicker. With frequency, we added a schedule. Being insular, we invited our peers. Lacking critical feedback, we introduced the de Bono hats and got everyone learning, trained up and exercising giving the different types of feedback. With lost feedback, we introduced more of a process: recording the sessions and leaving comments on the board. With confidence, we enabled people to be hosts with a rotating host, and we also used the hats to build confidence too. And with stale, as I just touched on, we're always trying to keep it fresh for all of us. After this talk, if anyone has any suggestions, I would love to hear them, so get them over to me. This is a topic I'm passionate about and I'd love to talk about it, so if you've got great ideas from your company, I'd love to hear them.

[00:28:37] Our goal is not just to create one really good crit one week, or two, but to create many, many critiques. This is a real screen grab of our critique board in Zendesk EMEA. It's obviously really far zoomed out, so you can see the bigger picture. We have one Miro board that has all the design critiques cataloged together chronologically. If you look at this board, one of the biggest takeaways is this: we redesigned our design critique in 2019, close to the start of the year, and the real success for me has been the number of design critiques we've been able to do in 2020, in a remote, working-from-home world. We've nearly doubled the number we did in 2019, and we still have four months or so left of the year. That's been really, really positive for our team. People enjoy doing the design critique. People are confident about bringing work, from pencil sketches to high-fidelity work and everything in between, and people are confident giving feedback and learning from others. All those things are really, really positive for any design team.

[00:29:57] Thank you very much. My name is Gianni. Hopefully I'll be able to answer some questions on this topic, and as I said, do DM me or get me on LinkedIn if you're really interested in design critiques as well and you'd like to share some ideas or chat about it. I'd love to hear. Thanks again to the team at UXDX, and I really hope this talk has been of value to some. Thanks very much. Cheers.