CC API Portal

Overview

During this 1-month project, I worked individually to design an API portal for a non-profit named Creative Commons(CC) that enhanced developers’ experience managing their CC API. Through weekly check-in with clients and mentorship from James Reffell (Design Director of Clever), I was able to address client’s need by defining feasible scope, project goal, user’s needs as well as delivering a high-fidelity mockup ready to code. The final outcome was highly prized by my client, claiming that it helped Creative Commons think about directions moving forward.

Process Overview

I followed a double diamond structure to guide my design process. Applying various techniques and tools in the converging and diverging cycle, I was able to iteratively improve my design to stay on track of client’s need and project goals.

Creative Commons’ request

Creative Commons supports Artists with free copyright licenses and provides a CC search service for all users to find artworks that they can use with attribution. The API service enabled users to embed the CC search on their own websites. Currently Creative Commons only has an API documentation page. The request was to design a portal for users to perform a list of tasks:

• create an account

• create and manage API keys

• monitor their API usage, including success and error rates

• request increases in the API usage limits

• view API documentation

Define the problem

Although given features backlog, it was not clear what goals am I aiming to achieve by incorporating these features. Thus I kicked off my first client meeting trying to find out what’s the key problem and who are the key users? I found myself asking the following questions: 

Having answers to these questions helped me define the problem statement:

The key words here are CC’s existing resources and developers, which can be further summarized to two key groups of stakeholders: the primary user: Developers and the client: CC Engineering Team.

Developers — Understanding users’ behavior patterns

With limited understanding of what defines a user-friendly interface for developers, I found the user research part one of the most challenging stage of this project. I approached this challenge by exploring what existing product’s documentation page and API dashboard they find the most intuitive. Through casual interviews with several developers, I was able to generate these key insights:

CC Engineering Team — Need of a sustainable solution

Through a week of frequent emails and online chat, I learned that the need of CC Engineering team is to have a sustainable solution as the number of users continued to grow. I translated this need into 2 design goals that guided my design:

1. Encourage more users to register for an API account: Creative Commons offers higher rate limit for registered users. To maximize the help users get, registration is a must. 

2. Minimize direct customer support from the Engineering Team: Considering Creative Commons’ small engineering team, the API portal should ideally provide enough resources for users to debug on their own.

The Design Solution

Documentation Page Redesign — Encourage more user registration by highlighting key benefits to decrease cognitive load

To be encouraged to register, users need to firstly realize the benefits they get as a registered user and secondly be able to register easily. On the current documentation page, these information will be easily missed. The following two mockups illustrated how my redesign successfully improve readability of the key information.

API Portal Design — Minimize direct customer support from the Engineering Team by enabling self-serve troubleshooting in the API portal

Without the API portal, users can only inspect through web or contact the CC engineering team when they encounter errors. With the new API portal dashboard I designed, customers will be able to access key information developers need to manage and debug their CC API.

First step of the design is to define what information need to be included on the dashboard. Through communication with the engineering team and developers, I crafted the following Information Architecture:

Since each sections of information aren’t space-consuming, I decided to apply a single-page design with fixed menu on the left that enabled users to jump to the section they want to view. The following final design successfully visualized the key information needed and highlighted key design decisions I made to visualize information in the clearest way.

Visual Design — Adding a neutral color to the palette

Creative Commons used a bright tomato orange as the branding color. Yet for a portal which majorly visualize backend data, the tomato orange is too bright on the eyes. I proposed adding a bright neutral blue to their color palette and the primary color of API portal design. After confirmation from the client, I used the following design system for my portal design.

Delivering Design

“You did an outstanding job and you put a lot of creative effort into making something rather dull into something enjoyable and attractive. I believe this achieves your goal of engaging developers.”

— Mentor’s comment on the final design

At the end of week 4, I delivered my figma design file along with a design brief outlining key process, goals, design rationales and the delivered file. I also presented my design to my client remotely and to my cohorts in class. Creative Commons were thrilled to receive my design and said they were really impressed.

Next Steps

Different status & micro-interaction

Given 4 weeks from initial touch point to final delivery, I was only able to iterate on the larger framework and skeleton design of the interface. On the micro level, there are still lots of detailing design to be done before the interface is pixel perfect. For example, for hourly, daily, monthly, the usage statistic will look a bit different with adjusted margins.

Design validation with real data

The final design was highly approved by several developers I showed to. Yet one of the limitation of my design can be the result of not being able to work with real data. In future iterations, this concern can be addressed by working side by side with the front-end developers of the Creative Commons team. I believe that linking the design interface with real back-end data can infer more meaningful insights to make design modifications.

Takeaways

1. The Challenge & fun of designing for unfamiliar subjects: For me, the major challenge of this project was not sketching out the design, but understanding the subject matter: What is API and What are developers familiar with. With no experience using an API before, I found even my client’s request hard to understand at first. Yet I was able to breakdown the challenge one piece at a time by communicating with client, talking with several developers, educating myself through blogs and signing up existing API account. Once I understand the concepts, the rest of design process became more fluent than expected. Overall, it was a fun exploration adventure. Working through this process swept away the fear of unfamiliar subjects and gave me more confidence in designing for similar circumstances in the future.

2. Face ambiguity by applying agile methodology to planning. While designing for client, it is common to began with ambiguous requirements and in my case, even no problem statement. Haven worked with multiple clients previously, I found myself able to define my personal workflow and lead meetings with clients fluently. More Than that, I was able to apply some of the agile methodology I learned in Product Management course this fall by breaking up tasks, setting small milestones each week and adjust plans based on weekly check-in meeting with my client. This work methods helped me clarified ambiguity, avoided misunderstanding and greatly increased my work efficiency.