Common Good Design
Published in

Common Good Design

How we use design sprints

A design sprint is a focussed approach for designing, developing and testing a product or service. It’s a five day facilitated design process with participation from cross-functional skillsets to create, build and test opportunities for big challenges quickly.

Our approach to design sprints

At Common Good we’ve run design sprints with clients ranging from large businesses to small social innovation startups, for digital products and physical spaces. No matter what size your organisation or what the problem to solve is, a design sprint is a good way to mitigate big spends and quickly test a concept with users to see if it’s viable before building anything concrete.

Why did we start using design sprints?

We initially wanted to try this process to see how we could add more value at speed. We wanted to see how human-centred (customer-centric) design worked in this process. On longer projects, we use a mixture of lean and agile methodologies to test concepts, create prototypes quickly with insight. The idea of the sprint (developed by Jake Knapp of Google Ventures) gives a time constraint to focus on a particular area or feature without distraction.

Being a strategic design studio, we don’t just make pretty things or things pretty. We use design to create relevant and useful products and services that are feasible, viable and desirable to people and business.

Since we started sprinting, we’ve trialled and tested different tools, techniques and processes to see what works for the team and clients. We’ve learned when a sprint will work and when another method would be more valuable to our customers.

How we’ve learned to sprint

We start every sprint with a day of understanding. The starting point involves having pre-sprint preparation and a clear brief of the problem we are looking to solve. The research helps inform and clarify what the goals are, map out journeys, understand how we might solve the problem and where the focus needs to lie.

For each sprint we make sure we understand:

  • The brand/business or organisation — what their goals, needs and wants are?
  • What are the business KPIs and how are we tracking them?
  • Importantly who is the customer?
  • And what are their goals, needs and wants?

Key insight: don’t go into sprints blind. Talking to stakeholders and customers beforehand helps feed into building empathy for users, customers and humans in general. It is integral to our customer-centric approach and feeds into the solution we design.

Sprinting — exploring and making

Once the team have understood the problem and barriers, we begin exploring opportunities and identifying potential solutions. We use techniques that help us initially think big, and then help us narrow down our thinking to more tangible concepts. We colour the walls with post-its, sketch ideas out and continuously share along the way.

We generate lots of ideas and then narrowing them down fast. There are no sales pitches in sprints; the facilitator describes the details of each idea unbiasedly — this means more introverted personalities don’t miss out on having an idea not heard. The team all vote on aspects of each concept, then the decision maker (the client) gets the ultimate vote. Decision made, focus found, it’s time to make things.

Taking a sketch-led approach to prototyping and making means that you’re able to create artefacts that aren’t limited to a screen or something digital. For example, you might produce a physical object that shows how a product might work, or something paper-based to tell a story, or straight onto a device with a lo-fi coded concept.

The power and value from this approach come from getting something into the hands of users and out of the door. Testing in labs, real-world situations, or using other collaborative services means you start to understand where the value is in your prototype. The outcomes help shape up your prototype and provide you with the ability to make smarter decisions about your product or service from the feedback and insight from your users.

What works and what doesn’t with sprinting

Here are six learnings we’ve found about design sprints, when to run them and how to make them most effective:

  • Don’t be too broad — sprints are good to focus but they don’t work when it comes to re-imagining a huge topic!
  • Don’t do a sprint if you are 99% sure something is going to work — sprints are about testing problems that carry a risk.
  • Research is necessary — customer insight, interviews, desk research is needed before starting a sprint
  • Client teams or representatives need to be part of the sprint — co-creating helps build shared understanding and vision
  • Sprints are great at a project kick-off — they get the momentum going, help validate and set a direction for the product or service
  • Culture is important — expectation setting, collaboration and communication are vital to running a smoother sprint. Remember to make time for check ins and sharing.

Over the years we’ve experimented with the amount of people in the sprint. We’ve bought in a range of multi-disciplinary roles — subject matter experts, stakeholders, customers for interviews and insight. We’ve used sprints for product development as well as business and customer experience design. We’ve solved problems in both physical and digital. We’ve ideated, prototyped and tested in one week, as well as one day! We’ve kept on time and we’ve gone over. We’ve added energisers when we’ve needed them. We’ve mixed up tools and exercises. We’ve got stuck and we’ve whizzed through; and ultimately we’ve had a lot of fun.

Common Good’s design sprints have proven to be a valuable approach to solving our client and partner problems, and complement our existing roster of design and consultancy services.

Let’s make something great together

Is there a design or business challenge your organisation needs solving? I’d be happy to discuss how Common Good can help. Send me a message and say hello.

Originally published at on November 13, 2018.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store