Working in the open is a vital part of the way we work at Mace & Menter. It builds trust and confidence in our work. It strengthens our design work by including feedback from multiple perspectives across its development.

Benefits of working in the open

• ‍It strengthens the design solution
  ‍By working in the open, the design solution is shaped from multiple people’s input throughout the sprint. Others on the project team have their own expertise and perspectives, be that technical, business, compliance etc. It’s much better to get structured design feedback throughout the sprint rather than at the end when it might be too late to change course.
  ‍‍
• It demystifies our process and builds trust
  ‍We’re transparent about our approach. This builds trust in both us as a team, and in our process.
  ‍
• It builds confidence in the design direction
  When we work in the open, the project team is invested in the solution. They understand why it is in the form it is, the alternatives which were considered along the way, and why the alternatives weren't selected.‍
  ‍
• It builds a sense of ownership in the design within the team
  By involving the team throughout design sprints, a sense of ownership of the design is built. This is important when we hand over the design. The team will need to advocate for the design, and make decisions as the product develops.

‍

Context: the design sprint

Before we start we work with our clients to shape the two-week approach and define the sprint goals.

Week one is about concepting and prototyping. Following sprint kick-off, we work on early concepts for a couple of days which we then present back.  We finalise a prototype at the end of week one and demo it to the team before research in week two. 

The prototype is usually a rough digital prototype, (without the refined code that goes behind something that’s made by a developer). Alongside this, as a team, we agree questions to explore in the research, and develop the discussion guide ready to use in the research sessions.

At the start of week two, we run user research with the prototype. Following analysis, we play back the research findings to the team and agree amends, before updating the prototype.
‍

How we work in the open in a design sprint

• Learn from the project team before designing starts - Before a sprint starts, there are typically areas of the product or service to learn about, and gain perspective on before starting design work. Running a workshop with the team and subject matter experts helps to access that knowledge. Stakeholder interviews are another approach which we might do outside the design sprint.

• Ask for recommendations for desk research - Desk research might involve looking at competitors, best practice examples, and parallel products. Clients know the landscape they operate in well. Asking for suggestions taps into that knowledge.

• Craft How Might We (HMW) questions with the project team - HMW questions are a bridge from problem space into solution space. Involving the team in the creation of that bridge is a useful step. When you play back the concepts, they can be linked back to the HMW questions.

• Have frequent team check-ins - Throughout a design sprint, we have multiple touchpoints with the team every few days. This frequent feedback ensures the design direction is viable and meeting the goals of the sprint. 

• Product Owner and technical expertise is required throughout to facilitate decision making and ensure feasibility of the design - This is important because at each stage of a design sprint, we make decisions with the team about the design direction, and what to take into research. It’s important the concepts are technically feasible. 

• At the start of each design call, we recap where we are in the sprint, and what’s next - This simple step takes no more than five minutes, and helps frame the rest of the call. When I wasn’t doing this, I found that the questions and feedback we got in the calls were either going over old ground we’d previously discussed, or would not fit with the timescales of the design sprint. We go over the objectives of the call as well, such as ‘flagging feasibility issues/ things to consider in the design’. This gives people permission to stress test the design in the call before we move forward with it.

• We show what we considered, not just what we recommend - We don’t go crazy on this; it’s our job as designers to curate what’s most important for the team to focus on. But by showing breadth in what we tried and considered, what worked and what didn’t, we build trust in the process and chosen design direction. It can be good to present a couple of options for an open team discussion about what direction to continue with. This is particularly important when there is no clear front runner amongst the options. Sometimes, elements of different options may be merged based on the team discussion.

• Make the design progression visible - We typically use a whiteboard tool to document the design progression over the sprint. At the end of the sprint, it’s satisfying to see how far the design has come, how it’s evolved and why. Other ways we document the design progression might be in a living deck, briefly noting what we did and learnt each week, what decisions were made and why. 

• Invite the team to observe research sessions - Team members who don’t do research as part of their standard job find observing research sessions very insightful. It builds empathy for people using the service, and they hear insights first hand. I like to involve all observers in a quick ‘Top five’ call after the session to note five things that we each took from the session.

• Involve the team in the design amends - In a typical sprint, we like to discuss design amends as part of the research playback call if possible. This links research insight with the changes being proposed. Combined with encouraging team members to observe research, this means the project team become advocates for the research, and the design decisions which have been made.
  ‍

By working in the open and getting feedback from people with different perspectives, we strengthen the design throughout the sprint. We build confidence in the design direction within the team, and we learn from the team’s expertise and perspectives as early and often as possible.
‍

Author: Natalie Vanns