APIdirect

TYPE
MOBILE & WEB APP
YEAR
2022
ROLE
UX LEAD
HOME
>
APIDIRECT
The aim for APIdirect is to provide a gateway between systems used across healthcare and modern drag-and-drop process workflow builders in order to automate desired operations. APIdirect also offers conversions of traditional Rest APIs into No-Code “Connectors”, which allows stakeholders to easily design process workflows using any automation and integration platform that supports the Alphalake APIdirect technology, enabling the integration of processes and improvement of information flow.

INTERCONNECTED HEALTHCARE

MOSCOW MATRIX

PRODUCT RESEARCH

API CARDS

FILTER API'S

EXPANDED API'S

UPLOAD API'S (FHIR)

UPLOAD API'S (NON-FHIR)

INTER-CONNECTED HEALTHCARE

APIdirect is a responsive designed web based portal, with a database of APIs in the backend that are pulled into cards displaying to users a brevity of information available in a seamless experience. Not only are many popular APIs routed into APIdirect, developers can also submit their own APIs through a bespoke form for review, enabling our library to grow without manual outreach and database input.

RESEARCHING THE EXPERIENCE

MOSCOW MATRIX

Whilst solving the simple pain points of existing API databases such as inaccessible and confusing overviews, we also wanted to implement niche features into the platform that would transform it from a useful tool to a potential game changer in the API development scene, and this made it a necessity to properly illustrate the basic requirements as well as potential future implementations.

PRODUCT RESEARCH

Undertaking product research is an essential step in my discovery process, and whilst direct competition does not exist for APIdirect, similar products exists for which we were able to study and evaluate.

Key offerings of competitors provided our team with valuable insights not only into the market landscape, but also into unique selling points that enabled us to properly differentiate our library, as well as provide an expanded feature set that properly aligned with our user & client needs

An important consideration here was that our aim was not to shift users from direct competition to us, which meant a reduced need for understanding of competing concepts and structures, however the existing mental models and experiences of similar products were important to take note of in terms of comparative design thinking.

NOTE: Displayed is a compressed version of extensive research.

DESIGNING THE EXPERIENCE

API CARDS

Within each API card it was vital to display core information as succinctly as possible, so that the maximum amount of information could be absorbed by our users without overload, and without leaving questions for the purpose of each API. This was achieved through the use of Tags, decided through iterative research sessions, and Resource Groups, which are pulled directly from the FHIR standardisation handbook.

The tags were designed under 2 subcategories, API Type, and API Category. The API type designated the card as either ‘Nocode’ or as a traditional REST API, where the tag would appear as transparent with a clear CTA to get in contact with us to create a connector for them. Throughout the medtech industry the FHIR standard is well known, which is why it was opted to include a badge that expressed the API fit the standardised criteria used across many healthcare platforms.

Within the Resource Groups, it was decided that dropdowns would be the most optimal way to display the extended resources available to the user, after going through several design tests and narrowing down the exact copy we wanted to display.

FILTER API'S

After several research sessions with clinical leads to confirm the requirements, we concluded that there were 6 overarching categories our users would want to see, underneath each would be the relevant tags to filter by. The following categories were decided as the ones pivotal to navigate through what eventually would become a very large, a difficult to manually navigate library: API Type, Status, User, Location, Care Setting & System.

EXPANDED API'S

When selecting an API, the information available from the smaller view is still available, but for some APIs such as Cerner or Epic, there are too many resource groups to display in a fair amount of space, so after being giving a brief overview in the smaller display of what the API does and how it can be of use to them, if the user wanted further information this is where they would land.

A reviews section is also included in this expanded review after our research sessions confirmed that having the ability to let current colleagues, futures coworkers and other general members of the development community know what works well with the API, as well as enabling the API developer to gain valuable insight into improvements they can make, providing further incentive to upload their APIs here. This section is filterable by two tags, a carefully vetted ‘Expert Opinion’ where a well learned expert on the specific APIs industry application would give their untarnished opinion, and the All Reviews, where (under moderation) the wider user base could provide insight and opinion.

In a future iteration, stakeholder review sessions concurred that we may eventually want to develop a ‘forum’ for APIs, creating an environment where API developers can interact and better understand the APIs they use, and this would branch off from the current bespoke review system in place.

UPLOADING API'S (FHIR)

In order to allow our API database to expand without direct intervention, it is important to ‘automate’ this process by providing enough incentives for API owners to want to go through the process of uploading their APIs to our database, though even with incentives to do so, it was important to ensure this process was as easy and smooth as possible for them to prevent second guessing due to the effort required.

UPLOADING API'S (NON-FHIR)

Whilst FHIR standardisation is the best way for healthcare APIs to display their Resources, our research made it clear that some did not follow this schema, so I had to design the form to include those APIs without standardisation. As it was impossible for us to predict how many Resource Groups & Resources would be available within the API, and what the names of each would be, I opted for input fields with a simple explanation on the function and the ability to remove choices that were either mistakes or no longer wanted. When deciding operations there was no need to over engineer the solution, as the only operations available on these APIs are Read and Write.

LET'S COLLABORATE

HELLO@ZACHARIACURTIS.UK