Design Strategy for APIs
A five-step guide to use Design Strategy for API design
Introducing Design Strategy
Design Thinking, as we know, is a methodology that was developed by IDEO[1] for creative problem solving. The core principle behind Design Thinking is to be empathetic with the customer, identify their pain points, their journey through the product, their opportunities and needs, and get to a solution that truly solves their most important problems first, instead of creating a product that customers didn’t need or won’t use.
Design Strategy is a way to combine Design Thinking with strategic thinking[2] to create a product that not only provides a creative solution to the problem but ties the solution in with the business goals.
Traditionally, both these techniques have been applied to products that have interactive front-end interfaces in the product. However, the process is equally effective when applied to API design — not from a technology stack perspective alone, although the architecture is an important component of it — but also to identify what content or data the customer needs from the API to get[3] their job done .
The challenge with an API design as compared to a traditional UX interface is the fact that most buyers, who make the decision to invest in the product, are not the actual users of the API, and often, have a hard time visualizing what the API is going to do, and therefore, find it hard during stakeholder calls, to articulate what they need from it. Design Strategy is an effective tool to overcome this problem and this talk will put forth some guiding principles on how PMs can get to the real customer requirements faster using Design Strategy and UX principles.
Methodology
In Design Strategy, the first task is to create a Product Strategy document. Why? Because this document helps the designer, the PM, technology and customers to identify the common business objective — what problem does this product solve, and what is the expected success outcome for this product. This is aligned with the KPIs the product sets out to achieve and keeps everyone rooted to the goal.
For an API, typically, this is the easiest part. An API that processes credit card payments, for example, is supposed to perform one function and achieving that functionality, and to be able to repeat the function quickly, in parallel, at scale, are typically the key business objectives. But what is unclear is how the API can be designed in such a way that the developer can derive the information they need to, quickly.
What the PM decides to do next determines if the API truly provides the functionality and the efficiency expected in the Product Strategy document, or it becomes an API no one wants to use or pay for.
APIs are typically B2B products and that makes requirement gathering particularly challenging, because the users are almost always developers of different skill levels, and they could use the same API in many different ways for their business goals. This is what makes the APIs hard to design, because rarely is the goal as simple as “process payments”.
Here are the five most common hurdles that PMs face while formulating the requirements for API development, and Design Strategy has a solution for each of them.
Challenge 1: The customers all want the API to be a magic solution that solves all of their different problems.
Everyone wants a magic wand. In technology development, we know that is impossible. There are always trade-offs on what features can be released within a designated timeline that aligns with the expectations of the business stakeholders, both internal and external. In order to make the API impactful and create noise in the market, it is important to focus on what the users are struggling with every day that this API could solve. Design Thinking provides a simple framework to identify[4] these key pain points . Starting with an Empathy Map helps all stakeholders think like the user and identify what the user does and feels every day, what can’t they do today w.r.t the specific functionality the API is expected to solve, and what they wished they could do.
The key is to think like the user, and not the buyer. Through this process, more than one persona might evolve as well. This seems like traditional Design Thinking, but this is where it becomes different for an API. Instead of converging on a few functionalities, for an API, it is important to look out for converging ideas around data or content the API is going to provide
Challenge 2: So, we know what problem the API needs to solve, but what does the API need to do?
This is where all stakeholders try to translate pain points into opportunities using “How Might We” statements, to identify the key areas where the API can make an impact. Correlating the pain points and opportunities through the user’s journey map also helps. Here again, though, it’s important to remember that the journey map of the end- user is not important, the journey map of the developer as they use the API is the key focus.
For instance, a developer in a small startup wants to use the payment API. The journey map for the user starts with reading the API documentation, continuing on to testing out a sample integration followed by quick integration and testing with the user’s app or website that will use the payment API.
The pain points will likely be around the fact that the API documentation is hard to understand or poorly organized, the fact that there is no Swagger to test, and the fact that the parameters that can be parsed out of the API are not very obvious to the developer.
All of these, then, become opportunities for the API design to address.
Challenge 3: The API could be same as a competitor’s API, is anyone going to pay for it?
There might already be other competitors who are creating APIs with similar functionality. In order to make one’s API better, more powerful and different, the “How, What, Wow” technique can help. In this session, all stakeholders imagine what would be some cool “wow” things the API could deliver on. Many of these are unicorn ideas, that can seem difficult to do, but also highlight functionality that competitor APIs don’t provide.
For instance, a “How, What, Wow” for the payment API could be “Pay for the service by using Amazon Cashback so that the user’s customer can use cashback instead of entering credit card details.
This session becomes important because it provides stakeholders the option to speak up about their own unique needs, and the way other stakeholders react to these statements provide an indication of how the wider market might react to certain ideas and what the price for these unicorn ideas might be.
Challenge 4: All of the functionalities are equally important for the first release of the API.
This is where the conversation starts getting tougher. Once there are 20 opportunities on the board, and stakeholders have figured out the features that will add oomph to the API, how to get everyone to agree/commit to the MVP? What is the MVP? And what is an acceptable MVP? More importantly, what features are critical to the MVP and which ones can be passed over?
The Feasibility-Impact matrix is a great way to flesh out what the MVP could look like.
But in this context, the conversation is not around API functionality, but around what content or data are the most important for the API to surface first and how much effort is it for technology to deliver this data, in a structure that the developer can quickly parse out and use?
Challenge 5: But what will it look like when I finally use the API?
Finally, the big challenge — buyers don’t know what the API will really do, and users don’t want to know how the API will look.
How can a PM overcome this problem?
There are two things that, when conducted in parallel, have shown significant results in my experience.
- Prototyping: This is purely for the buyers. Once the Design Strategy workshop is completed, product managers work with the UX designer and even a UX researcher to put together a quick clickable prototype. The prototype should help the buyer visualize a common use of the API on their own website or app. Conducting one-on- one interviews as buyers interact with the prototype helps create immense trust among buyers well before the product is released by giving them the ability to visualize how this API will change their business once they use and what value the API will provide to them.
- Documentation Usability: This is a difficult activity to conduct, because the UX researcher and PM must work very closely together to frame the session and keep it as open-ended as possible without letting the study digress, but if done well, these sessions provide a wealth of knowledge from the developer’s perspective. As the true consumers of the API, developers often have different requirements than buyers do. As a result, having them walk through API documentation (Read mes), YAML or JSON Swagger documentation, and talking out loud about what they think they can or can’t do with the data they’re seeing, the parameters they have to pass, and the information they need to build their product can reveal key deliverables that might be missing, or even data the API has, but does a poor job of showcasing through documentation and structure.
Typically, it’s a good idea to iterate through these usability studies and even have follow-up Design Strategy workshops once the MVP is out and product managers are deciding on what new features to add to their APIs that will create value for their product.
So.. in conclusion
In the end, the process of designing the best API for customers depends on how well a product manager has researched customer expectations and assessed product market fit, just like every other product.
However, Design Strategy can draw the PM’s attention to key components within the API structure and data that could make the API very easy to integrate with. Failing to identify the data and content the customer wishes to view through the API or surfacing the data in a way that makes the data hard to use takes away from the functionality the API expects to deliver.
Using Design Strategy methods like the “How, what, wow”, the “Need Statements” and the Feasibility-Impact matrix for API data and structure can facilitate delivery of an API that has a shorter Go-to-Market for customers.
Adapted from a talk the author gave at #vGHC2020.
References:
[1] https://www.ideou.com/blogs/inspiration/ what-is-design-thinking
[2] https://medium.com/capital-onetech/experimental-api-strategy-fromcapital-one-be72db15362
https://www.toptal.com/designers/produc t-design/design-strategy-guide
