Design critiques for distributed teams
Persuading an in-house design team to embrace critiques can be tough — but where do you start when your design community is spread across different countries, sectors and clients?
Here’s how we solved the challenge of establishing remote, cross-project, design critiques at Kainos.
This post focuses on helping distributed design communities organise and facilitate remote design critiques, not the benefits or mechanics of critique itself.
If you’re interested in learning more about critique, I’d recommend reading some of the great posts by Jared Spool and Facebook Design or the incredibly insightful “Discussing Design” book by Adam Connor and Aaron Irizarry — as, without their work, this post wouldn’t have been possible 🙏
The problem with distributed critiques
Organising critiques while working in a distributed design community presents two distinct challenges — context and time.
Firstly, finding a mutually agreeable time slot is really difficult.
Kainos designers predominantly work in Dual Track Agile environments — oscillating between the fast learning and validation that occurs during discovery and collaborating with scrum teams during development. This way of working results in lots of deadlines (research/usability sessions, backlog refinement, story refinement, design reviews, design/development sprints, show and tells, etc.).
As such, we needed a process that enabled designers to gather valuable feedback at the time of need. A formal, diarised critique session was not an option — chances are designs would be in the hands of users before we had the opportunity to critique them.
Secondly, there’s context. We needed a process that enabled designers to quickly gain a shared understanding of the problem space. Predominantly working in large digital transformation programs, our designers tackle wicked problems in complex business environments. Our process needed a way for designers, unaware of a project’s context (users, requirements, guiding principles, vision or constraints), to quickly gain enough understanding to effectively critique a design.
A quick note on terminology
Before running through the process it’s worthwhile clarifying the roles involved in critique.
The presenter
The presenter is the designer whose work is being critiqued. They’re responsible for setting the scope of the critique, efficiently communicating the problem space, presenting the design, and acting on feedback.
The facilitator
The facilitator is usually, but not always, a senior designer who’s highly experienced in UX methods and processes. They’re responsible for ensuring the audience understands the agenda and problem space, as well as taking notes and moderating feedback.
The audience/critics
It’s important that everyone, including the presenter, participates in critiquing a design. As a designer, being able to intentionally shift your mindset between creative and analytical thinking is a key design skill that needs practice. In addition, by actively participating in analysis, a presenter inadvertently puts others at ease — allowing free exploration of the design and not the presenter’s relationship to it.
1. Setting things up
We use Trello to organise and record critiques. For those who don’t know, Trello is a web-based service designed for project management. Trello cards can have members (owners), due dates, attachments, and comments — a perfect fit for our needs.
The lists (columns)
The first list acts as an aide-mémoire or to help anyone new to the process. It answers common questions and provides tips to ensure an effective session.
The second, “Critique template”, list acts as a blueprint for organising a critique. A presenter duplicates this list changing its title to their name and project.
The cards
The “Critique context” card enables presenters to succinctly explain design goals, context of use, and define the focus of the critique.
It looks like this:
I’m showing [early/mid/late] work from [project name]
The intended users are [members of the public/admin staff/persona] who will access using [device] at [location]
The goal of this piece of work is to [What problem is this solving? What does this enable the users/business to do?]
I’m looking for feedback around [specific focus for feedback]
I’m not looking for feedback regarding [consideration] due to [constraint]
In addition to completing a “Critique context” card, presenters attach any design artefacts (personas/profiles, flows, maps, blueprints) that help promote a shared understanding of context and problem space. As this is regularly the first exposure an audience has had to a complex project, reading about it before the critique significantly reduces mental strain.
The “Critique notes” card is completed by the facilitator shortly after the critique. It captures everything discussed during the session including:
- Who attended the session
- Which design decisions were agreed to be effective
- What could be improved or needs further research/investigation
- Any alternative design directions that were discussed
Capturing this information allows everyone to refresh their minds prior to the next session.
Finally, the “Follow up” card is completed by the presenter after a session and documents the designer’s proposed actions as a result of the critique.
2. Asking for a critique
We solve the problem of scheduling by making the process very informal. Here’s how a designer requests a critique:
- Presenter duplicates the “Critique template” list changing its title to their name and project
- Presenter completes the “Critique context” card (attaching supporting artefacts)
- Presenter asks for 4–5 volunteers in our design community Skype channel — stating their preferred dates/times and linking to the “Critique context” card
- The resulting squad agrees on a facilitator and (virtual) location — Skype, Slack, Hangouts, appear.in etc.
- Facilitator sends a formal meeting invite by email
3. The agenda
We aim to keep critiques to around 30 minutes to limit the impact on busy schedules. Here’s how we roll:
- Facilitator runs through the agenda (~1 minute)
- Presenter explains the scope, context and design problem (~5 minutes)
- Facilitator confirms everyone understands the problem (~1 minute)
- Presenter shows the solution (~5 minutes)
- Everyone explores how the solution aligns with the goals, discusses design decisions and questions choices (~15–20 minutes)
- Facilitator gives a summary of the discussion, asks the presenter for their next steps and schedules a follow up when possible (~3 minutes)
Why this format?
The distinct separation between discussing What is this design trying to achieve? from Does this design achieve it? is crucial.
When focused on analysing the effectiveness of design decisions, circling back to context or goals is incredibly disruptive. It’s the quickest way to fly off on a tangent about supporting business processes that are irrelevant to how design decisions align with goals.
The facilitator makes sure this doesn’t happen by getting everyone to confirm they understand the design goals and context of use before a design is presented.
In summary
This flexible process allows our designers to have their work critiqued at the best time for them. If a designer finds themselves questioning design direction 2 days before a deadline they can complete a “Critique context” card and get feedback the same day from our experienced community who are working on different projects across Europe.
If you have any ideas or suggestions for improvement we’d love to hear from you.
Finally, and as a thank you for getting this far, here’s a copy of the Trello board — now go forth and critique!
Kainos is committed to developing a world-class experience design community. We’re always on the lookout for talented UX/IxD/service/content designers, and researchers. If you’re passionate about solving complex problems and designing life-changing digital services get in touch.
