Human-Centered API Design

By |2018-07-10T06:40:14+00:00July 10th, 2018|Chapter|Comments Off on Human-Centered API Design

Human-Centered API Design

Digital transformation is the next big thing after the industrial revolution. And APIs is one of the pillars of this transformation. That’s why so many organizations are interested in building APIs and expose their assets.

However, building and providing APIs is no guarantee for creating business value, digitalize, or transform. Without the Who, Why, and What, it’s rather a guarantee for failure, especially in the API economy. Thus, the key is to answer the following questions, which should be done prior to discussing how to build an API:

  • Who is the customer
  • Why does the customer need it?
  • What is the API or rather value proposition interface (VPI)

Organizations are increasingly investing into innovation to differentiate from or stay ahead from competitors. Innovative organizations focus on users and their needs. And this is what human-centered design is all about: focus on users, their needs, and requirements.

In this chapter, you’ll learn how to answer the Who, Why, and What with human-centered API design. To this goal, we’ll explain the methodology developed by Tobias Blum[^^Blum2016], who developed the human-centered API design workshop with us to find good candidates for innovative API products.

[^^Blum2016]: Tobias Blum: “Innovating the API Economy – Towards a validated human-centered workshop design.”, 2016

In the following, we’ll first describe human-centered API design. Then, we’ll present an API maturity model for organizations that helps you to select the appropriate API design workshop. Subsequently, we’ll present the corresponding workshops that help you discover your organization’s assets, understand customer journeys, and find innovative API products.

What is Human-Centered API Design?

Generally, human-centered design is an approach to interactive systems development that aims to make systems usable and useful. To this goal, this design approach is focusing on the users, their needs, and their requirements.

Highly usable systems and products tend to be more successful both technically and commercially. Especially, systems designed using human-centered methods improve quality, e.g., by:

  • increasing the productivity of users
  • being easier to understand and use
  • improving user experience

Our goal is to make API products useful and usable to make them successful. Hence, human-centered design is an appropriate approach. So, let’s use human-centered design in the context of API products.

  • Human-centered API design: Human-centered API design is an approach that explores the needs, wants and wishes of users and other stakeholders to create API products that are fitting their needs.

Human-centered design is different to user-centered design. Typically, human-centered design is more focused on methodologies and techniques for interacting with people to detect desires and needs, either by verbal or non-verbal means.

In contrast, user-centered design focuses largely on the API user. But API users or rather developers have different needs than API customers. That means that user-centered design focuses more on the user. On the other side, human-centered design is more holistic, which best fits the API stakeholder landscape.

That’s why we apply human-centered API design and not user-centered or developer-centered API design.

Three Stages of API Program Maturity

Different organizations are at different stages in their API journey. Some have no experience with APIs. Others have already experience with developing APIs and integration. And yet others have experience with API use cases.

Here, you’ll learn about the three stages of an organization in their API journey and to classify your organization accordingly. This will help you to select the right API workshop to create successful API products.

In the following, we’ll present the three stages in more details.

Stage I: Beginner

An organization without knowledge of APIs and how they work is in Stage I.

For organisations in Stage I, we suggest to start with the API Workshop I to discover new API use-cases. In fact, it’s about building up knowledge about API, how they work, and what you need to take into consideration.

Stage II: Advanced

An organization enters the Stage II when they run an API program. Some have already some experience with API design and development. Others are just starting.

When you expose more assets it doesn’t necessarily mean to be more successful in terms of commercial success or business value. Hence, you need to discover new use-cases, and understand what jobs customers want to get done and their pain points. To be successful, you need to know your organization’s that are at you disposal. Otherwise, you’ll find creative ideas that are not feasible within your organization.

For organisations in Stage II, we suggest to start with the API Workshop II to discover new API use-cases that build on existing assets of the organisation.

Stage III: Expert

An organization enters the Stage III when they have a running API program. Further, it already has some API products based on available data and service assets.

If you stop innovating, stop extending API products, stop create new API products, then you’ll soon outperformed by your competition. Hence, it is crucial to continue innovating and creating new API products or extending existing API products.

