Design: 7 Essential Meetings

Nail these kinds of meeting to drive outcomes with your design

While Agile Scrum has plenty to say about development rituals and ceremonies, I have not found too much written about design rituals.

As Jared Spool says, “Design is a rendering of intent”. If this is true, then design can be used to facilitate communication. Therefore, it is useful to think of different rituals as a set of tools at a designer’s disposal to aid in communication and collaboration throughout the design process.

Here are a selection of rituals and practices that I have found over time that have become more formalised in my set of tools as a UX Designer.

3 Amigos Meeting

• 30–60 mins
• Designer, Developer, Product Owner
• Summary: 3 Amigos is an agile practice that I have found extremely useful for collaborative problem solving. These meetings have limited numbers to enable smooth communication and empower decision-making by not having too many cooks. The goal of the meeting is defined up front, and it is usually fairly focused. Each member has a role: One to request, One to suggest, One to protest. Typically, the PO will request, UX will suggest and Dev will protest. Through this format, a fairly complex problem can usually be solved in just 30 minutes.
• When to use: When designers want to learn about the technical constraints related to their design, or to refine a design before implementation, and discuss feasibility or technical aspects to a solution. Sometimes a model or design artefact is needed to make a problem more concrete.
• Top tips: Solutions should be made visual during the meeting to ensure a shared understanding — even writing notes on a shared screen can be enough.
• Drawbacks and considerations: Due to limited numbers, not everyone is involved, and so any findings or decisions made should be communicated to the rest of the team at the earliest opportunity. Sometimes if a solution was not well resolved, or outcomes communicated, a duplicate meeting can be required. You will not get a diverse set of viewpoints in this type of meeting, but that can solve through other forms of communication.

Pairing & Sharing Session

• 30 minutes
• Designer, Developer
• Once or twice a sprint
• Summary: Borrowed from the practice of pair programming. Where two developers work side-by-side to refactor and ensure quality code. The key principle of this is that defects are easier to fix sooner rather than later. Pairing and sharing is the same for developers and designers who will work together to implement a design. While pair programming uses two people’s time it actually saves time overall and improves quality in the end product.
• When to use: I have found it helpful for designers to do this with developers when UI is being implemented. Not only do designers quickly learn of the constraints of working code (e.g. CSS or REACT), but a relationship is formed, developers understand expectations more clearly, and the tendency to ignore designs is occurs less often.
• Drawbacks and Considerations: Use this practice sensitively: The developer should not feel like someone is looking over their shoulder to inspect their work. Developers don’t like the scope of work changing too much mid-sprint either. Therefore, pairing and sharing should be approached as a collaboration, kept fairly casual and honest feedback given both ways. Compromises should always be sought. The greatest win is when developers and designers find an improvement that actually makes implementation simpler and speeds up delivery. This technique is hugely beneficial.

Pair Designing

• 30 minutes
• 2x Designers
• Once or twice a sprint
• Summary: As above, but with two designers, the goal is to generate ideas or solve a problem collaboratively. As a designer I am aware of my own specialist areas, and I have often paired with a designer with complementary skills who can offer a new perspective on how to solve things I am not an expert on. This technique helps during hand-off between designers, or as a way to improve and learn.
• When to use: Constantly and often. Use this to generating ideas and concepts, untangle complex problems like user flows. It can be used to resolve disagreements about a design particularly when designers have an overlap in expertise that they disagree on.
• Drawbacks and considerations: Sometimes designers don’t agree on designs, at this point it is best to get a third, unbiased opinion.

Design refinement session

• Once a week
• 1–2 Designers, Product Owner
• Summary: This is different to the feature refinement that Software Developers go through to split feature-level items into tasks. Design refinement is something I do weekly with POs to: Bring new feature ideas or roadmap items to the table to start the design phase; for the PO to give feedback on designs; remove any barriers to progress and answer questions, and move approved designs into the product backlog.
• When to use: We do design refinement every Monday morning, this sets the activities for the week.
• Drawbacks and considerations: The meeting topic is not set beforehand so the topic can drift and be unproductive. Both parties should come prepared with work to discuss so that next steps can be planned.

UI Club

• Once every two weeks, 45 minutes
• 3–6 people
• Designers, Front End Developers
• Summary: This is a show and tell between designers and front-end developers across teams to present their work for feedback. The key outcome from this meeting is visibility of work, inclusivity during the design/development process, feedback and alignment on the company’s design standards.
• When to use: Occurs regularly, but is low priority. Can be cancelled if needed, or members are narrowed down to a 3 amigos if a problem needs solving.
• Drawbacks and considerations: The meetings can become quite large if the company is working on many products. Developers may not also be used to giving and receiving critique, but it is a learning curve!

Workshops

• Whenever necessary
• 3–6 people
• Summary: Workshop is a broad term so this one needs splitting down, but if you want to learn more, Gamestorming is the best book on this subject.
• Drawbacks and considerations: Workshops can be overused and while they can seem fun to begin with I have found teams can become fatigued by them. It is key to limit participants in workshops and keep them well facilitated — this is an art form.

Executive Reviews

• Once every quarter
• UX, Product Manager, Executive Stakeholder
• Summary: This one is about design leadership. An Executive Review is a meeting where designs are presented to whoever has executive decision making authority. It is an opportunity to share the design vision and get buy-in. The benefit of this can be a green light your designs, building trust and giving visibility of your work and more importantly, to avoid the famous executive ‘swoop and poop’.
• Drawbacks and considerations: You need to ensure your designs are watertight and you can give a solid rationale for your designs before going into the meeting, so be well prepared!

If you have more I would love to hear them — please leave a comment below!

—

I am user experience designer working in Glasgow and London. For more information about me, visit:
www.peterberrecloth.com