I. Background
Outline: I. Background, II. Template redesign, III. Dashboard, IV. Other screens, V. Feedback & future
Role: Lead designer on developer portal
Team: IBM API Connect
Team members: Local & international developers, team researcher and team design lead
Tools: Keynote, Invision, Sketch, paper prototype, whiteboard and storyboarding
Deliverables: Weekly meetings with development, research artifacts, wireframes, hi-fi mockups
API Connect covers the entire API maturity curve
IBM API Connect is a product that supports API maturity at every stage: creation, management and marketing. Our least lucrative offering was our developer portal, which is a marketplace for third-party developers. Developer portals provide a platform to explore and evaluate API products. Recognizing the potential for revenue growth, our business analysts advocated introducing monetization options and revamping our developer portal template design. I was selected as the lead designer for this initiative.
Monetization: We previously did not offer a monetization feature. To address this potential profit loss, I worked with our business analysts and my team lead to design a tiered subscription model based on number of API calls.
Template redesign: For clients who did not want to create designs from scratch, we offered a template that clients could either alter with CSS or simply replace the placeholder content. Business analysts determined from user feedback that we needed to revamp our template design to be a better example of how users could market their APIs.
Dashboard: I created a dashboard offering analytics for registered users to view important information at a glance.
Ia. Users
Our two main users are API developers, who create the developer portals, and app developers, who review the portals and decide if the APIs add value to their apps. Our API Connect research team created personas of our users, shown below.
Ib. Design process
I was not given direct access to test designs with our current users. Therefore, to design I relied on a multitude of factors:
Research team’s work: The research team created resources containing overviews of our users, our competitors, and the technical space.
My background research: I started the design process by first researching our competitor portals. I documented and notated screenshots dissecting the UX and visuals, providing visual references to align our team during discussions.
Developer & user relationship: The UK developers had access to select users and were able to convey user feedback to me during our weekly discussions.
Local app developers: I tested low-fidelity paper prototypes with app developers in our local IBM offices who themselves were users of a variety of developer portals, representing our users.
Interactive paper prototypes.
I moved the sheets for participants as their finger clicked on different items in test flows.
Ic. Design testing
Participant screener. In order to be considered, participants needed to be app developers.
I collaborated with our team researcher to construct 2 research plans: remote user testing and a survey assessment. Because we could not design test with our current users, our researchers recruited app developers with portal experience for both plans. The same screener was used to recruit for each plan, and users were selected agnostic of company size and industry.
The results of these studies are discussed throughout, but I include a summary of each plan below.
The remote user testing plan.
Survey assessment: To determine what information was most important to users, our researcher asked participants to take a survey. Knowing what users prioritized helped us evaluate if the current redesign aligned with user needs. 55 participants were recruited from Respondent.io, Mechanical Turk, and usertesting.com.
User testing: 6 participants from usertesting.com passed the screener criteria. The first participant evaluated the prototype and script before the others so we could ensure the process worked. Our goals were to evaluate the overall design usability.
II. Landing page redesign
The landing page served as a marketing tool for potential customers. Because our customer businesses varied, our landing page template needed to be generic enough to apply to different customer needs but not too generic such that there’s no value provided. We also aimed for our template to guide users, helping them understand the kind of content they should substitute for our placeholder content.
IIa. Original vs. redesign
Original landing page template unregistered users
Call to Action (CTA): The original template’s CTA was to sign up, decided from a marketing perspective. However, I learned from research that app developers prefer exploring API documentation before creating an account to evaluate the potential value added to their app. I updated the CTA from account creation to API documentation and also linked the documentation at the bottom of the page as a final nudge to explore our offerings. I also added documentation to the top navigation bar.
Banner: The banner image was a low resolution jpeg image of San Francisco, too specific to apply to our wide variety of clients. The image colors were also quite dim instead of friendly and marketable. I replaced this image with a minimal SVG background for more responsive design so that the image could be resized without losing resolution. I also chose friendlier and more approachable colors to appeal to a wider audience.
Monetization: I included basic price breakdowns on the landing page for transparency.
Social media engagement: I added a social media section in case clients wanted to incorporate updates.
Redesigned landing page
IIb. Previous iterations
Below are some screens made in the process.
A low-fidelity iteration
A mid-fidelity iteration
IIc. Alternate designs
Some alternate designs I considered and submitted are shown below.
I later added an optional social media section to this design and reduced the descriptor items from 4 to 3 to simplify the content.
The focus of this design is on the API offerings. However, many of our API developer customers preferred to show this information only to registered users. Because the goal was to create a developer portal that could serve all our clients, we did not go with this option.
III. Dashboard
The dashboard monitors app and API interactions and provides organized navigation. I designed the dashboard based on competitor research, team discussions and feedback from app developers. Unlike the other parts of the portal, the dashboard content cannot be altered.
IIIa. Process
Below are some mid-fidelity prototypes. I experimented with content, data hierarchy and graph visuals.
A mid-fidelity version of the dashboard
Another mid-fidelity design
IIIb. High-fidelity mockups
The design includes analytics such as an overview of total monthly errors, monthly calls and average response time, along with a bar graph dissecting these categories by different time periods. There is also a summary of the latest API calls, notifications, and subscriptions, along with tabs providing this information in full view.
Empty dashboard
Example of a populated dashboard. This is the design we tested amongst app developers.
I received some pushback from the business team on displaying error analytics because of concerns that this transparency could potentially make the portal look bad to the customer. To strengthen my case, I collaborated with our team researcher to test the types of analytics that app developers find useful. Our research confirmed that 33% of 55 participants felt that viewing error analytics was one of the top 3 main tasks they want to accomplish with a dashboard. I presented my case to business analysts with these statistics, and the team agreed on building the infrastructure to provide users with error analytics for the next version.
API developers were asked to list the 3 main tasks they are trying to accomplish when monitoring their entire dev org
API developers were asked to list the 3 main tasks they are trying to accomplish when monitoring their app
Additionally, we learned from our survey that our dashboard lacked certain analytics that our clients would prefer to see, such as a chart for input and output message for each request, timeframe vs. average response time of all operations for the app, and an errors bar graph. Because we were limited in the analytics we could provide due to lack of infrastructure, I established next steps to address user needs by setting a timeline for improving our analytics capabilities and discussing with the engineering team and business analysts about creating the infrastructure.
We need to improve our analytics visuals
Through remote usability tests, we also learned that users found the analytics graphs difficult to interpret. After design testing the dashboard through remote usability tests, we learned that users found the analytics graphs difficult to interpret:
Users reported wanting graph functionality to show the exact numbers instead of relying on the visuals.
Users wanted to view more details (call type, response, etc.) on key data points to better understand problematic behavior.
This feedback suggested I needed to revise the graph and also consider other methods of displaying information, such as charts.
IIIc. Minimum Viable Product (MVP)
Our development team could not build the analytics tools in time for the release date, so I needed to provide a scaled back design more feasible for the release date. For this Minimal Viable Product (MVP), I reduced the tabs I originally designed (activity, notifications, subscriptions, and test apps) down to dashboard and analytics. I added the monthly cost and the API key credentials to this design. For the analytics tab, I inserted the existing analytics our team could offer. I intended these graphs to serve as placeholders in the MVP until we could provide more useful analytics in the following product releases, such as being able to view the API call volume per timeframe. The visuals of the analytics are directly taken from an existing framework. This MVP design provided us with time to evaluate dashboard information hierarchy and analytics during design testing before committing to coding technical frameworks.
MVP dashboard tab
MVP analytics tab
IIId. Remaining tabs
Below I include the other dashboard tabs for reference.
IV. Other screens
Below are some redesigns made for the portal once registered: getting started, documentation, product details, and sign in flow.
IVa. Getting started
I decided to incorporate a walk-through to guide users after they create an account. From this getting started page, users are linked to the 2 major actions: viewing the documentation and creating a new application.
User creates an account or signs in for the first time, and sees a getting started page
In this route, developers chose to create a new app
The previous API products display stated there was “1 API included,” but users would not know the APIs unless they click into the product.
IVb. Products page
The API Connect business model groups APIs into packaged products, and I redesigned the page showcasing these bundles.
In the original design, the API products page was not scalable because there was no search or filter. Additionally, the APIs bundled within each product were not displayed. Instead, the total number of APIs was listed, and users would have to click into each section to learn more.
I modified the products page to list the APIs within the products bundles along with a search and filter so that users could find items more easily. I also include a description within each product and an optional tagging system and filter to help in case there were multiple API categories offered.
Updated sample API products page with placeholder text
IVc. Documentation
After browsing the API products, users can read the documentation and API details and test different calls. I stylized our documentation to be visually more consistent with the redesign.
The original documentation
The testing panel opened up in the API documentation
IVd. Product details
I also redesigned the product details page to incorporate the direct links to the contained APIs, terms of service, and detailed monetization plan. The goal for the next design iteration is to improve the visuals and UX of this price chart.
The original product details page users are taken to once they select “Subscribe”
Updated product details page
V. Outcome
Va. Overall user feedback
When sponsor users were shown the designs, they largely gave positive feedback—one sponsor user said they “wanted it now.” When the remote testing participants were asked their overall thoughts on the design, they reported the design as straightforward and clear.
“Simple minimalistic well organized, I really like it. I like when the website doesn’t have a lot of information, isn’t messy and confusing.”
“It doesn’t seem out of the norm which is good because we want familiar interface and easy to find information”
Vb. Team feedback
I received overwhelmingly positive feedback from the UK developer team. In addition, the users that the UK team talked to reported that they were very excited about the redesign, found the designs more intuitive and were even asking how soon it would be implemented. I also received good feedback with the visual improvements as well.
— QA manager
— Developer manager
“You’ve done a great job Elika — thank you very much indeed for your efforts!”
— Team design lead
“No one can deny the portal looks *a lot* better than it did in v5! Already had 2 customers asking if we’re planning on backporting it to [our current version], v5.”