Weather Company API Portal

How might we improve the experience for developers and Weather Company API administrators when provisioning and utilizing Weather Company APIs?

The Weather Company APIs are some of the most used around the world, powering applications across a wide range of industries. IBM needed to expand The Weather Company’s API offering; in the first year after TWC’s acquisition, requests for new API keys more than doubled.
This growth highlights the need for TWC to provide a seamless and satisfying API experience for its users. Our design team redesigned the API Portal to provide such an experience and set the stage for TWC’s continued expansion.

the existing API portal before the redesign

We began by getting familiar with the current API process. Weather Company team members managed APIs through a very manual process. There were inputing API customers in a spreadsheet after getting API requests via a webform. The site for API management (shown above) was in need of a visual refresh.

How we worked

A multi-disciplinary team consisting of one researcher, two Front End Developers, one visual lead and one UX lead (my role) We started by interviewing the individuals that are responsible for managing this process and then interviewed several developers that regularly use APIs in their work. We pulled insights from those interviews and used these to start ideating ways to create our API portal that would address the needs and ways our users like to work. In addition we completed a cursory site audit to see how the site was structured.

The interviews yielded some key insights that were shared back with stakeholders.

Anne Jordan

“Developers move quickly. Stuff comes up all the time you have to play with and learn. I get my gratification from making stuff work.”

Insight 1

The main priority of an API site is to allow Anne to access her key and start coding.

Supporting Characteristics

Anne and other developers want to be able to find and use their API key quickly. Anne’s first goal when she initially arrives on an API site is to make a test call and start to understand what the APIs to which she has access can do.

Insight 2

API Documentation should show text and code side by side to help Anne quickly get to productive use.

Supporting Characteristics

Show, don’t tell. Actual code snippets are more helpful than long explanations. They speak in developer’s language and let Anne more quickly parse calls and responses. Anne is looking to work and learn quickly. Speaking to her with code helps her get up to speed and be productive faster.

Insight 3

Help Anne effectively manage her API usage. Support functions are secondary.

Supporting Characteristics

Surface relevant API usage info to help users manage their account. This value-add simplifies the experience for Anne and is an additional benefit TWC can provide and possibly monetize. Leave community building and knowledge bases to Stack Overflow. Anne prefers “known” resources, and policing message boards is an unnecessary and time-consuming distraction.


Ideation is quickest when we move fast and don’t invest too much time or effort into the work. This makes it easy to try something, gather feedback and reject or refine it. I use hand sketched wireframes to help communicate our thoughts as our team started to explore ideas. Here are some of the sketches I created in our early rounds of ideation:


Our team set up a regular cadence of design playbacks as we worked through our early concepts. Getting feedback at the early stages helped us stay on track and kept our stakeholders in the loop with how the design work was addressing user needs.

What we achieved

By representing the voices of our users through interviews, we armed ourselves against a potential mis-step. When showing the user insights to our stakeholders it was evident that we were emphasizing user needs that hadn’t been as considered. Within the six months that our team worked on this project, we produced a coded prototype of the API portal site for The Weather Company and shared our research findings and concept work.


These are presentation hi-fi screens showing the log in screen that uses Weather API to generate a wind map. Notifications and notification banner.


These are presentation hi-fi screens showing service tickets and ticket management.

Lessons learned

Our key stakeholder had a title change and a priority shift while we were working on the project. Because we had built good rapport and trust with him, we were able to finish the work we had started. Forming partnership with stakeholders is key, and the best way to do this is to build trust by being great communicators and following through on the commitments we make.


© 2019 Matt Cardinal. All rights reserved.