For organizations in Stage III, we suggest to go for the API Workshop III to discover new API use-cases. Repeat this workshop to continue innovating.

API Workshop I: API Fundamentals

Please refer to the Chapter “Beginners Guide to API”. It provides an introduction to the domain of API, stakeholders, and mindset.

API is more than just an interface to an application. It is an interface to a value proposition. Having this in mind, you’ll excel at the subsequent API Workshop II and III.

Further, you learn who are main API stakeholders. This helps you to invite the right people into these workshops.

API Workshop II: Asset Discovery and API Product Ideation

You are familiar with APIs. But you never had the opportunity to think about API products because you had to deliver APIs on request. Or, you don’t have a complete overview of interesting data and service assets in your organization yet. Or, you are just starting with APIs but don’t know where to start exactly. Then, this workshop is for you.

In this workshop, you’ll create new idea for API products based on your organization’s data and service assets. That way, you don’t create ideas that are not feasible to implement.

In the following, we’ll briefly outline the agenda of the API Workshop II. Then, we’ll deep dive into the single sessions, applied methods, and how to use them.

Overview of API Workshop II

The API Workshop is a full-day workshop. The goal of this workshop is to find interesting assets (i.e., data, services) that can used to create API products. The following table hows the agenda of the API Workshop II.

API Workshop II

TimeAgendaObjective
09:30Beginning of WorkshopWelcome and wake up their creativity. Provide overview to participants.
09:45Data FindingFind data assets
10:15
Service FindingFind service assets
10:45Data & Service LandscapingGet overview and understanding of data and service landscape
11:15Break-
11:30
Foresight Thinking IUnderstand what makes API successful
12:15
Lunch Break-
13:15
Foresight Thinking IIUnderstand what makes API successful
13:45
PrioritizationSelect most important assets
14:00API Product DefinitionCreate drafts of API products
15:30
Stakeholder MappingIdentify stakeholders to collaborate with
16:30Outlook & FeedbackCheck participants’ expectations and results. Define next steps and follow ups

The workshop starts with an opening to inspire all participants and to wake up their creativity. Then, they will work towards getting an overview of the organization’s assets, namely data and service assets. Afterwards, they will research existing APIs in your industry to understand what makes a successful API, how they evolved, and what might be needed in future. Based on assets and success factors of APIs, they’ll draft first interesting API products. Finally, participants identify stakeholders of this API products and define a follow-up to involve them.

In the following, we’ll present in more detail how to perform each session.

Session 1: Beginning of Workshop

The beginning of the workshop is key. This is the session where you set the starting mood of the participants.

The goal of this session is to inspire the participants and put them into a creative mood to get more creative ideas.

In the 15 minutes, inspire the participants, e.g., with telling an inspiring story or providing an outlook of the participants’ bright future. Then, provide the participants a quick preview of what will happen today and what the agenda is. Either you’ve collected the participants’ expectations in advance or you do it now.

As a result, you get their involvement. Then, they will be even more motivated to give their best.

In the next three sessions, you will analyze the data and service landscape and get an overview. This is the foundation of creating feasible API products.

Session 2: Data Finding

The goal of this session is to know what are the organization’s data assets. To this goal, we use existing offerings to extract data assets from. Focus on data finding to get more results.

In the 30 minutes, take a complete offering that you brought into the workshop. Then, start extracting the data assets out of it. To this goal, write each data assets to a sticky note.

As a result, you get an overview of what data assets the company owns and how this data assets are connected to the offerings. This are, e.g., address data, or data about their products.

In the next session, you’ll perform the same task analogously for services. In Session 4, you’ll cluster data assets together with service assets to get a better understanding of your organization’s valuable assets.

Session 3: Service Finding

The goal of this session is to know what are the organization’s service assets. To this goal, we use existing offerings, analyze them, and extract service assets from. Focus on service finding to get more results.

In the 30 minutes, take a complete offering that you brought into the workshop. Then, extract the service assets out of it. To this goal, you’ll write each service asset to a sticky note.

As a result, you’ll get an overview of what are the organization’s service assets. This are, e.g., encryption or selling a product.

