API Tutor

An Overview

The Challenge

There is a glaring underrepresentation of minority male and all female populations in tech. Early intervention can help mitigate these gaps in representation, but coding and general API-documentation as they are presented today can be quite intimidating. Often, it is difficult to know where to begin.

The Solution

Our team developed a user interface that is accessible and inviting, both in presentation and curriculum, and verified through surveys that those who are curious about various APIs can:

  1. gain a better understanding of what APIs are,
  2. learn about what data can be made available through an API, and
  3. explore how to make use of that data.

My Role

UX Researcher: Persona creation, storyboarding, contextual inquiries & ethnography, affinity diagraming

UI/UX Designer: wireframing, low-fidelity prototyping (paper & Balsamiq), high-fidelity prototyping (FramerJS & HTML/CSS), Adobe Creative Cloud (Photoshop & Illustrator)

The Case Study

An incorporation of our developed personas, Jo, Chris, and Brittany, to illustrate a current scenario of learning how to code within a social environment.

User Research

Our cohort came from an after-school program called Code510: a program for students who come from underrepresented groups within tech around the Bay Area. Technical breadth — including familiarity with APIs — varied amongst the students.

The team conducted a top-down approach in conducting our contextual inquiries, observing how the students interact with the resources currently at their disposal (such as Code Pen, text editors, the Internet at large) as well as their environment (such as other students, the program teacher, notebooks). In this way, we were able to grasp their values, dispositions, and applied our findings to constructing an affinity diagram.

A report detailing this entire initial process can be found here.

An affinity diagram, as a result of a brainstorming and reflection session soon after a Code510 workshop.

The main take-aways from our user research were the following:

  1. Students want to express their creativity while encountering minimal frustrations while coding.
  2. Frustrations stem from a lack of organization of their workspace, not knowing where to begin, and not knowing how to troubleshoot their code.
  3. When things become too frustrating, the reluctance to quit shrinks, and the task appears more intimidating.
  4. When a problem is overcome, it is often met with a feeling of euphoria, sometimes extending to a want to share their results with someone else.

Storyboards with Objectives

In order to mitigate disorganization and the frustrations that arise from it, API Tutor will house all necessary information in a way that is not cluttered.


API Tutor will direct the student directly to the API's documentation, and assist the student in decoding the sometimes confounding vocabulary used.


To lower the barrier-to-entry, starter-code will be provided for the user to model from and experiment with, resulting in an informative and hassle-free, gratifying experience.

The Design Process

Low-Fidelity Prototype

Our team created paper prototypes in order to quickly and efficiently iterate some changes after feedback from various subjects, including other researchers within the User Interface Design class. I was responsible for the landing page prototype, specifically. In addition to the paper prototype, I used a Balsamiq template within Pages to visualize the landing page a bit differently. A report containing photos of our paper prototypes can be viewed here.

Users found difficulty in interacting with a module without any priming or instruction, verifying our need for some walkthrough of the organization of a module. There was also some difference in interpretation of the social media icons present atop the landing page, which we will combine when we execute the landing page's future iterations.

High-Fidelity Prototype

After feedback on our low-fi paper prototypes, we moved forward with our educational module via a higher fidelity prototype, using FramerJS and Adobe Creative Cloud as our resources. We ran the prototype on a local server via grunt, with all files stored on github for users to access.

The visual design itself is not meant to be polished quite yet, as it is important to us that the underlying framework functions optimally. The goal of this step was to provide a functional prototype, such that the users could get a feel of the flow of a module. We chose SoundCloud's API for our example, as we've noticed our Code510 cohort conveys a strong interest in music.

Using Nielson's Heuristics to evaluate how well our prototype met user interactions and objectives — such as a want to see the jSON object, something we thought would have been overly intimidating to initially incorporate —  we were able to move forward, onto a higher-fidelity prototype.

Above is a .GIF showcasing the flow of a module, walking a user through some of the functionalities available through the Spotify API in the form of a role-playing activity.

Final Prototype

Fully rendering our product in HTML/CSS, Javascript, and jQuery, (with little assistance from Bootstrap) we refined the functional architecture of our module set-up and constructed a landing page for a more natural experience. I personally designed all icons and other visualizations present in the final prototype using Adobe Illustrator.

Icons to indicate the user's placement within the module. From left to right: Overview, Authentication, Communicating with Server, and Parsing JSON. The Authentication icon/step did not make it into the final prototype (shown below).
A screenshot of our final prototype. A progress bar is shown above via icons indicating functional segments of the module (overview, making an API call, and parsing through the JSON object). To the right is a narrative/instructional window, and to the left is a split-screen view of the JSON object retrieved, as well as a visual (a stage) representing successful data-gathering.

Our final prototype underwent user testing with our typical cohort, and upon completion filled out a survey. All of our users were able to successfully complete the Spotify module.

Through our testing, our users felt our product was strong in the following areas:

Our users also felt our product was weak in the following areas:

Reflection and Future Steps

By and large, our users understood the abstract idea of what they were doing. When it came to technically handling the calls and the data returned from the server, however, the understanding of the concept weakened. In listening to feedback in wanting to know what data was available when making an API call, and making the JSON viewable, we may have introduced different points for confusion: users provided values instead of their respective keys as their answers to the first Parsing step, for example. Completion of the second Parsing, and overall final step, showed that some struggle with the preceding question solidified understanding of how values are gathered from the JSON dictionary, though, suggesting that perhaps the initial struggle was helpful and conducive to learning.

I believe our implementation can be made more clear by selectively highlighting/emboldening words in the instructions and text, so users know precisely what in the JSON dictionary they are looking for. Also, it may be useful to provide definitions of various aspects of the code we provide, should a user need further clarification that inline comments cannot provide.

In addition to optimizing for other APIs, we can also implement a sharing functionality for people to export their final code for customization and use.