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.
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:
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)
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.
The main take-aways from our user research were the following:
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.
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.
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:
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.