In the next session, you’ll cluster service assets together with data assets to get a final overview.

Session 4: Data & Service Landscaping

The goal of this session is to get an overview of data and service landscape and how they are connected. To this goal, we use the findings from the previous two sessions, particularly data and service assets.

In the 30 minutes, cluster thematically the data and service assets. The following figure shows data and service assets, which are clustered. The red lines between clusters indicate that they are complementary or similar. It is a good practice to give each cluster a name. That will help in the following discussions.

Data Service Landscape

Data & Service Landscape. Data and service assets are clustered thematically. A line between two clusters means that both are similar or complementary.

As a result, you gain an overview of data and service landscape and how they are connected. This understanding and knowledge is the foundation to create feasible API products.

In the next session, you’ll analyze API from an API ecosystem relevant to your industry. This will help you to anticipate and foresight future API products.

Session 5: Foresight Thinking

The goal of this session is to anticipate the evolution of APIs and functionality that are relevant to your industry. To this goal, we use the Progression Curve method, which is an appropriate method to outline APIs on a timeline and anticipate their evolution.

Progression curves help to understand API patterns in the past and how these have led to the current APIs. The progression curve map has one axis: time. Time refers to publishing date of the API. It is on the horizontal axis. The year of 2005 marks an early year of public APIs. The following figure presents the Progression Curve map.

Progression Curves

Progression Curves.

In the 75 minutes, start with researching APIs that are either relevant to your industry or do similar things in other industries. The ProgrammableWeb[^ProgrammableWebURL] is one resource that might be a good starting point to discover APIs. Write relevant APIs on sticky notes.

Then, map the APIs in chronological order into the progression curve. Add as many curves as necessary.

Afterwards, analyze functionality of the APIs. The goal is to understand the pattern of events for APIs and how these events have led to its current state.

Ultimately, each curve represents how a set of similar APIs and their functionality evolved over time. The following figures shows some APIs that are put in chronological order on the progression curve.

Progression Curve Map

Progression Curve map. APIs evolve over time. Find the patterns how they evolve to anticipate future APIs.

Next, extract API evolution patterns and draw some insights about current state of APIs and future development. This is foresight thinking.

As a result, you get a feeling for successful APIs. Furthermore, you’ll get an overview of APIs relevant to your industry and how they evolved. More importantly, you understand the functionality of competitive APIs.

In the next session, you’ll apply your insights from foresight thinking to select important data and service assets for your API products.

Session 6: Prioritization

The goal of this session is to prioritize what data and service assets are important and what are less important. To this goal, we use the insights from the previous session and prioritize data and service clusters.

In the 15 minutes, prioritize data and service clusters based on your insights from the previous session.

As a result, you get an organized list of clusters where you see what is interesting and relevant today and probably tomorrow.

In the next session, you’ll use the prioritization list draft of API products.

Session 7: API Product Definition

The goal of this session is to define API products based on the results of previous sessions. To this goal, we use the API Product Card method, which presents the functionality of an API product in a very concise form.

One API product card represents one API product. It consists of:

  • Name: crisp name that gives an idea about the API product
  • Functionality: short description about the functionality of the API product
  • Icon: visual icon that gives an idea about the API product functionality

In the 90 minutes, take the prioritization list and go from top to bottom. Try to identify APIs or API products. Try to define the name, functionality, and an appropriate visual icon. You may use brainstorming to create ideas.

As a result, you get a stack of API product cards that you are going to use and validate in the API workshop III. Furthermore, you understand how you can integrate data and services into API products to create value. The following figure shows the API product cards for both API products Identity and Smart Catalogs.

API Product Cards

API Product Cards of Identity and Smart Catalogs.

In the next session, you’ll identify relevant stakeholders and customers for each API product card. This are the stakeholders you are going to involve for the corresponding API products, especially for the API Workshop III.

Session 8: Stakeholder Mapping

The goal of this session is to identify relevant stakeholders for the API products that you defined in the previous session. To this goal, we use the Stakeholder Map method, which is appropriate to list and classify stakeholders.

