Zoona provides essential financial services that help communities thrive. They are using technology and entrepreneurship to bring transformative change in Africa. The Zoona Developer Portal was a project funded by the World Bank's CGAP initiative that aimed to provide developers with information about the Zoona API.


Zoona and World Bank
Cape Town




Senior UX

Team size


The problem

Zambian businesses and 3rd party developers want to be able to accept payments from and send money to their local customers via Zoona's cash-based agent network. Zoona and the World Bank believed that an open API with integrations into the payment ecosystem would address this need and thereby provide a vital connection point between the digital and cash-based worlds. Zoona's developer community required a portal where they could learn about Zoona's API and start developing their payment solutions.

Design challenges

  • The project had a tight 12-week timeline.
  • I would be working remotely as a UX designer. The Zoona team were based in Cape Town, the World Bank's CGAP stakeholder was in Johannesburg, and the target users were in Zambia.
  • I would be packaging technical concepts and jargon into a format that could be easily understood by a diverse audience.
  • The Zoona Plus brand identity was new and had not been applied to a responsive website yet.

Project goal

The goal was to rapidly design a new information portal for Zoona's developer community that would sit on top of Zoona's existing API tools hosted by Google Cloud (previously APIGEE). The portal needed to utilise and extend Zoona's new Plus branding.

Success criteria

  • Could users understand Zoona's new offering?
  • Were developers able to find the information they needed to use the API?
  • Were the key stakeholders happy to sign off the designs?

My role

I was the Senior UX Designer and my responsibilities included:
  • Stakeholder engagement
  • Designing the website
  • Creating the content
  • Building an interactive prototype

Design process

I followed an iterative, user-centred design process for this project. The goal was to complete as many micro iterations within the twelve weeks as possible.

The strategy phase consisted of a stakeholder workshop where we discussed and completed a UX strategy canvas. It helped me extract valuable insights from the team regarding the business problem, target users, and success factors.

The research questions that we outlined on the canvas formed the foundation for the first phase of the process.
See other methods I've used

1. Research

The research phase focused on developing an understanding of both the needs of the target users and the business’ requirements. The plan was to utilise a combination of stakeholder workshops, desk research and targeted user interviews to develop a solid understanding of the problem space.

Methods and tools

Stakeholder workshops
A series of workshops and discussions were held with key stakeholders to help me understand the problem space from the business' perspective. I captured the outcomes on a UX strategy canvas that covered the following topics:
  • What is the business problem to be solved?
  • Who are the target users and what are their needs?
  • What are some desirable outcomes for the business?
  • Key research questions and solution ideas.
Understanding the target users
A key deliverable was a set of personas that I generated after the workshop. It provided a tangible way of keeping the team centred on the goals, information needs, and attributes of the target users. Practically, the personas served as subjects for the user journey maps and aided the screening process for interview participants. The persona set included users who needed a high-level explanation of what the Zoona's API offered and technical users who needed to understand the details of the API.
Design pattern research
My desk research highlighted several UI and content patterns for developer portals. The key findings are summarized below:
  • API reference pages should utilise in-page navigation.
  • Code snippets should support 'copy and paste'.
  • Code snippets should be available in multiple languages.
  • Remove unnecessary jargon in sections targeted at users who may not be developers.
  • Provide clear, succinct information regarding the steps to implement an API call.
  • Use non technical section titles.

2. Explore concepts

I used the concept phase to diverge and explore information architectures, which were presented as wireframes to the stakeholders for review and feedback.

Methods and tools

Review workshops
Sketch (wireframes)
Zeplin (handover)

Information architecture

A critical part of the concept phase was finding the 'right' information architecture to satisfy the users' information needs. The process required me to think about the concepts that I needed to communicate during an interaction, how the communication should be structured, and the content required. The nature of the content meant that I had to be careful not to overload the users with technical jargon, especially those who only wanted an overview of Zoona's offering.
Examples of the wireframes used to explore the information architecture
Key information architecture concepts

3. The solution

I simplified the minimally viable version of the Zoona developer portal to 17 pages. There were more pages available to the user after they registered and logged into the API management area, but these pages were out of scope for this project.
Basic site map for the external pages of the Zoona developer portal

Methods and tools

Sketch (UI designs)
Axure (prototype)
Zeplin (handover)
Colour and typography
Zoona's Plus brand identity transitioned the company to a more sophisticated and mature palette. Nunito was chosen as the primary font because it imbued stability, playfulness, and accessibility. Muli provided a minimalist secondary font suitable for the body text or situations where a rounded font was not appropriate.
lllustrations and icons
The illustration and icon style focused on clean, high contrast line work with soft curves and minimal use of a primary accent colour. My goal was to create a web experience that felt light, spacious, yet focused and emphasised the content. 

Art direction: Andrew Maunder
Cover illustration: Quintin Weyer (modified by Andrew Maunder)
Illustrations: Andrew Maunder
Icons: Andrew Maunder
The solution launch pad
The home page included a 'launch pad' section that aimed to give users a quick overview of some popular uses for the API and to cross-link them to the appropriate page. This section is an example of 1st tier content that intends to guide new users to the most relevant piece of 2nd tier content. As mentioned before, the goal was to prevent overloading the user with information.
Pricing information
My research showed that clear and transparent pricing was a common feature seen on developer portals and API related websites. I, therefore, decided to include a pricing page that was accessible via the primary navigation and a pricing section on the homepage. I also added a price related caption below the "Create account" button that said that the user could try Zoona's API for free. The design goal was to encourage the users to keep exploring the site and then, hopefully, to get interested users to create an account or to contact the Zoona team.
In-page navigation and quick links
The documents page took the form of a single, long page with a sticky, in-page navigation panel on the left-hand side. It provided an overview of all the topics covered and allowed the user to link to the appropriate section. I chose a single page pattern with auto-scrolling for two reasons:
The quick links strip provided a highly visible set of links and phrases designed for new users. API websites often included a 'Get Started' section, and it is a phrase that developers look for when they start working with the API documentation.

4. Test the solution

My strategy combined data from three sources, both qualitative and qualitative:
The goal of the evaluation phase was to understand how users experience the products and to determine if they found value in it. I did this by looking at their behaviour (what they did) and their interpretation of the experience (what they said).
Usability testing
The usability testing followed Nielsen's iterative, five-person approach with moderated sessions and a task-based script. The participant list included Zambian developers, product managers, and entrepreneurs who were recruited directly via email.
The interviews were semi-structured and consisted mostly of open-ended questions. This format encouraged participants to express their perspective on a topic. In this case, we delved into their job, their previous interactions with developers portals, and their experience of the website prototype.

Project outcomes

Overall, the project the stakeholders were thrilled with the designs, and they signed off the work. Unfortunately, I only managed to conduct a single usability test and interview before I had to hand over the design work, assets, and prototype to the Zoona team. It was primarily due to the project having a fixed budget and, as a result, I could not fit in all the testing sessions. Fortunately, the design utilized common patterns, and the content would be relatively easy to update, so the risk associated with proceeding with an untested solution was relatively low.