API Case Study with Human-Centered API Design
How we created Identity, our first API product.
In this case study, we present the API product Identity, which was our first API product when we applied our API product management methodology. Basically, it is a product that allows organizations to verify the identity and personal info of a person. Our customer data is the basis for this API product.
In this case study, you’ll see how we applied the human-centered API design method to draft the API product Identity. This real-life example will help you to understand how to do human-centered API design.
In the following, we’ll present a real customer onboarding process for a Web portal. It was a real onboarding process of one of our clients to whom we ultimately sold Identity. Then, we present how we used the API service blueprint to visualize the customer journey, how we identified pain points, and how we used the API product cards to sketch solution and ultimately the API product Identity.
Customer Onboarding Process
Many organizations seek new ways to interact better with customers, provide better customer experiences and journeys, and save costs. Many do offer or plan to provide online self-service capabilities to their customers. To this goal, many provide a Web portal to onboard customers and to provide services.
Providing a simple and fast onboarding process is key to transform visitors into users, which are eventually transformed into customers.
Nevertheless, some organizations need to perform more verifications of users, specifically in the insurance or financial industries. As a result, the onboarding process becomes more complex and time-consuming.
More complex processes have lower conversion rates. One organization we worked with reported a conversion rate of approx. 10%. We define the conversion rate as the ratio between the number of visitors that were onboard and the number of visitors who started the onboarding process.
So, we conducted a workshop with one organization to understand the onboarding process and its pain points. The following table lists the steps, the user intents, and the corresponding user action of the analyzed onboarding process.
- Starts the registration process. To this goal, he clicks on the “Registration” button.
- Creates a new user account. To this goal, he clicks on the “New User Account” button.
- Provides personal info. To this goal, he enters name, birthdate, e-mail address, and mobile phone number.
- Verifies E-Mail address. To this goal, he checks his e-mails for the verification e-mail. He activates the verification link.
- Verifies mobile phone number. To this goal, he receives an SMS with a code on his mobile phone. He enters the code into a form.
- Provides address info. To this goal, he enters address info in the address form.
- Sets nickname and password. To this goal, he writes his personal nickname and password into the form.
- Verifies postal address. To this goal, he gets a postal letter with a code. He takes enters the code on the Web site.
Next, we used the API service blueprint method to visualize the customer journey of this onboarding process.
Based on the previous analysis of the onboarding process, we visualized the customer journey. To this goal, we used the API service blueprint method.
Together with the customer, we mapped the end-customer journey on the API service blueprint. The following figure present the API Service Blueprint of the onboarding process.
Next, we went on identifying the pain points.
Pain Point Identification
We marked the pain points on the API service blueprint. As described previously, we used red dots for clear pain points, green dots for steps to further discuss, and blue dots for steps that can be improved. The following figure shows the API service blueprint after we have marked the pain points.
Eventually, we identified the following three pain points:
- Verification of postal address via postal letter. This is a clear pain point. The prospect has to wait for a postal letter with a code that he has to enter on the Web site to complete his onboarding. Typically, sending a letter takes few days. Additionally, each letter costs.
- Verification of mobile phone number. This has a potential for improvements. Typically, you can verify the owner of a mobile phone number by sending him a code that he has to provide back. However, the organization already used a service. Fair enough.
- Verification of address. This has a potential for improvements. When people enter their address, they may make typos, abbreviate street names or cities, or just forget the zip code because they just moved to another city.
Next, we pulled out our existing API product cards and discussed how these may solve some of the identified pain points.
In our portfolio of API product cards, we found three API product cards that relieved some pain points: Customers API, Addresses, API, and SMS Token Validation API. The following list presents these three API product cards in more detail.
- Customers: It consists of the Customers API that provides info about one of our customers. It provides info about customer based on either a phone number or a customer Id. The info may include basic info (e.g., names, address), product subscriptions, billing, etc.
- Maps: It includes the Addresses API that provides an interface to retrieve all existing addresses in Switzerland. To this goal, it uses a backend service. A telco company needs to have all existing and future addresses and coordinates to manage building the telco infrastructure to existing and planed addresses.
- Messaging: Messaging is a bundle of APIs, which includes among other things the SMS API. One feature of the SMS API is token validation. With this API, we you can verify the owner of a mobile phone by sending a token via SMS that the owner has to send back via a Web site.
We added the API product cards to the API service blueprint. We connected the API product cards with the pain points they relieve. The following figures shows the API service blueprint, the API product cards, and which pain points they mitigate.
Providing customer data via Customers API to an organization is problematic. Hence, we brainstormed other solutions.
We knew that we cannot provide an organization access to data of our customers due to legal and ethical reasons. So, we did an out-of-the-box brainstorming based on the Opposite Day approach. That means, how do we not want organizations to use a Customers API.
We understood that the organization’s need is to verify the identity of people. And we have a database with data about lots of people. Eventually, we sketched a new API product card called Identity that consists of the idea of an Identify Verification API. The brainstorming helped us to know what we must not provide.
- Identity Verification: It consists of the Identity Verification API that verifies the identity and personal info of a person. To this goal, it receives some personal info about the user (e.g., name, address, phone number). The API uses some backend services to verify if the provided info corresponds to the info we have in our customer data.
The API product Identity Verification verifies the postal address via letter obsolete. As a result, we could remove this step and simplify the onboarding process. Additionally, a visitor can complete the onboarding in one session and doesn’t have to wait for a postal letter anymore. The following figure presents the final onboarding process with the API product card Identity, which replaces Customers.
With this approach, we don’t provide any organizations access to our customer data. They provide us some info and we provide a confidence score back that indicates the corresponding trustworthiness.
API Product Draft of Identity
Ultimately, we identified three API product cards that can help organizations to simplify their onboarding process, which increases the conversion rate. We bundled these API product cards into one API product and named it Identity.
The API Product Identity consists of three APIs:
- Identity Verification API to verify the identity of a person.
- Addresses API to verify that an address even exists, to correct typos, and provide simple search functionality for better user experience. Addresses API is part of the API product Maps.
- SMS Token Validation API to verify the owner of a mobile phone number. The SMS Token Validation API is part of the API product Messaging.
This is how we developed Identity, which was our first API product based on our API product management methodology.
Interested in the full story? Check out our book about API Product Management.