Published on | Prototyping: From UX to Front End — Medium Nate Parrott

Ask a high school student how they study for the SAT, and no matter your age, you won’t be surprised: despite growing up in an era of cutting-edge digital distractions, the YouTube generation still studies vocabulary the same way grandparents did: paper workbooks. But look deeper into vocabulary education today, and you’ll see an uglier remnant of the past: systemic inequality.

Long after questions about oarsmen and regattas were taken off the SAT, the test still shows a racial bias, especially in the verbal section. It’s just one symptom of the chronic inequality that still plagues American education.

When I met Austin Martin in April 2017, he’d already been working on a project called Rhymes with Reason for three years. He’d been visiting Providence middle schools and using hip-hop songs to teach vocabulary. The potent wordplay and deep vocabulary of hip-hop was ideal for teaching SAT and Common-Core words — and the kids loved it.

Austin showed me the current Rhymes with Reason website — as a coder, I was blown away (and a bit taken aback) by the interactive vocabulary program he’d managed to build, with zero coding knowledge, using WordPress plugins and APIs. When the told me he had schools paying for it, I was intrigued.

Over the summer, I teamed up with Austin to make Rhymes with Reason into a full-fledged, web-based vocabulary education platform. We set out to modernize vocabulary education in more ways than one — building a modern vocabulary workbook, and chipping away at the achievement gap between white and minority students.

This article focuses on the design and technical challenges of bringing Rhymes with Reason to life — for more background on the ideas and content behind Rhymes with Reason, check out Austin’s TedX talk, or these articles from NPR and the Brown Alumni Magazine.

Step 1: How do you “teach” vocabulary?

Rhymes with Reason’s goal is to teach vocabulary using hip-hop lyrics. But how do you teach vocabulary?

There’s no “one true approach” to teaching vocabulary — certainly not one that’s been discovered yet — but we know that through building, testing and iterating, we’ll get better and better at it. But we have to start somewhere.

An example of the type of workbook experience we used as our baseline — this is what we’d be improving upon.

Today, many schools use vocabulary workbooks — little books with various fill-in-the-blank-style exercises that students fill out and teachers grade. We made the vocabulary workbook our baseline, challenging ourselves to be better, cheaper and more relevant than the venerable workbook. We looked at existing vocabulary workbooks — as well as more cutting-edge language education tools like Duolingo — and crystallized the first version of Rhymes with Reason’s educational structure. We built a linear, week-by-week “workbook” structure, with new vocabulary, warm-up exercises and a quiz for each week.

An early wireframe of the learning experience.A later, more high-fidelity mockup.For the new-word page, we strove to be as engaging and informative as possible. The music and lyrics are front-and-center, but definitions and explanations aren’t far away.

Content pages: the building blocks of learning

Rhymes with Reason has a lot of content: about 10 weeks worth of exercises, each with 10 new vocabulary words, 10 song clips, 10 warmup exercises and a quiz. I wasn’t creating the content myself — that was Austin and his team’s job — and the last thing I wanted to do was take all the content and laboriously code it, page by page, into an interactive website.

Instead, I built a content management system — an interactive tool that Austin and his team could use to create entire sections of content. Editors drag and drop different content blocks to form a content section — a self-contained unit of learning that students work through.

The three original building blocks of all Rhymes with Reason content — and three more we’re working on.

The content-management system is one of the parts of Rhymes with Reason that we’re most excited about, because it lets educators and experts build online workbooks that teach anything — not just vocabulary — with incredible speed.

Editors can create content for Rhymes with Reason without any code, just by dragging and dropping different content blocks into the right order.

Our initial prototype shipped with three content blocks — a “new word” page, a multiple-choice quiz question, and a title page (for breaking up a section into subsections.) After the initial launch, we built two new content blocks, for a new workbook we’ll be offering in the coming months.

Choosing a visual identity

Rhymes with Reason’s original WordPress site

Branding a product like Rhymes with Reason is a bit of a balancing act: it has to be cool enough to appeal to kids, while staying sophisticated and professional enough to appeal to educators and parents. I collected inspiration from a variety of sources — from music streaming services and language-learning-apps, to sites like Genius and forward-thinking “content” sites like The Outline.

Part of a Figma board I used to collect images during branding ideation.

Eventually, we settled on a sparse scheme — four colors, a single typeface, and a couple flashy flourishes for special occasions. In a Figma document, I outlined the building blocks of Rhymes with Reason’s visual style:

The first prototype

From left: the landing page, a student’s homepage, a teacher’s view of a class, and the team’s internal content editor.

We ended up with a consistent and conservative interface, characterized by sidebars and large white cards of content. Due to time constraints, most the the interface was utilitarian — but we did find time to sprinkle a couple playful flourishes throughout the UI:

Sidebar: calendars are a bad way to enter dates and we should do better

The actual interaction design of Rhymes with Reason is pretty by-the-book, but I did feel compelled to deviate from the standard on thing: how you enter dates.

Teachers on the platform can assign students work, and specify a due date. Most sites give users a little calendar widget to pick dates, but I’m not a huge fan of them, for a couple reasons:

calendar widgets necessitate tiny, close-together touch targets, making mistake-free use difficult
inputting something like “tomorrow” or “next Thursday” into a calendar widget requires the cognitive overhead of translating these relative dates into months and days
inputting dates more than a few months in the future quickly becomes tedious

The natural-language date-entry widget, build with React and Chrono.

Rather than using a calendar widget, I build a natural-language date-entry widget. Rather than clicking tiny dates on a calendar grid, users can type a date however it makes sense to them: “next Thursday,” “Oct 26,” “tomorrow,” etc.

The natural-language date-entry widget looked like a normal text field, with the addition of a text label on the right edge that echoed back the date as it was parsed. The feedback is crucial for users, who are potentially unfamiliar with natural-language date entry, or unsure of what the software can understand.

Untanglinging the sign-up mess

One issue with our initial prototype was a bloated and confusing signup flow. We started with separate signup forms for instructors and students, added an option for school administrators to purchase activation codes, allowed teachers to redeem coupons, allowed students to purchase their own subscriptions, allowed existing students to join new classrooms — you get the point. The complexity of the signup flow was quickly becoming unwieldy. So with only a few days before launch, I threw away our existing signup forms — designs and code — and committed myself to build something better.

I began by making a flowchart to determine which forms each new user would need to fill out:

The flowchart became the philosophy I used to redesign the signup flow. I ditched shallow, hectic forms for a series of sparse pages forming a decision tree — quickly and effortlessly guiding all types of user through the signup flow:

User Testing

To find out if Rhymes with Reason was as intuitive as it needed to be, I did some light user-testing — both in-person and using UserBob.com.

I asked some participants to pretend they were teachers, trying to sign their class up for the site; I asked others to pretend they were a student who’d just been given an invite code by their teacher.

User Testing: Teacher Signup

I gave users the following prompt:

Rhymes with Reason is an education platform that teachers can use to assign vocabulary exercises to their students.

go to this url:

http://[redacted]/

1. Sign up as a teacher and purchase two classrooms (use credit card number [redacted]. You can use a fake name and email address).

2. Create one classroom named “Test classroom”

3. Find the classroom’s “quick signup link” and copy it to your clipboard. This is the end of the task.

Both users were able to complete the task in under five minutes, which was promising. Neither got frustrated, but I did notice a couple issues which tripped them up:

The home page had buttons labelled “Signup” and “Student Signup” — this seemed to cause confusion. Based on this feedback, I removed the “Student Signup” button.
One tester expressed confusion about the “Remember Me” button that appeared on the payment entry screen. This is a feature of Stripe, our payments processor, that allows credit-card information to be stored and used to fill out other Stripe forms. To avoid confusion, I turned of the “Remember Me” option.
One tester didn’t click the “enter payment info” button to enter their payment info. When they saw the error message, “Please enter payment info,” they tried to click it. In response, I changed the visual appearance of the “Enter payment info” button to look less like a link, and more like a form field, reinforcing the idea that it’s a mandatory part of the form.

The biggest pain point for these testers was locating the “signup link”. One tester spent nearly a minute searching, before finally discovering it; the other tester complained that it was “hidden.” Based on this feedback, I revamped the experience of inviting students to a classroom:

In both versions, teachers can invite students by sharing either a “quick signup link” (probably via email) or a “class ID and password” combination. In the new version, these take the form of explicit buttons. Clicking “Invite via email” shows the link, while “instructions” shows the ID and password. This, and the removal of “students” section when empty, radically reduce the clutter a teacher sees after they create a classroom.

User Testing: Student Signup

The prompt:

Imagine you’re a student, and your English teacher sends you an email. Follow the instructions as best you can:

Hi class!

This semester, we’re using Rhymes with Reason to practice vocabulary. I’ve posted your first assignment online.

