Critique: The Secret to Growing Your UX Team Skills

I get emails several times a week like this one: A manager asks me to come in and train her design team on UX skills. I respond to her and suggest we have a discussion about it.

During this discussion with the manager, I realize conventional classroom UX training won’t help her team. It would be easy for us to sell her a course, as that’s exactly what she’d like me to do. However, it would be a waste of her money and, in good faith, we can’t do that.

Yet her team does need to learn more about user experience design. They are struggling with design challenges that exceed their knowledge and expertise. She tells me the team doesn’t have a common language to talk about design and it gets in the way of problem-solving.

It’s clear her company’s future success depends on solving those problems. Even though training seems like the obvious solution, my experience tells me it won’t work here.

Training Options for Teams with Varied Skill Levels

This organization, with 1000+ developers, has built a UX team of 65 folks. Some are senior designers and user researchers. Others are much newer with only a small amount of experience behind them. There are even folks who have joined the UX team from other parts of the organization, never having done any UX work before.

The team is completely varied in their skill levels. Some have great experience and knowledge in interaction design, while others aren’t aware of basic design patterns. Some are super information architects, while others barely know about card sorting. Any training would need to take all these different levels into account. If the team were to set up training, there are several ways they could structure it.

They could have an outside organization (like ours) come in and teach a course with the entire team. Because the team’s skills are so varied, it would be hard for the trainers to provide the necessary foundational training without boring the more senior team members.

Of course, they could somehow train only those folks who are missing the skills. But an outside organization would bring their own dialect of the language of design that wouldn’t be exposed to the team’s senior members. Those trained will speak a different language than those who aren’t.

Another alternative is to train the team’s senior members to teach their own classes. This would solve the dialect problem (and possibly be less boring), but it’s a lot of work to build and teach classes. And it could be reinforcing some bad habits that the senior members have. Plus, as the team grows, this would have to be a continual effort.

To make it even more complex, at this team’s company (as is common among lots of companies), the UX cadre is distributed across time zones and project teams. It’s logistically complicated to get them all together for regular training.

Finally, the people who belong to the UX team aren’t the only folks in the organization who need training in user experience design. Almost everyone they work with could use some level of training. Everyone could use a common vocabulary and literacy about what makes a design good for the users.

Any solution to the training problem has to involve everyone who influences the design. It can’t interrupt the daily project work—it needs to help move it forward. It has to engage everyone intellectually and adapt to changing demands of the organization.

There’s one technique that’s rarely thought of as an educational technique, except that’s exactly what it is. That technique is critique.

Shifting Critique from Design Feedback to Design Exploration

Critique is when a group of folks get together to discuss a specific designer’s work. Often, the designer presents their work, then solicits affirmative and constructive criticism about that work.

When I talk to folks, they see critique as an advanced form of design review. They gather in a room and give feedback on how to improve the design. It can be a harsh environment for the person who did the work, having to project a thick skin as everyone’s opinions come rushing by.

However, when done well, critique won’t be like that at all. The critique session can be an educational experience, exploring the designer’s work and what it means in a bigger picture.

These teams don’t approach critique as, “What feedback can we give this designer about their work?” Instead, the team members see critique as, “What can each of us learn from the work this designer has done?” Everyone walks out of the session with new knowledge and perspective about their designs.

Focus is Key

I recently participated in a critique where the team decided to focus the session on the design’s information architecture. The designer, who knew up front this would be the focus, started by presenting his IA goals for the project. He talked about the users, what their objectives were with the IA, and then showed us variations he’d come up with for the design. He talked about design principles he was focusing on and alternatives.

All the while, the team members in the room, some of whom were themselves quite knowledgeable and experienced about information architecture, asked him questions about his choices and thought processes. The session’s facilitator also made sure those in the room who weren’t as experienced had an opportunity to ask their questions and get informative responses.

The session hit a lot of tangents and a few digressions, but the facilitator did a great job of bringing us back to focusing on the information architecture. By the end of the session, the team explained complex concepts. New terminology emerged. The designer, who was fairly junior in the organization, confirmed they’d done a good job on the design, and left the session with some alternative ideas to explore.

Because the team agreed up front to focus this critique on the information architecture, everyone was prepared. And everyone learned a ton, which was reflected in future conversations the team had about the design.

Lenses of Learning

Information architecture isn’t the only thing the team can learn about in a critique. They can explore any aspect of the design or the design process, and should. Here are some of the different lenses that teams use critique to explore:

Design Concepts: All the different aspects of design, from visual design to copywriting, information design to interaction design. Holding a critique to talk about options for typography or grid layouts, or another one for discussing microcopy and form field labels would develop literacy in those topics.

The Design Itself: What are we trying to build? Are the flows through the design the right way to approach the problem? Have we arrived at the guiding principles that will make this design successful?

Design Systems: Is this design part of a large suite of designs? Are we evolving a design system that we can use in other places? Are we exploring the systems that are out there (such as Google’s new Material design system)?

Who the Users Are: What do we know about our users? What makes them distinct from non-users? What are the different personas we’re designing for? What are the common scenarios for each of those personas? How does this design match those scenarios? What are alternative ways to design for these personas and scenarios?

Business Needs: What are the explicit and implicit goals of the business? Have we designed for the immediate short-term needs? Have we ensured our design could last for the longer term?

Constraints (Technological and otherwise): What constraints will we run up against? What happens to the design when it’s at its most degraded (simple devices without capabilities like JavaScript, for example)? Have we explored the different progressive enhancement options?

Team Process & Collaboration: How are we working as a team? What are alternatives to our workflow? Where are we spending time that’s not getting us closer to a better design?

Critique Process: Are we learning everything we can from these critique sessions? Are the right people in the room? What alternative techniques could we use to be more effective at learning?

Each critique can focus on one or more of these lenses. Ideally, the team decides on the lens before scheduling the critique and starting the work. Teams that go into each critique session knowing what they want to learn are more likely to get the most out of each session, coming away energized and excited.

Separating Critique from Design Reviews

Design reviews are a necessary part of the process. Reviews determine if a design is ready to move to the next phase. Does it need more work or should you abandon it for another approach?

A common mistake we see is when teams combine design reviews with critique. They use the review session to offer constructive or affirmative feedback on the design.

This combination can strip the critique of its educational value because everyone is focused on making deadlines and meeting project objectives. Keeping the critique independent of the review sessions preserves the educational objective. It helps each team member think about the design work as a chance to learn and gives the designers a chance to take more risks with their work.

Critique and the Growth of Your UX Team

Regular critique, whether formal or ad-hoc, ramps up team members’ skills quickly. By changing up what the focus of learning is for each session, the team ensures that everyone’s skills become more well rounded. A vocabulary for design emerges and principles evolve.

Critique is a great way to get smarter about design, which in turn, helps the organization become more design-focused. As more people are brought into the critique process, such as product managers, stakeholders, content providers, and executives, teams see an organization-wide appreciation for the hard work of design and the outcomes it can produce. It’s the most effective way we’ve found for continual education and growth of the team.