The stakeholder map has two dimensions: power and interest. Power refers to the stakeholder’s power to support or stop your ideas. Interest refers to the stakeholder’s motivation and his gains when you succeed.

The stakeholder map provides four quadrants based on low/high power and low/high interest:

Stakeholder Groups

GroupDescriptionInteractionExample
Crowdhave low power and low interest informcolleagues
Context Setters
have high power and low interestconsultyour boss, top management
Subjects
have high interest and low power involveaccount manager
Playershave high interest and high powercollaboratecustomer, product manager

The following figure presents the stakeholder map with the four quadrants.

Stakeholder Map

Stakeholder Map. Each quadrant represents a stakeholder group. Each group needs to be taken care of differently.

In the 60 minutes, list all stakeholders and customers for whom the API product might be interesting. Write them on sticky notes and put them into the right place in the stakeholder map. Create A stakeholder map for the top-five API product cards.

As a result, you get a list of potential customers as well as relevant stakeholders you have to interact with. You’ll use the stakeholder map to invite relevant stakeholders to the API Workshop III. Relevant stakeholders for the next workshop are subjects and players. The following figure shows the stakeholder map with some relevant parties.

Stakeholder Map

Stakeholder Map

In the next session, you’ll close the workshop and discuss how to leverage the defined API products and interact with stakeholders.

Session 9: Outlook & Feedback

The goal of the last session is to discuss about how to continue working on the API products and who and how to involve from the stakeholders. Furthermore, review the participants expectations and results and perform a feedback round.

With the discussion, you get time to think about how to continue with the ideas back in your organization. For instance, you might discuss about internal stakeholders, sponsors, synergies, but also how to proceed with the API ideas and how to make them happen.

API Workshop III: Find API Use Cases

You are familiar with APIs. You know the data and service assets that are at your disposal and you know the stakeholders. But you never had the opportunity to think about new API products because you focused on API delivery. Then, this workshop is for you.

In this workshop, you’ll create new idea for API products, evaluate, prototype, and test them.

In the following, we’ll briefly outline the agenda of the API Workshop III. Then, we’ll deep dive into the single sessions, applied methods, and how to use them.

Overview of API Workshop III

The API workshop is a full-day workshop. The goal of this workshop is to understand customers’ journey and pain points, and to generate, develop, and validate ideas for API products. The following table outlines the agenda of the API Workshop III.

API Workshop III

TimeAgendaObjective
09:30
Beginning of WorkshopWelcome and provide overview to participants. Set ground rules of workshop.
09:40Welcome & Intro from Head of PrincipalGet participants' acceptance for the workshop.
09:45
Intro of Companies & ParticipantsParticipants get to know each other.
10:00
Customer JourneyUnderstand customer's job to get done.
10:45
Break-
11:00
Pain Point IdentificationIdentify biggest pains and gains to tackle.
11:30
Additional Problems & NeedsDiscover radical innovations.
12:00
Lunch-
13:00
Problem/Solution FitIdentify what pain points can be solved with API product ideas.
14:00
IdeationInspire ideas for new API products.
14:30
PrioritizationSelect best ideas.
15:00
Break-
15:15
PrototypingCreate API prototypes that relieve pains or create gains.
16:00
PresentationCreate hype. Enforce quality of prototype.
16:15Wrap Up & Next StepsCheck participants' expectations and results. Define next steps and follow ups.

The workshop starts with an opening to get their commitment and to present participants and invited companies. Then, participants will draw the customer journey of a company and analyze pain points, problems, and needs. Afterwards, they will map their API product cards to relieve pain points and improve the customer journey. Based and untackled pain points and needs, they will brainstorm new innovative API products. Afterwards, they will select an API product card to build a prototype. Then, they will present it to show how it will create value to the customer. Finally, participants will define next steps to continue with their ideas.

In the following, we’ll present in more detail how to perform each session.

Session 1: Beginning of Workshop

The beginning of the workshop is key because it sets the mood and mental state of participants for this workshop. Hence, the goal of this session is to inspire participants and put them into a creative mood to get more creative ideas. To this goal, we use story telling, which is an approach to get people emotionally hooked.

