API DEVELOPER CONSOLE

Role
Research, Interface Design, Prototyping
Platforms
Web
Industry
Fin-Tech
Year
2019

Introduction

Interswitch is an Africa-focused integrated digital payments and commerce company that facilitates the electronic circulation of money as well as the exchange of value between individuals and organisations on a timely and consistent basis.

Problem

Due to the nature of the business scaling at a high rate it was faced with the challenge of providing stable documentation to the users. It was complex to integrate APIs with third parties system. The API documentation was either incomplete or outdated. It time-intensive to onboard a new users to the platform which brings about drop off. The onboarding process for users was cumbersome because of the paperwork and informal processes with the sales team.

Outcome

Our design was able to achieve the following key things: The user/developer can understand the API in less than 3 secs. In less than 30secs, it easier to find different endpoint in an API. The Onboarding rate increased by 30% since the beta lunch. It takes about 3minute for the project to be up and running.

Results

Our design was able to achieve the following key things:

  1. The user/developer was able to understand the API in less than 3 secs.
  2. In less than 30secs, they are now able to find different endpoint in an API.
  3. The Onboarding rate increased by 30% since the beta lunch.
  4. It takes about 3minute for the project to be up and running.

Problem

Due to the nature of the business scaling at a high rate it was faced with the challenge of providing stable documentation to the users. It was complex to integrate APIs with third parties system. The API documentation was either incomplete or outdated. It time-intensive to onboard a new users to the platform which brings about drop off. The onboarding process for users was cumbersome because of the paperwork and informal processes with the sales team.

Strategy toward identifying a solution

Discovery phase

I approached my design process using a double diamond approach. Not being able to get the stakeholders buy-in conducting in-depth research due to financial constraint. I improvised by using the Guerrilla research method this method is fast cheap and reliable.

Secondary research

A round of quantitative research was necessary to expand my understanding of the issues faced by users. The research was conducted in two parts. First, I performed a heuristic analysis (Nelson Norman Group) of the existing system, then I administered a pair of surveys via twitter.I also constructed a competitive analysis of our product to better understand how our features stacked up against those offered by other competitive vendors.

User Pain Points

There is a strong developer community on Twitter. So, I worked closely with the team responsible for the social media team to conduct secondary research using the most popular tool twitter to conduct a survey. This made it possible to directly understand user pain points.

User Survey Poll From twitter

Relevant Findings

Based on the sample polls gotten from twitter with about 343 votes, I discovered that the developers' community remained concerned about the context of how the API documentation was written and how the content was complex to understand at first glance.

Things to consider

  1. Overview page: at first glance the developer should know if it is worth exploring further.
  2. Examples: Show key examples of how the API works
  3. Tutorials: the APIs should follow the best practices for writing any kind of step-by-step help.
  4. Onboarding: Decrease the time to which developer can be onboarded by providing quickstart guides.

Analysing the User Persona

The data gathered helped me to understand the target group and their common behavioural patterns and needs. Then I saw a pattern with the users so I classified the users into several levels some developers will like to familiarise themselves with the API and start working based on the example provided. Other users prefer diving into the project with an example. A different set of users will prefer to read through the documentation from top to bottom. Another set of users will prefer checking out the code samples before they begin reading the API descriptions.

User Persona

Exploring the Solution

Validating my findings I created a simple user flow with the intention that any user coming into the system can do the basic things which are:-

  1. Accessibilty: quick accessibilty to the APIs documentation.
  2. Interactivity: create a sandbox where the sample APIs can be tested and played with to give a quick understanding on how it works.
  3. Implementation:  to use the company APIs the developer has to request for it at the point of registration. Then when the developer has access to it the API can be used with any 3rd party app
Initial  user  flow for the APIs journey

The downside to the user flow drawn above implies that the technology backing the API sandbox tool could not be implemented on the documentation page, so I had to find an alternative.

Information architecture

Moving forward, I had to define the site structure alongside the Product owner and getting feedback from different stakeholders. We eventually came up with this architecture.

Information architecture

Expanding Ideas with wireframes

Examined an unconventional approach using the Kano Model which explores two axes: satisfaction and functionality. I used prototypical, familiar, proven patterns to reduce cognitive load. In taking a user-centred approach, I emphasized the need for users to quickly find important API documentation and get right into the console for testing. To validate this, we ran studies using wireframe prototypes.

Wireframe APIs Documentation Exploration

It is important to understand that the only way the developer can use the APIs they must ensure they must have successfully been onboarding into the platform.

Version 1
The intention was for the developer to be able to see their entire task in one single screen but after a design sprint session with the stakeholders, we learned that it will be challenging to implement sandbox tool in a single view, therefore, this indicated to be a red flag. To ensure we got this right, I launched an internal experiment and iteration using two distinct variations of design.

Version 2
The insight I got from the iteration, I realised it was necessary to understand that developers would prefer to have separation of concern on each page which is meant to focus on just one thing rather too many information brought into one page which will reduce the cognitive load of the user.

Project Console

Visual Design

Landing page exploration

Based on the finding earlier in my research anybody visiting at first glance needed to know

  1. What are the benefits of using the APIs?
  2. Who are the leading industries using the APIs ( Social proof )?
  3. How can we encourage can we make the information accessible and informative, but not intrusive.
Landing Page Overview

Categorization of the APIs

From specific learnings, I gathered the use of cards will make it easy to scan through the list of APIs and get immediate knowledge on what is the specific value of the API before it's even opened it.

API Categorization

Documentation details & layout

It is essential to know that the key factor for the user experience is the layout and navigation. Identifying what is the best practice I checked out the leading companies like stripe, master card, visa and dropbbox. Then I introduced persistent navigation this will make the navigation visible at all times. Users don’t want to scroll looking for a navigation bar that disappeared. So using a subsection on the top right will allow the user to scan through the headlines topics of the document and by clicking on any of the headlines it takes the user straight to the section.

API Categorization

Onboarding phase

40-60% of people who sign up for free software or SaaS application trials will use it once and never again if the user onboarding experience is bad. Therefore it’s important to set the user expectation early enough by asking for less information when they are about to register and this can reduce the chuck rate of the application.When you get into the system the user will be reminded to update their information which can be used by the administrator to approve the set of APIs that will be used.

Console View

Introducing a sense of delight within the developer console

For the first-run experience, I focused on creating a personalized and low friction flow, so that users could feel at home, but also get onboarded quickly.

Console View

Results

Our design was able to achieve the following key things:

  1. The user/developer was able to understand the API in less than 3 secs.
  2. In less than 30secs, they are now able to find different endpoint in an API.
  3. The Onboarding rate increased by 30% since the beta lunch.
  4. It takes about 3minute for the project to be up and running.

Takeaways

Our design was able to achieve the following key things:

  1. Understanding the technical side of the business and incorporating it within my design.
  2. I learnt how to create a balance between the developer experience basically to speak in there language and yet not compromising the other type of users.
  3. Learning how to take ownership of any project without waiting for people.
  4. One of the greatest thing as a designer is to be able to present your ideas to stakeholders and that was the greatest thing I learnt on this project.