Critique: An effective way of sharing feedback
Design Process at Asana
I joined Asana a year ago. I came from a different company, with only two designers. There, my relationship with the Product Managers (PMs) hadn’t been the best; worst of all I didn’t feel valued, which was depressing.
My designs were unsuccessful. Amongst other things, I blame the lack of timely feedback as a major cause. Whenever I received feedback, it came in the form of “the direction is wrong and now we all have to work extra to fix it”. This not only made me feel disappointed in myself, but it left me with a complete lack of motivation. I was told I had control over design, but they were turning down all of my ideas. I didn’t feel supported.
At Asana, the work process has made me feel inspired, energized, and genuinely happy every day (for the most part). Above all this, my designs have been very successful. I would like to share key parts of this process, so anyone can benefit from them and produce great work.
During my first days at Asana, I was given a small project to help me get on board. After a couple of days of design work, I presented the results to the product team in Design Critique.
The Design Critique (aka “Crit”)
To be honest I was a bit scared, but I think it was because I had only been there for a week. I had a lot of respect for my peers, English isn’t my native language, and I didn’t know how the meeting will work. I had been at one Crit before this, but didn’t participate much, I was just learning.
I got there, put my designs on the table and proceeded to explain them. I was cut off halfway through — someone recommended me not to explain every single bit, but just introduce the screen and what the view was, with a couple of sentences.
This first point makes a lot of sense if you think of the common user’s experience. You can’t rely on explaining the UI to the user; the UI should be as self-explanatory as possible. If the designs work there’s little to explain.
The second point was getting the feedback. It was strange because it challenged all my instincts. In feedback sessions I had at previous companies, I felt like I had to fight and defend my designs. During Crit at Asana, the point is not to defend your designs. That way, the spectators’ impressions are true and honest, and valuable just as they are. The concept is not to bring others around to your way of thinking, but to gather input.
Everyone started voicing their comments in a very calm and polite way. Most of the sentences started with “In my opinion…”, “I feel…”, “To me…” which defeats any possible argument because that’s what they thought when they saw the designs, it’s just what it is. No discussion needed. At any given point, if someone wanted to second any piece of feedback, they’ll just say “+1 (plus one)”.
I also received some clarification questions as “Why did you do this?” or ideas such as “Did you consider that other thing?”, and “Have you taken this other thing into account?” I had answers for some of the questions, while others opened doors to new paths, making me think about things I hadn’t even considered.
It was hard to avoid being defensive, but that moved the conversation (thus, also the designs) forward.
The aftermath
After Crit, I received a task in Asana with all the feedback. The PM had been taking notes during the meeting so I could focus on listening to what the team had to say. All the observations and ideas thrown there had their respective “+1”. The more +1’s, the stronger the consensus. With all that feedback, it was then up to me, the designer and owner of the designs, to decide how to interpret and utilize the feedback.
Nowadays, this process helps me realize what works and is clear and what’s not, it encourages me to decide when my designs are ready to ship, and it makes me feel like I’m in control and fully accountable for my own work. The team not only has my back, they’re also pushing me forward.
If you want to try it
I speak for myself, but I really recommend this method. In our Crits, we gather PMs, designers, and members of our User Research team. Some front-end engineers join us now and then as well. The process is as follows:
- The presenter (generally the designer) shows the designs. They can be printed or on-screen. They can be static files, animations or even rich prototypes (HTML, Quartz).
- A small brief is given to put the design in context and explain the goals of the project, and the goals of the specific screens being presented.
- Anyone in the room can give feedback or ask clarification. Depending on the size of your team, raising hands help keep a civilized order.
- There’s no defense of the designs, nor reply to the feedback, unless it’s a clarification. Every comment is that person’s helpful input. There’s no obligation to agree or modify the designs because of it.
- At the same time, the PM creates a task in Asana, assigns to the presenter, and makes notes of all the comments given, including the +1’s and ideas.
Some rules:
- The presenter should tell the group what type of feedback they are looking for (visual or interaction, for example).
- Guide the discussion away from unfinished parts of the design or pieces that don’t need feedback at the moment.
- Take turns while speaking, but don’t hesitate to jump with a +1 if your thoughts are strongly tied to someone else’s ideas.
- Before you start, timebox the presentation (including time for comments), to keep it tight.
- Attach the designs to the feedback notes (tasks in Asana work well for this), and make them available to the entire team. This way any extra comments can be given in text form afterwards.
- If a couple of people have a lot of ideas or feedback, you also can set up a meeting and discuss it separately afterward so you don’t use the whole team’s time.
I hope you find this useful. I would love to know what you think about it, if you use a similar system or if you tried ours. Please leave a comment with your feedback.