In the ten minutes, tell a resonating and inspiring story and preview the positive future of participants and your organization. Then, provide the participants a quick preview of what will happen today and present the agenda.

Afterwards, set the ground rules for the workshop. To this goal, we use the nine rules for collaboration from Uebernickel[^^Uebernickel2015]. The following table shows the rules to foster successful collaboration.

[^^Uebernickel2015]: Uebernickel, F., Brenner, W., Pukall, B., Naef, T., & Schindlholzer, B. (2015). Design Thinking: Das Handbuch (Erste Auflage). Frankfurt am Main: Frankfurter Allgemeine Buch.

Nine Rules of Collaboration

No.RuleDescription
1.
Be visualDraw instead of write.
2.
Encourage wild ideasEverything sounds impossible until it's done.
3.
One conversation at a timeListen to others, get inspired, and collaborate.
4.Think user-centricProvide value for the user first. The rest will follow.
5.Build on the ideas of othersCombine your ideas with ideas of others.
6.
Stay focusedAlways remind the purpose of this workshop.
7.
Go for quantityDon't be perfect. Exhibit bias-to-action.
8.Defer judgmentDon't kill creativity and wild ideas.
9.Have fun"Creativity is intelligence having fun", Albert Einstein.

Finally, get their involvement by collecting their expectations now. If you did it in advance already, then quickly present them. Then, they will be even more motivated to give their best. Collect the expectations of the participants, e.g., on a flip chart. In the last session, come back to this expectations and review them with the participants and achieved results.

As a result, participants are in an inspired and creative mood.

In the next session, the Head of Principal will eliminate remaining doubts of participants and show the importance of this workshop and journey for the organization.

Session 2: Welcome & Intro from Head of Principal

The goal of this session is to get the participants’ acceptance for the workshop. To this goal, we show the support from a senior or rather Head of Principal.

In the five minutes, the Head of Principal presents what is at stake and why APIs are crucial for the organization’s success and future.

As a result, all participants will accept the workshop, motivated, and open to collaborate.

In the next session, all participants will get to know each other. This will facilitate exchange and collaboration among them.

Session 3: Intro of Companies & Participants

The goal of this session is to get all participants know each other and to facilitate collaboration and exchange. Further, all participants get to know the companies who take part in the workshop as well. To this goal, companies will pitch their company and participants will quickly introduce themselves to the others.

In the 15 minutes, each company representative will pitch the company in two minutes. This may include the company’s vision, approach, products, and customers. Afterwards, every participant introduces himself in one or two sentences.

As a result, all participants know each other. This facilitate exchange and first networking.

In the next session, participants will analyze the journey of the attending companies, which are prospect customers.

Session 4: Customer Journey

The goal of the customer journey is to build customer empathy and understand the journey of a customer. The customer is either the invited company or the company’s customer in the business-to-business case (B2B) or business-to-business-to-customer (B2B2C) case, respectively. To this goal, we use the API Service Blueprint method, which represents a service oriented customer journey.

The API Service Blueprint illustrates a process in which APIs can facilitate or simplify some parts. The API Service Blueprint consists of five layers: physical evidence, user action, front stage, back stage, and API stage. The following table describes this layers and provides some examples.

API Service Blueprint with five layers.

LayerDescriptionExample
Physical Evidence
Elements that influence customers' perception.Product info, ads, graphical design.
User Action
Steps that user takes to get a job done.Registering on a Web site, searching.
Front StageInterfaces the user interacts with.Registration form, Web page, cart.
Back StageServices and process that are used.Product search, check out.
API StageAPIs that can be applied.Payment API

The API Service Blueprint has two dimensions: technical depth and timeline. Technical depth is vertical and represents the technical depth. The lower a step, the more technical it is. Timeline is horizontal and represents the customer journey. The customer journey starts typically at the top left and ends at the top right. The following figure shows the API Service Blueprint.

API Service Blueprint

API Service Blueprint.

In the next 45 minutes, collaborate with the company representative to create a customer journey. To this goal, think about a specific customer journey.

