Making the Case for Design Sprints

To Clients, Developers, and Even Designers

“A Design sprint is a time-constrained, five-phase process that uses design thinking to reduce the risk when bringing a new product, service or a feature to the market.”

If you’re thinking about doing your first sprint ever, follow this article when talking with clients, developers, and even designers.

Use the accompanying documents, and practice how to introduce, frame, and pitch Design Sprints — both to internal team members and to prospect new clients.

Make the case to Clients

  1. “Sprints reduce waste — time and money.”
    It may seem like a bigger investment going into the project, but looking at the total cost of bringing the MVP to market (start to end, strategy to post publish), you will, wait for it — save money.
  2. “Everyone understands (and follows) business goals from project start.”
    Maybe obvious, but it’s really important for everyone in the project (and there are usually a bunch of stakeholders) to understand why we’re building this product, who is it for, and how success will be measured.
  3. “Sprints help build products people will actually use.”
    Business goals are first and foremost, but without end users and real customers, the product is bound to fail. Sprints allow the team to define the customer, plot out a user journey, and validate the concepts with real users on the final day of the Sprint.
  4. “We bring everyone working on the project together.”
    A lot of times, this is success enough. Big companies have a large number of projects with team members across multiple locations (and also new members that never met before). This brings everyone to the same room for five days — and that helps with the project going forward.
  5. “Jobs said Sprints are much better than focus groups.”
    On the last day of the Sprint, devoted to user testing, we show the built prototypes to users and get actual feedback. Much more rewarding and valuable than any kind of focus group.

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” — Steve Jobs

Download

Make the case to Developers

  1. “You will be involved in building the product from day 1.”
    A developer is one of the most important stakeholders to be present this week. The workshop needs someone that will keep the group honest in terms of existing and future engineering capabilities. Participating, you’ll actually help in steering the product the right way.
  2. “Sprints will allow you to switch gears for a week.”
    This will come as a positive change. For one week, there will be less coding and code-reviewing, and more product definition and development. The following week, it’s going to be much easier to jump into the routine.
  3. “This is the counterpart to agile in development.”
    You already do (and know everything about) sprints. The Design Sprints is the product design equivalent to development sprints.
  4. “Preparation (think API spec) will go much smoother.”
    When everyone sketches and presents solutions, you’ll validate in real time what’s feasible and come out of the workshop armed with next steps — preparing that API way before the actual development starts.
  5. “There will be fewer changes when development actually starts.”
    There will be fewer change requests mid development. Solutions will be explored, bad ones flushed out, designed, prototyped and tested. Once you go into development it will be much more streamlined.

Download

Make the case to Designers

  1. “You’ll crunch weeks or even months into days.”
    What could have been a project kickoff that lasted for weeks of back and forth with a bunch of meetings and failed Skype calls is suddenly crunched into days. Decisions are made on the spot, assumptions tested and going into the project that follows is much easier.
  2. “You will understand why you’re actually designing this.”
    Often times, internal communication is not at its best. For instance, not everyone is included in every meeting, project briefs are missing relevant information and things get misplaced. If a project lands on your table, you’re probably going to miss some context. If you’re part of a Sprint, this will not be an issue.
  3. “You will actually get a seat at the table.”
    A popular phrase in the Design community, about designers getting a seat at the table. When we’re discussing the visual aspect of a product, it’s mostly not going to happen. But when we’re discussing the actual product, customers and most importantly — business goals — you’ll have everyone’s ear.
  4. “You’ll hear real users giving feedback.”
    The last day of the Sprint is the most rewarding and painful at the same time. You’ll actually watch real people interacting with your one day design. Don’t be emotionally connected, just listen. You’ll start creating much better designs when you do.
  5. “Sprints will force you to brush on your skills.”
    Let’s think about this: Building prototypes in one day? Every time for a different client, on a different platform? Using different tools? Yes — this will help you brush on your organizational, design, prototyping skills as well as thinking, structuring thoughts and ideas and presenting them clearly to the rest of the team.

Download

You’re now fully equipped to convey the value of Design Sprints to a broader audience. If you’ve encountered convincing arguments that are not included here — let me know and I’ll update the list.

This article was originally published on Tin’s Medium page.

Get started with Marvel Enterprise

Get started with Marvel Enterprise

From CEOs to marketing, get your entire organisation collaborating in one place.

Get started with Enterprise

Designer. Lead @airbnbdesign. Core team @IxDAEurope and #designsprint ambassador. ✗CD @sypartners, @fivenyc, @bruketazinic, @studijdizajna.

Related Posts

I recently worked on defining the spacing system for Practice Fusion’s EHR (Electronic Health Record) product, to ensure improved readability and consistency across all pages. I came up with 3 spacing rules (hint: rule of 3 C’s) and 4 spacing values, which worked harmoniously well with the new typographic system. The problem “When positioning elements vertically, the designer has to… Read More →

A selection of prototypes, photos, and learnings from Design Club at a special CoderDojo We recently joined CoderDojo London to deliver two days of workshops for 7–17 year-olds. We were hosted by UCL at Base KX, near Kings Cross. There were tables dotted about, offering coding activities. There were computers everywhere. Except on our table. We we were unplugged. Okay,… Read More →

“Dashboard”, “Big Data”, “Data visualization”, “Analytics” — there’s been an explosion of people and companies looking to do interesting things with their data. I’ve been lucky to work on dozens of data-heavy interfaces throughout my career and I wanted to share some thoughts on how to arrive at a distinct and meaningful product. Many people have already tackled this topic,… Read More →