Compiling curated ScratchJr teaching materials for parents and educators

Challenge

How might we allow educators to access DevTech-approved teaching materials related to ScratchJr?

I took on this project as an independent study, hoping to apply UX design skills I was learning on my own. I picked up on previously conducted UX research by Hyejin Im and Eddie Futterman. I initially used these prior insights to rework the site’s UI design and determine its tech stack.

My Goal

Launch a functional website that allows users to submit resources pertaining to ScratchJr, which is an educational app that helps young children gain literacy in coding. The website needed to be scalable to serve possibly millions of existing educators who teach using ScratchJr in their classrooms or at home.

Why It Matters

For years, ScratchJr users have reported a need for teaching materials recommended by a verified source. Devtech Research Group is one of few authorities on ScratchJr best teaching practices, and has not had a central platform for making these recommendations. Providing such a platform would reduce the work time that ScratchJr representatives spend manually addressing individual requests, while minimizing frustration for educators who normally have to track down a perfect lesson plan on their own.

Outcome

Search, filter, and bookmark lessons vetted by ScratchJr experts

Easily Browse resources from all over the world, and download them for free. Create an account in order to Submit your own files with domain-specific metadata, such as the school subjects and learning criteria that your resource targets. This metadata makes it easy to filter resources by tags.

User Analysis

Educators want to enrich their child’s use of ScratchJr with minimal effort

Competitive Analysis

Filling a unique niche that other sharing platforms cannot

I assessed other online platforms that serve similar functions for our users, in order to gain design inspiration, as well as to understand how ScratchJr Connect could stand out.

e.g. Teachers Pay Teachers

Strengths: Ability to filter by many categories; rating and reviewing by established member profiles

Weaknesses: Resources are not free; site is not specifically for coding materials for kids

e.g. ScratchED

Strengths: Online community for Scratch educators; discussion boards; bookmarking

Weaknesses: Geared towards Scratch, not ScratchJr; threads get long and hard to skim

Task Analysis

Mapping site visitors’ wants and needs to site features

With support from previous project members’ research, I prioritized the core requirements of our platform based on its primary use cases. It was useful to map goals to features in order to make the purpose of everything I would design clearer.

I also broke down the steps to achieve these goals in a hierarchical task analysis. By identifying the steps it takes a user to achieve each goal, I could focus my design process on the flows most essential to users.

Wireframing

Communicating my design vision to non-designers

After initially focusing on building the product vision and design, I was responsible for hiring and training developers who could help implement that. Although our team had dabbled in Figma prototyping at the start, I quickly realized that I wanted to convey my ideas faster than I could mock them up in high fidelity. I returned to pen and paper to make sketches of key screens that we had not covered in previous prototypes.

High-fi Prototyping

Conducting think-aloud testing with target users

I conducted Think-Aloud tests with 5 individuals with backgrounds in K-12 education. Through these interviews, I uncovered usability issues and additional feature requests by asking participants to Browse and Submit resources via our Figma prototype.

What we learned from 5 usability tests

1. High-level categories for resources were overcomplicated: Although generative research suggested we should sort resources into 5 categories, users reported confusion about the distinction between "Lessons" and "Activity Plans". This fueled later discussions where we finally settled on just two categories, “Activities” and “Project Showcase”.
2. Educators want to verify the science behind ScratchJr: Users wanted to learn more about the “PTD Rating” out of five stars that every resource received from Devtech. This pushed us to provide clarity in how we displayed this rating—a five-star system wasn’t sufficient.
3. Internet speed greatly affects user adoption: One participant pointed out that most schools have slow wi-fi, making every successive page-load a hindrance to successful submission. We decided to spread the Submit process across fewer pages, to prevent users giving up halfway through.

Look & Feel

Getting detailed with UI specifications

Based on learning from our usability testing, I created high-fidelity mockups of the ScratchJr Connect entries that would be a key focus in the browsing experience. This addressed insight from educators, introducing a revamped information hierarchy which spoke to the tags and granular DevTech rating that testers were the most curious about. I tried many combinations of color and contrast to see for myself how visual styling contributed to the playful nature of the website while remaining informative at a glance and not too overwhelming.

Reflection

Fail fast—it builds character!

I learned firsthand the drawbacks of jumping too quickly into Figma. Although we uncovered a lot from think-alouds with a high-functioning prototype, it was heartbreaking to implement major insights from our research and completely scrap the screens we had spent weeks on. I've now learned to test sketchy wireframes before moving onto higher fidelity prototypes.

This need for speed extends to our testing process. Now that I swear by affinity diagramming, I would re-do this project with a scrappy mindset so I could feel more empowered to routinely speak with more users.