Then, collect all steps and map them on a timeline. Finally, classify each step to one of the five layers (e.g., user action). The following figure shows the API Service Blueprint with the steps of a specific the customer journey.

API Service Blueprint

API Service Blueprint. The yellow sticky notes indicate steps of the customer journey.

As a result, you have outlined a customer journey from the customer’s perspective and mapped all relevant interactions and backend processes.

In the next session, you’ll identify the pain points in the customer journey. Identifying and addressing pain points is essential to create a desirable solution.

Session 5: Pain Point Identification

The goal of this session is to identify pain points of the customer journey from the previous session. To this goal, we vote individually for the biggest pains.

In the 30 minutes, put your votes on the steps. You can use coloured markers or coloured sticky dots. The code of the colors are as follows:

  • Red dot: Marks a step as clear paint point
  • Green dot: Marks a step as up to discussion
  • Blue dot: Marks a step as optional opportunity, i.e., it can be improved or provides a gain.

With the placed votes or rather coloured dots, you can quickly see where the most pain points are and of what type. Let’s use them as the innovation triggers to improve them.

Understanding the customer’s pain points is key to create a desirable API product. The following figure shows the API Service Blueprint after you voted for the biggest pain points.

API Service Blueprint with Pain Points

API Service Blueprint. People voted with colored sticky dots what steps are the biggest pain points. Red dots indicate clear pain points, green dots indicate up to discussion, and blue dots indicate potential gains.

As a result, you have identified what steps of the customer journey are the biggest pain points. This steps might be replaced or improved with an API.

In the next session, you’ll discuss additional problems and needs that are not reflected in the customer journey. These problems and needs can lead to radical innovations.

Session 6: Additional Problems & Needs

The goal of this session is to find really new API products based on identified needs from the pain points. To this goal, we list pain paints and associate each with a real need.

The following table shows a simple template to list pain points and needs. It contains three examples of pains and associated need. You may use a flip chart.

Problems and Needs

No.Problem / Pain PointNeed
1.
Short sessions because of limited battery lifeStay in touch over longer period.
2.
Missing product reviewsMake a good purchase decision.
3.Huge product catalogFind the right product.

In the 30 minutes, list all pain points from the customer journey. Then, clarify the needs that are associated with each pain point and put them on the list. Finally, extend the list with other pain points and needs that are not visible on the customer journey.

Replacing one part of a customer journey with a better one is good. But finding a total different and better solution for a problem is just better. Replacing one part with a better one is what we refer to as incremental innovation. Finding totally different and better solutions for a customer journey is what we refer to as radical innovation.

The list of needs can inspire you to find totally different and better solutions for a problem.

As a result, you get a list of pain points that are associated to needs. In the best case, you identified new API products for which you can sketch additional API product cards.

In the next session, you’ll use your API product cards to improve the customer journey.

Session 7: Problem/Solution Fit

The goal of this session is to find problems that can be solved with APIs. To this goal, we use the API product cards that you previously developed before this workshop.

An API product card consists of a short and descriptive name, a visual icon that represents the functionality or value proposition, and a short description of the functionality.

In the 60 minutes, go through your stack of API product cards and try to find what pain points on the customer journey it can solve. Put the API product cards in the API stage layer below the steps that it improves or replaces.

The API product card should at least partially solve a pain point. The following figure shows the customer journey, steps (yellow sticky notes), and some parts replaced with API products (blue cards).

API Service Blueprint with API Product Cards

API products cards that improve some parts of the customer journey are placed on the Service Blueprint.

As a result, you get an improved customer journey with less pain points (incremental innovation). Possibly, you might even found a complete different solutions that completely changes the customer journey (radical innovation).

Now, you’ve got a lead! You showed a prospect customer (i.e., company representative) how you can relieve his pains points. The worst case is that you learned who is not your customer. Please remind the following:

“The only real mistake is the one from which we learn nothing.”, Henry Ford

In the next session, you use the untackled needs and problems to ideate new API products and new uses cases. In case that the company representative is not yet convinced to buy your API products, this is your second chance to make him an early adopter or validate new ideas.