You’ll need to sign up by going to [redacted].com and signing up as a student.

Our class ID is: english_301–XX

Our class password is: ABC-DEF

Once you’ve signed up, complete each question until you reach the word ‘adoration’.

Have fun!

Our tester — a 32-year-old sales rep from California — completed the task handily, and mentioned she liked the brand:

“I like the design, subtleties, nothing too overwhelming, but still trusting, which is always a good sign”

She hit one huge hurdle, though: she initially misunderstood how to sign up. Students are supposed to create their own account, with their own username and password — the classroom ID and password are used only to enroll the student in a teacher’s class. But this tester tried to use the classroom ID and password she’d been given to log in immediately.

It’s an understandable mistake. I added a small note at the bottom of the login screen, with a link to the student signup form — but I was worried that wasn’t enough. I realized that, because classroom passwords have a unique format, I could write code to detect when someone tries to log in using a classroom password, and show them a more prominent notice:

Once she found the student signup form, things went smoothly, except for a minor hiccup when she was choosing her password. She accidentally typed two passwords that didn’t match, and didn’t notice the error message, which was in light gray, and halfway down the page. I quickly fixed this by adding a “passwords don’t match” message directly below the password fields.

Prototyping Animations

Rhymes with Reason’s not a game, but it wouldn’t hurt for it to feel like one. Adding juicy little effects when students score points (or even when they’re just navigating between pages) could go a long way towards making Rhymes with Reason feel fun. Other educational apps, like Duolingo, have animations and visual effects spread liberally throughout, adding a dash of motion or a touch of action to make their exercises feel alive.

After launch, I began brainstorming high-impact places to add animation, and settled on two spots — adding animated transitions to the onboarding form and the student vocabulary-workbook view. I picked up Principle and came up with a couple prototypes:

Transitions between different forms of the “flow-chart” onboarding UI — the first thing users see when they go to sign up.In this Principle prototype, a “pop” animation greets a student who answers correctly.A prototyped animation between pages of content in the student view.

Principle is a great tool for rapidly prototyping native-app animations — but the unfortunate truth is that the infrastructure for building web-app animations still lags far behind native. Rhymes with Reason is built in React, and, while a myriad of animation libraries exist for React, all have significant drawbacks. They all tend to be good at animating simple lists — when an item’s added or deleted, items can be configured to slide in or out with ease. But all fall flat when trying to animate the replacement of something — the replacement of one page with the next, or one set of buttons with another. In the end, implementing these animations took more time (and more dirty code) than I was willing to invest. Only the onboarding transitions made it into the shipping product — and even those aren’t identical to what I could prototype in a couple minutes using Principle.

A friendly and unobtrusive in-app feedback experience

Collecting user feedback is crucial, and we want as much as possible — but it’s difficult to collect feedback in a non-intrusive way. We’ve all seen — and promptly closed — those annoying prompts asking if you’d like to take a short, anonymous survey to help improve your experience! We wanted to build something eye-catching, personal, minimal and not intrusive. Here’s our first iteration of that:

Left: the feedback prompt in context. Right: a simple feedback flowchart. Our system allows arbitrary flowcharts of questions — based on the buttons a user clicks, they’re redirected to different follow-ups.

The feedback prompt isn’t a pop-up — users can ignore it if they’re busy, and come back later. A key feature of this feedback system is that it’s flowchart-based — a feedback prompt can present multiple buttons, which lead to different follow-ups.

For example, we might ask “how do you like Rhymes with Reason?” If the user clicks a negative response, like “it’s okay”, we’d follow-up by asking“what can we do better?” But if they answer, “it’s perfect,” we’d follow-up with “Thanks! Anything we can improve?” When submitted, both these forms might show the same “thanks!” notification. Allowing different responses to reveal different follow-ups allows us to build concise, quick feedback experiences easily.

What’s next?

So far, feedback from educators and students has been overwhelmingly positive. We’re continuing to refine the core product, and Austin and his team have been aggressively adding content — thanks to the CMS, they’ve been able to quickly build U.S. History, Science and SAT/ACT Prep packages, which we’re rolling out soon.

Beyond that — we’re still figuring it out. How can we reach more people, teach more effectively or impact education more meaningfully? Leave a comment, or reach out — we’re listening.

Designing a more equitable vocabulary program, feat. hip-hop was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing a more equitable vocabulary program, feat. hip-hop

Top Stories