API Design Sprint Playbook

An API Design Sprint is a 5 to 10-day process for getting clarity on API products through design, prototyping and testing ideas with customers. It’s a take on the Design Sprint, invented by Google Ventures, that focuses on the nuances of developing APIs that overcome technical obstacles but also deliver real business value. 

The short, sharp nature of an API Design Sprint has a way of rallying everyone around a problem to focus on the problem and fast track a solution. It provides something concrete to help reduce uncertainty while also being inexpensive. 

This process shines when you and your team approach it with a mindset of developing APIs that users – usually developers – love, customers value, and the business gains clear benefits from. Great APIs are about more than just solving a technical problem. 

This post is a playbook for running an API Design Sprint. It covers:

1. What a Design Sprint is
2. Why a Design Sprint is useful for developing APIs
3. How to run one

What is a Design Sprint? 

The Design Sprint was invented by Google Ventures as a process to help their portfolio companies rapidly solve big problems. Google perfected it with more than 150 startups, and since then, it’s been deployed by companies globally. 

Lego ran over 150 design sprints in a year. Facebook used it to evolve their news feed. The City of Denver used it to re-imagine public art. And some have used it just to redo their company website. 

Google Ventures provides a complete guide to Design Sprints with videos and checklists. There is also a book. To start with, the online resources are more than enough, and the book is for those that really plan on using Design Sprints heavily. 

The simplest way to understand a Design Sprint is by understanding what you do on each day of the sprint:

• Monday: understand more about the problem, your customers, your users and your business context.
• Tuesday: sketch possible solutions.
• Wednesday: decide on the best solution.
• Thursday: build a prototype.
• Friday: test the solution with customers and users.

Why Use a Design Sprint for APIs? 

APIs often get dealt with as purely technical problems, yet APIs are no different to any other digital product or experience you would work with. APIs that solve a clear customer problem in a way that creates value for the customer and the business is more likely to thrive.

Thriving means more funding for you and your team to develop an exceptional offering.

By using the lens of a Design Sprint to design your new API platform or re-imagine your existing one, you’re forced to draw upon the best thinking from strategy, innovation, behavioural science, design thinking and product management, not just technical excellence. 

Most importantly, the API Design Sprint explicitly forces you to put your concept into the hands of customers at the end. This step is crucial to developing APIs because APIs are often developed and published based on what was technically easy rather than what the customer needed.

How to Run an API Design Sprint

The API Design Sprint uses the same structure as a normal Design Sprint but tailors the specifics, like the checklists and content of each day.

The focus of the API Design Sprint is only partially on the technical functionality. It’s really about where technology meets the customer in a way that helps the business. 

Key Concepts

The key concepts you need to be aware of for an API Design Sprint are:

1. APIs – interfaces for software programs to talk to each other
2. Design Sprint – a short, sharp process for solving a big problem
3. API-as-Product – APIs through the disciplines of product management and agile. See The API Product Mindset and the 37 Dimension API-as-Product Assessment Framework.   
4. API Design – OpenAPI and Swagger standout here
5. API Platforms – software to develop and operate APIs 
6. Prototyping techniques – like the Wizard of Oz
7. User Testing and Customer Interviews

This list isn’t exhaustive but calls out the key concepts. 

Key Inputs

Before you start with the API Design Sprint, you will need information about the problem you are solving. If you don’t have this, then you need to conduct some research, maybe in the form of a discovery. A Design Sprint, by design, doesn’t allow for research. 

Preparation

Preparation for an API Design Sprint is about the following: 

1. Collect the information you have about the problem you want to solve
2. Block time in everyone’s calendars to make sure they can be fully present when you need them over the 1-2 weeks that you will run the Design Sprint. 
3. Prepare a technical environment: make sure the team has access to a technical environment that they are familiar with where they can rapidly prototype APIs without unnecessary constraints.
4. Create a plan: detail the day-by-day, hour-by-hour activities and workshops. It goes fast, so having a clear agenda helps stay on track. 

Refer back to the Design Sprint guide for more detailed information on preparation and planning. You may want one of your engineers to get familiar with an API platform, but this isn’t necessary. 

Key Activities

The Key Activities for an API Design Sprint are the same as a design sprint, so the focus here is on the elements of the activity that are specific to APIs.

The Key Activities at a high level: 

• Understand (Monday)
• Sketch possible solutions (Tuesday)
• Decide (Wednesday)
• Prototype (Thursday)
• Test (Friday)

Let’s walk through the API specific elements of each activity. 

Understand

When understanding the nature of the problem, the API specific elements are:

1. Sometimes you need to look beyond what your customer wants to do and look at your customer’s customer. What’s the Job-to-be-Done for your customer’s customer? 
2. Consider whether an API is really the best fit. Sometimes it’s better to provide a data export or tighter integrations. (See APIs: to build or not to build for more on this)
3. Link the API to revenue: look for a direct way to monetise or improve revenue-related metrics. This means the API will be more useful, but it also makes it easier to justify funding. 
4. Take a moment to look at what a best-in-the-world API looks like and what your peers are doing. Here’s an analysis of the ASX100’s public APIs as well as an analysis of Xero’s API (one of the good ones). 

Sketch

When sketching possible solutions:

1. Start with the Job-to-be-Done rather than the technical architecture. What’s the Job-to-be-Done of your user and customer?
2. Then design the API specification.
3. Then, and only then, design the technical architecture.

Fit the technology to the problem, not the other way around. Due to the technical nature of APIs, teams building APIs are particularly prone to getting too technical too early.

Decide

There isn’t a material difference between an API Design Sprint and a regular Design Sprint here. A minor issue to observe is that, if you’re the facilitator, don’t allow technical people to override “the business folks” or allow the “business folks” to back away from expressing a point of view. 

Often, given the technical nature of APIs, the non-technical people in the discussion will be hesitant to express a point of view because they don’t want to look silly. Yet this non-technical point of view is usually what is desperately needed – “I don’t understand how this helps our customer?”

Prototype

When it comes to prototyping, it’s ideal if you can use an API platform like Apigee. These give you so much power to quickly demonstrate some major functionality, but you do need some familiarity. 

Mock functionality is acceptable. It’s essential that your API is callable by an engineer. Postman is a great tool for testing and showcasing how your prototype works.

Test

Get a customer or developer that needs to consume your API to actually try using the prototype. Avoid talking about how the API might work and give the developer an actual specification, encourage them to try to solve their problem with it. This is the ultimate test and completely feasible. It will provide real insights. 

Outputs

Out of the API Design Sprint, you can expect:

1. Rough Job-to-be-Done (an outline of the problem your API solves for your customer)
2. An API Design Specification
3. Feedback from a small number of customers/users on your solution and their problem
4. A working prototype
5. Clarity and alignment on how your API can proceed (or not)

Remember that a completely reasonable output from an API Design Sprint is to kill the idea of proceeding with the API further. 

Read on:

• Webinar On Demand: Workshop Facilitation for Design Sprints
• An Expert Answers 15 Design Sprint Questions
• 3 Product Design Processes and When to use Them | Video

---