Session 8: Ideation

The goal of this session is to develop new API ideas. To this goal, we use Out-of-the-Box Brainstorming method, which is an approach to brainstorm complete new ideas.

Out-of-the-box brainstorming puts you outside of your usual context and thinking patterns. We made good experiences with three approaches: Scrabble Bag It, Pocket Dictionary, and Opposite Day.

  • Scrabble Bag It: Mostly everyone has an old Scrabble game that probably isn’t used since ages. Let’s repurpose those little letter tiles for brainstorming. To this goal, every participant grabs a handful of letter tiles. Each tile stands for the first letter of a word that might represent your new industry-defining idea. Be creative! The participants share and discuss them.
  • Pocket Dictionary: Often, we are just blocked in our thinking. One solution to this is to associate our problem with something completely different to get a different perspective on it. So, pick a random word from a pocket dictionary. And stick to this word! Associate your problem with the word and start the brainstorming.
  • Opposite Day: Sometimes, the best way to find the right answer to a problem is to think about how not to solve a problem. You want to get your customer to use a new product. So, think about all the ways the customer shouldn’t use the product. When you take another perspective, it opens up a new realm of thinking about a product.

“If you can’t solve a problem, then you need to change the perspective.”, Vinh Giang

As a result, you collect many ideas about new and relevant API products. The ideas are relevant because they are associated with the needs you retrieved from a real customer journey.

In the next session, you’ll evaluate and select the best API ideas to ultimately build a first prototype.

Session 9: Prioritization

The goal of this session is to evaluate the APIs of the previous session and to select the one that you want to work on in the course of the workshop. To this goal, we use the API Valuation Matrix method to create an overview of the best ideas.

The API valuation matrix has two axes: potential and viability. Potential refers to the value that the API brings to the team, organization, or customers. It is mapped on the horizontal axis. Viability refers to how realistic it is to build an API or provide a solution to an industry based on the available resources, experience, and reputation. It is mapped on the vertical axis. The following figure presents the API valuation matrix.

API Valuation Matrix

API Valuation Matrix. It consists of two axes: potential and viability.

In the first 25 minutes, place the API product cards from previous workshops and the ones creates in the Ideation session on the matrix. The position of the card reflects its potential and viability. The higher you place an idea the more viable it is. Analogously, the more right you place an idea the more potential it has in the market.

The best ideas are at the top right. Go for it! These ideas are viable and have potential.

The least interesting ideas are at the bottom left. Leave them. These ideas aren’t viable nor have potential.

The ideas at the top left are viable. Nevertheless, they don’t provide value or have a great potential. Hence, these ideas are just a waste of time at this moment. There might be a potential in the future. So, don’t forget about them entirely and reconsider their potential from time to time.

The ideas at the bottom right have great potential because they provide a high value. However, you are not yet in the position to develop them. In this case, try to identify why not and change the situation in the future. Then, this ideas may become your next innovation.

The following figure shows the API valuation matrix with evaluated API product cards.

API Valuation Matrix

API Valuation Matrix. Mapped ideas according to their potential and viability. API product cards at the top right are the best ones.

In the last five minutes, vote on the most interesting ideas you want to work on in the course of this workshop. Typically, people select ideas at the top-right or bottom-right.

In the next session, you’ll take the idea with the most votes and develop a first prototype. Afterwards, you’ll present it.

Session 10: Rapid Prototyping

The goal of this session is to prototype the selected idea from the previous session and test it. To this goal, we use the Rapid Prototyping method.

In the 45 minutes, take the solution from the previous session and build a prototype. You can build the prototype out of anything (e.g, paper, pipe cleaner). Ultimately, the prototype should reflect how the interaction with the customer changes when using the prototyped idea.

As a result, you’ll get a testable prototype, a clear vision about the API’s task, and a story that explains the APIs impact.

In the next session, you’ll present the prototype to get an early validation of your idea and feedback to further improve it.

Session 11: Presentation

