top of page
API Developer Portal
UX / RESEARCH / WEB
Our large Financial Services client wrapped up a massive digital transformation that would take them to the forefront as a transfer agency industry leader. Now their clients need access to and management of their data due to the rise of big data, in-house data analytics tools, and client reporting applications. The goal is to rapidly deploy external APIs for the market to leverage their data and transfer agency services.
My role was a UX Designer in a team of 2.
AWARDS
AFTAs 2021: Best data management initiative
GOALS:
-
Determine the main users of the portal, related needs, and potential team dynamics
-
Conduct competitive analysis to understand best practices for API libraries (open vs. private) available from other financial institutions
-
Determine the critical features and prioritized personas that would drive the MVP functionality
Our Design team worked closely with the Business Analyst team to align stakeholder expectations to streamline discovery processes and ensure we were in step with our assumptions every step of the way.
A developer portal is just for the developer, right?
INTERVIEWS
Wrong.
PERSONAS
Having interviewed people within the organization with various titles, we simplified our understanding to 4 main personas.
The way we think about personas are by way of “ hats ”:
One large organization may have 4 distinct people (or teams, even!) acting as each of these personas, but a smaller company may have a person wearing more than 1 persona hat. The point to keep clear is that each persona maintains different goals and reasons for needing certain information from the portal.
COMPETITIVE LANDSCAPE
Moving forward, we supplemented our research to discover best practices for API libraries (open vs. private) available from other financial institutions as well as
non-financial providers in the space.
The ones who I found to be strong websites performed well had some key points:
-
Documentation with technical specifications and code snippets in line
-
Clear distinction between technical pages (for developers and architects) and high-level exploratory pages (for business teams) so each persona would have a space that is relevant to the information level they’re seeking
-
At a certain point, there was a hand-off from the public site to when the interested party would need to submit a form or contact the provider to gain access to use and test the APIs
CREATING NEED-TASK STATEMENTS
Next, we focused in on the Needs and Tasks each of these personas would feel and encounter. From our user interviews and validation from stakeholders, we structured Need Statements that our business team constructed into User Stories for their business requirements.
I need to... so that I can...
PRIORITIZATION GRIDS
In a workshop with the stakeholders, we prioritized functionality through the lens of user value, feasibility, and business value.
Asking the team to plot user stories on the grid – we prompted discussion about the mid-feasibility, high-importance ideas that would reflect significant investments with potentially big payouts.
We were able to prioritize user stories (H, M, L) and the two main personas for the MVP and our sprint plan.
SIMPLIFYING THE SITE MAP
Following the workshop we constructed an anticipated site map, taking into account the personas that would likely need access to the portal prior to the paywall.
-
One group of people would need the right level of information and testing access to make business decisions on whether to engage with the client to begin a business relationship.
-
A second group (which can may overlap with the first) would need the detailed technical documentation and subscription access to begin actually integrating the APIs.
We developed a pre- and post- site map to understand how the features would translate to pages. Mapping each persona’s need-task statements, we were able to visualize the pages that multiple personas would utilize – this activity helped us tremendously to understand which personas would could prioritize while still maintaining the integrity of the site and capture many needs of the less prioritized personas.
We then finalized the pages we would need to create to account for the necessary MVP features.
Pre-login site map:
user story mapping iterated to final
Post-login site map:
user story mapping iterated to final
DEVELOPING THE DESIGNS
We focused on our two main personas, their level of information required, and best practices for API and code documentation. Our solutions include:
-
Discovery pages with high-level, non-technical information for business teams
-
Easy to find documentation and guides that included user-intuitive layouts and code snippets for the developers
-
Clear API versioning and standards that meet the criteria of best practices
USER TESTING & ITERATING
We conducted multiple user testing interviews with 1-4 developers from our sister workstreams who were part of the initial persona scope interviews.
WIREFRAMES AND HIGH-FIDELITY DESIGNS
API Developer Portal: Landing Page
Getting Started
Explore APIs
Explore APIs: View API
API Specifications
My Apps
WHAT'S NEXT
We took a very strategic approach for our quick timeline to prioritize and pinpoint exactly what was needed for the MVP.
I learned how to simplify technical requirements and focus on the user’s experience by talking to the end user and placing myself into a developer’s shoes.
These designs were the first iteration designed to be developed. As the interface is pushed to actual users and customers, the team will need to track and analyze the user feedback to capture next steps. The patterns of design will inform future iterations, especially as our team passes those steps off to another team.
In 2021, the work this team did won the award: AFTAs 2021: Best data management initiative—Northern Trust
TEAM
Ewa Karweta (Design Lead), Courtney Wu (Designer), Zulin Hsueh (Business Lead)
bottom of page