UX Design Group Crits: A Primer. Part 3: A Handy List of Questions

Hello, students of UX Academy! New and old! Students in general! Or to anyone who happens to be reading this for some reason! I’m Robbin and I run design critiques for Designlab’s UX Academy program on the weekends, and I love this gig. It is my hope that you’ll find the hour we have together in Group Crits useful.

This series of articles will tell you…

• the goals of the Group Crit 
• what you can expect from me 
• a list of crit-awesome questions (this article), and
• what I expect from you

An intro (also, bookmark this article)

Being critiqued is hard. Learning how to critique is harder. What do you even say to someone when you see a design that looks so beautiful that you can’t think of anything to improve it? Don’t worry—this is a common concern, and we’ll bridge it together.

Giving actionable feedback is a valuable skill, because it helps everyone, not just the design you’re critiquing. I feel that it’s highly possible that one thing holding students back from asking questions is an unconscious desire to be agreeable. I will stress the “unconscious” part here; I’m pretty sure no-one is going into a critique thinking that they’ll only say nice things about what is presented. It is just legitimately hard to overcome that in the beginning.

When I started attending crits as a student, I was definitely concerned that what I was saying made no sense, and was it really all that necessary for me to ask, and aren’t I just asking these questions about button placement because I need credit for my group crit? Luckily, I had some excellent facilitators (thanks, Matt, Kacy, and Emily!) who were encouraging and made me feel like the conversation was worth having. It’s my hope that I can make you all feel the same.

Without further ado, this article is my “cheat sheet” of questions (and here is a Google Sheet that you can comment on if you want me to add more) if you ever feel at a loss for what to say. Please do feel free to use these (ahem, and bookmark this), especially during my critiques. Each question will have a “reasons why this is important to ask” section so that you can understand what the question is generally hoping to achieve.

This is going to be a really, really long article because of that, so jump around as necessary. 

📚 Check out these resources

To begin, Designlab has docs that offer general tips on Group Crits, so if you haven’t read them or forgot they existed, please do give them a look.

• How to give and receive design critique well (includes 10-point checklist)

• Design principles checklist: covers elements that you should be thinking about as you critique your colleague’s work

• A primer on how to prepare for your group crit session (note: if you’re new and this is your first Group Crit, you probably won’t be doing a show-and-tell—but I do want you to start getting used to asking questions and offering feedback)

🔎 Find out what skill they want to improve

Questions to ask:

• What skill do you want to focus on improving? Why?

Why it’s useful: I will usually ask the presenter to reiterate what skills they want to improve the most in UXA so that we can provide feedback that will allow those skills to develop. But if you do not know, a great first question to ask is exactly that: what is a skill that you would like to improve? Keep in mind what the presenter wants to focus on improving when choosing what to ask.

📐 Choice of UX design tools

Questions to ask:

• What did using this tool help you accomplish?
• What did you learn (about the design, your audience, the business, etc.) from using this tool?
• Would you have used something differently? Why?
• Why did you use low-fidelity sketches over mid/high-fidelity mocks?

Why it’s useful: I know you’re just starting to learn about the tools, so this may seem like an unfair question. Isn’t this just a part of the Designlab curriculum, you say? Yes. But start thinking about why they are having you learn these things. Site maps, user flows, wireframes… these are all outputs that have come from somewhere. Being able to make them is great, but being able to explain why you made them is even better.

Regarding low-fidelity sketches… well, I’ve put this here because a senior designer mentioned that one of the major pitfalls of a junior designer is explaining how they empathized with the persona, and then it’s followed by… “AND THEN, I SKETCHED.” Yes. Well. Why did you sketch? What purpose did it serve? Is it because you could get feedback from others on it quickly? Because you can do it anywhere as long as you have a notebook and a pen? Because you don’t want to be attached to something that’s on the screen? There is a reason why you did it (aside from the curriculum), and articulating that reason is half the battle.

⏰ How long the work took

Questions to ask:

• How long did it take you to make this?
• Do you feel like it was worth the time and effort? Why/why not?