The goal of this session is to present all prototypes and tell their story. To this goal, we use Story Telling and Elevator Pitch. Sharing with others might improve the result. Further, you’ll get a first validation and feedback how to improve it.

In the 15 minutes, pitch the idea to the others. You can show how the customer journey was and what changes with your idea. Get feedback from the others.

As a result, you’ve got a first validation and feedback to improve the ideas. Furthermore, the presentation is like a closing point that crisply summarizes the result and success of this workshop.

In the next session, you’ll wrap up the workshop and define next step to continue with the API ideas.

Session 12: Wrap up & Next Steps

The goal of the last session is to discuss about how to continue working on the ideas. Furthermore, review the participants expectations and results and perform a feedback round to learn.

With the discussion, you get time to think about how to continue with the ideas back in your organization. For instance, you might discuss internal stakeholders you need to talk to, sponsors, synergies, but also how to proceed with the API idea and how to make it happen.

Define together next steps and when you are going to review them and proceed.

Summary

Organizations are increasingly investing into innovation to differentiate from competitors. Innovative organizations focus on users and their needs. And this is what human-centered design is all about: focus on users, their needs, and requirements.

Our goal is to make API products useful and usable to make them successful. Hence, human-centered API design is an appropriate approach. We define human-centered API design as follows:

Human-centered API design: Human-centered API design is an approach that explores the needs, wants and wishes of users and other stakeholders to create API products that are fitting their needs.

API Program Maturity

We describe the maturity of an organization with respect to APIs with three stages: beginner, advanced, and expert. The following table describes the three stages in more details.

Three stages of an organization's API product maturity.

StageDescription
I (Beginner)
An organization without knowledge of APIs and how they work is in Stage I.
II (Advanced)
An organization enters the Stage II when they run an API program. Some have already quite some experience with API design and development. Others are just starting.
III (Expert)An organization enters the Stage III when they have a running API program. Further, it already created API products based on available data and service assets.

API Workshops

For each maturity level of an organization, there is an API Workshop with appropriate goals. This helps to progress in the maturity and reach the next stage. The following table shows the API workshop, its goal, and for what stage it is.

Overview of API workshops for every maturity level.

WorkshopStageObjective
API Workshop I
BeginnerGain API knowledge.
API Workshop II
AdvancedDiscover assets, API product ideas, and stakeholders.
API Workshop IIIExpertProblem/Solution Fit and validation of API product ideas

API Workshop I

The goal of this workshop is to get the basic knowledge about API to define viable API products with high potential.

Please refer to the chapter “Beginners Guide to API”.

As a result, you understand APIs. Now, you’re ready to ideate API products.

API Workshop II

The goal of this workshop is to get an overview of the organization’s data and service asset and understand what makes a successful API. You’ll ideate API products based on this assets.

The workshop starts with an opening to inspire all participants and to wake up their creativity.

Then, they will work towards getting an overview of the organization’s assets, namely data and service assets. Afterwards, they will research existing APIs in your industry to understand what makes a successful API, how they evolved, and what might be needed in future. Based on assets and success factors of APIs, they’ll draft first interesting API products.

Finally, participants identify stakeholders of this API products and define a follow-up to involve them.

As a result from this workshop, participants learn what makes a successful API. Further, they drafted first API products

API Workshop III

The goal of this workshop is to understand a customer’s journey as well as to ideate and validate API product ideas.

The workshop starts with an opening to get their commitment and to present participants and invited companies.

Then, participants will draw the customer journey of a company and analyze pain points, problems, and needs. Afterwards, they will map their API product cards to relieve pain points and improve the customer journey. Based on untackled pain points and needs, they will brainstorm new innovative API products.

Afterwards, they will select an API product card to build a prototype. Then, they’ll present it to show how it will create value to the customer.

Finally, participants will define next steps to continue with their ideas.

As a result, you validated and ideated API products based on a real customer journey.

About the Author:

I'm enthusiastic about exploring, learning, and applying new things, connecting the dots, and doing cool things that matters or rather make them matter. I enjoy bringing the right people together, share know-how and ideas, support people to do exceptional work, and doing whatever it takes to make great ideas a reality.