Why it’s useful: The time you spend on each deliverable should be thought of in terms of company time. Really take notes on how long it took to finish an asset before starting on the next. You will learn which tools make you iterate faster, which ones help you come to a decision with just enough information, and which ones can wait until later in the grand scheme of things. As you design, ask yourself if it was worth it to you, your team, and your company to spend all those hours making 50+ screens for your prototype (something I see a lot in the crits I’ve moderated). Importantly, don’t panic. You’re in a class. You’re learning. Take notes now so you can keep this in mind when you’re working later.

🤔 Reasoning and decision-making

Questions to ask:

• What were your considerations as you created this (wireframe, sitemap, persona, etc.)?

Why it’s useful: Ideally, you should be able to start from the last deliverable of your capstone and say, “I could not have made this deliverable without first getting results from the previous deliverable” all the way up to the beginning, when you were first defining the problem. This is what I have learned from the design recruiter at work. It is damn hard, but that’s the point: contrary to popular belief, UX design isn’t supposed to be easy.

You can have a knack for design, but the tools you’re using are here to develop that raw talent into a diamond. You are not off the hook if you cannot answer this (unless you forgot, which is totally acceptable, but you DO need to know why you did it). If you cannot answer this during the crit, write it down and reflect on what you would have said later on so that you’ll be ready for similar questions in the future for design crits, interviews, etc.

🤔 Moving the work forward

Questions to ask:

• When did you feel you had enough information to go on to the next step?

Why this is useful: Honestly, this is something I ask myself every day when I’m working on a product design project. Did I do enough research? Who am I talking to next? Why am I talking to them? Do I have enough information? What are the next steps, really? Should I even keep working on this project? It’s a tough question to answer, and unfortunately, it’s one of those “it depends” situations based on how big or small a project you’re working on.

⚠️ The problem statement

Questions to ask:

• What are you solving for?
• How did you decide what the main problem is?
• How will you decide which of these solutions will best suit the problem you’re trying to address?
• What does success look like? How will it be measured?

Why this is useful: This is the big one. THE. BIG. ONE. You may find that I will ask and reframe and re-ask this question over and over again, which means I am not fully understanding what problem you are trying to solve and why. This is, in my opinion, the most difficult part of UX design, and the reason the job is so lucrative. You can throw solutions left and right for days only to realize you lost sight of the problem (as well as all that time you spent), and then you have to back up and start all over again. 

The most critical thinking happens here, and the danger is that many teams will be in full-on agile mode and forget to dedicate a decent chunk of time on defining the problem. As a caveat, if you’re in a bigger team, you may have a PM who will do this part for you, but if you’re on your own, well… this skill would make you valuable and also might save your sanity.

👂 Choice of UX research tools

Questions to ask:

• Did you feel that (user interview, mental model, card sorting, etc.) was the right tool for the task? Why?

Why this is useful: At some point in your studies, you’ll wonder what the point was of card sorting. Or maybe you’ll wonder what on earth it is you actually learned from an interview. Because user research dictates your design, it’s important to understand how you felt about a method that you used to learn about a potential audience. It is also important to remember that UX research is not the same as market research. As a UX designer, you are designing for the user primarily, and the business as a close second; ideally, you can marry the two and get the best of both worlds.

🙋 Formulating questions for user research

Questions to ask:

• What questions did you find the most valuable, and why?
• Which ones could have been omitted, and why?
• Take us through the process of how you decided on asking these questions.

Why this is useful: This allows you to think of whether you were asking the right questions to get to the root problem. Let’s say I’m an elementary school teacher and I’m trying to understand why a student isn’t turning in their homework. Am I going to jump to conclusions and immediately ask them if they stay up too late playing video games? Probably not. Thinking about why you decide to use certain questions will help you check yourself before you accidentally introduce bias into a user interview. 

I’ve written more on constructing user interview questions in a previous article. And as I mentioned before, knowing the problem is half the battle—so if you take the time to craft your questions carefully, you are more likely to have a much better understanding of the situation, and you are more likely to feel confident in defining the problem succinctly.

📊 Finding patterns in the answers

Questions to ask:

• What are some patterns you found in your (preliminary research/empathy research/usability testing)?
• What was the most interesting answer you received? Was it expected?
• Did your findings from your preliminary research match with what you found in usability testing?

Why this is useful: If you haven’t already synthesized your results, these questions are great to ask yourself (or have others ask you). Codifying free responses and comparing them to the original group can yield very interesting results that will help dictate the next steps of your process.

Importantly, it is a good idea to see if your findings during your usability test of a prototype toward the end matches what was said at the beginning. You might find that your personas may be completely off. Perhaps the goals of the users changed by the time you got to the prototype, and now you should backtrack and find out where that happened. Or maybe now you’ve seen something that should be A/B tested to see what would perform better.

🖥️ Using research findings

Questions to ask:

• What recommendations would you make to change (x) aspect of the site based on your findings?

Why this is useful: I love our UX research team at work, because they’re clever folks that can take qualitative and quantitative data and wrap it up in a beautiful synthesis document, complete with recommendations at the end. These are straightforward because they’re derived from research.

Our product design team uses this information to make informed decisions as they go on to negotiate with engineers and PMs in terms of the time it takes to implement a feature based on its complexity. This helps distill the first part of the project into a minimum viable product that is usable but very bare-bones. Then, you do more research on it to iterate on the entire design. Rinse and repeat, because there is never a perfect design—just one that performs better than the last.

🎨 Address decisions about UI and visual design

Questions to ask:

• Comment on visual aspects, such as: padding/spacing, color choice, font choice, mood boards, branding.
• Why did you choose this (font, color, asset)? What part of the brand does it represent?
• Why did you choose this interaction pattern (radio buttons vs checkboxes; breadcrumbs; colors for active/inactive states, etc.)? 
• What are some words you wanted your design to reflect? Do you feel like you did? What moodboards were used in creating the overall feeling of the design?

Why this is useful: As a caveat, my strength does not lie in visual design. These are questions that I have heard other students and mentors ask when a visual asset is presented, and that have come up when I worked with our brand team to create a banner for a test community that matched with the rest of the site. Honestly, much of the time it feels like I’m trying to formulate an answer in response to, “What do you think of this priceless piece of art in this museum?”, but once I took time to really look at the asset, there are some questions I had. 

Much of the time, my interest lies in accessibility. Many sites are not designed well for that. I’m hue-blind, so I’m only affected in a way that is very mildly annoying, but the user experience becomes much more challenging for those who are more visually impaired, for example. People with a background in graphic design can speak to this better and I would love to include your thoughts here.

💡 Extra questions, if there is time

These are questions that are not directly related to presentations, but are still important to ask. If you’re new, these might be some things you can ask as well, but I encourage you to refer to the list above for a more savory conversation.

If I find that these kinds of questions are taking up too much time from the actual critique, I will interrupt you and ask that the conversation be taken to Slack. If you find it’s taking me a while to interject, please know that it is also fine for you to politely ask if we could move onto the next presenter. Please don’t feel offended when I or someone else in the session takes the conversation back to the actual critique.

• Software/tools: Lots of folks have trouble with InVision or have questions about Sketch plugins, etc. These are fine if they’re really quick ones, but I do not want to spend more than a minute or two on them. If you find that a conversation is going on too long about how to use the pen tool in Photoshop or something, speak up. Things like Sketch, InVision, etc. will take a while to master, and there are several students who have talents that transfer cross-functionally. Don’t be afraid to reach out to each other for help.

• How to be a better presenter: You’ll be talking a LOT in this field, whether you’re interviewing, participating in a design review, or working across teams to get your designs live. A fair number of students are extremely well-spoken, so it’s a great time to compliment someone on how they articulate themselves.

• Real world applications: Again, we have a great diversity of students. Ask people in your group (or the entirety of Designlab in the Slack channels) about how they used their UX Academy learning on the job. Go to the #wins channel to talk to alumni who scored their first design job. Ask me if we have time at the end of the session. Outside of the Group Crits, ask your mentor. You have a wealth of people at your fingertips on Slack. Take advantage of that.

This article first appeared on Robbin’s Medium blog and is reproduced with permission. You can also check out her portfolio!