Heartbeat

Summary

Our team developed and designed an SEL tool (Heartbeat) which allowed students to explore their own learning factors and find solutions without being placed into prescriptive boxes.

Problem

Shmoop needed to expand its offerings beyond just a simple content and curriculum provider. Teachers needed a way to scale their 1:1 interactions with students to better personalize their education.

Contribution/Role

I served as the primary UX Architect, UI Designer, and User Researcher.

Figma Prototype Links

Interviews

In doing some general interviews with teachers, we asked “What is one thing you wish you knew about your students that you don’t currently?” Most responses related to “I want to know something unique about them to help me connect. I want to know what they’re struggling with beyond School.”

Hypothesis

Teachers can best help a student when they know something unique or personal about them. But this can take a lot of time investment for teachers. Many students want to express themselves but have a hard time doing so in more public circles.

Initial idea

As we began, we had a concept for representing all the learning factors for a student in a holistic data presentation. We went through many iterations, considering how to represent all of a person.

But as we continued, we realized we were making the same mistakes our competitors did. To quantify a person is to oversimplify them (considering the human brain is the most complex system observed in the universe).

We dove deeper into our goals. Was our goal to make charts so that educators could pretend that they understood everything about a student? Or, was it to help educators and students connect, and help students understand themselves?

The goal of so many of those all-encompassing data models was that if you gathered everything together, then maybe you’ll see trends and insights in the data. For one, this put all the cognitive load on the user. For two, why wait to get to the insights? If we had the tools, then we didn’t we just provide the insights?

Revised solution

We began to modify our approach. We would still set up a system to ask questions of students and begin to gather information on their learning factors, but the data display would not be prescriptive, but suggestive. It would offer potential observations, allow students the agency to reject such observations, and offer potential explanations, actions, and solutions.

We rejected the idea of holistic student data representations and embraced the idea of suggestion. If a student answered questions that suggested they may be struggling with reading because of vision problems, we couched that insight into non-prescriptive language.

The Board

To begin, we needed a way of gathering said information. Since we wanted to keep the system open and driven by student agency, we let students ignore or select whatever questions they wanted. We also protected their privacy by not showing educators the students’ direct answers, but by showing trends in categories we called “scales”. These were categories of questions that were so granular that they couldn’t really be broken down further. These served as the data backbone of the Student and Teacher report and insight experiences. By boiling down to pure elements, we avoided overgeneralizations that many other systems made.

The Pulse

The data layer was built to communicate potential reasons and solutions to the students’ various learning factors. Students also had the ability to offer feedback on how well this evaluation represented them. We used this feedback to update the factors and their associated questions.

Note: Most content has been removed from this page to protect Shmoop IP.

Handraise

Over time, we added other features, such as Handraise. This allowed the student to highlight whichever factor they were on, indicate how they felt about it, and notify a teacher.

The biggest challenge with this feature was building it around the various legal difficulties. Every state has a different method for dealing with severe issues. We needed to avoid legal liability, while still offering a way for students to easily let teachers know they wanted to talk. One part of this solution was to not allow any open text fields either to or from the teacher. We also (earlier in the project) did not include any high severity questions (such as concerning abuse) so that we would not be legally liable. But, we hoped that a digital tool to notify a teacher that student wanted to talk would help alleviate the stress of asking for help in person.

Educator Experience

The Educator Experience was where many of our anti-prescriptive and pro-suggestive principles came into play. Our first iteration was a data display that showed students’ data related to scales and whether they sat more to one side or another.

On doing some experience testing, however, we learned that this data display was too granular, and made the user do too much work (a hard pattern to escape).

The first solution to this issue was the Dashboard. A system designed to gather the most relevant information and display it to the educators in a simpler format. They could still dive in for more information, but the Superpowers, Challenges, and Favorites sections displayed on the dashboard gave them a higher level view of their classes. This page was received with much gratitude by the users!

Collections

Teachers and other educators already had lenses with which they measured students success (such as Utah’s “Portrait of a Graduate”). This led to the development of collections. Figuring out how to summarize broad trends in a digestible format. Collecting handfuls of factors into “Collections” which were relevant to each school district.

So many frameworks.

  • CASEL
  • Learner Variability
  • Common Core
  • A specific school district’s metrics of a successful student

Which model to go with? Which to choose?

All of them.

Users skimming granular data to find something relevant was too much work. And if it’s too much work, the user won’t do it!

Rather than grouping the scales by some arbitrary framework (whether our own or someone else’s), we decided to allow educators to create their own. In fact, since we are primarily a B2B venture, our Customer Success teams had the power to gather data into relevant categories for our bigger clients even before deals were signed. These categories pictured here are made up of our granular scales, but organized according to the Utah Department of Educations “Portrait of a Graduate.”

This was a game changer. Now, we could adjust the system to match the local language and structure of each client. A new tool with a learning curve tends to be ignored, but a new tool that speaks the local dialect? *Chef’s kiss*

Use the language and mental models of your users whenever possible. And remember, that you (your company) are not the most important thing in their life. You’re probably pretty low on their list. So, be useful, be relevant, be helpful, then get out of the way!

Results

The company went on to win many awards (such as “Best of Show” Tech & Learning Awards at ISTE Live 2022), and our company doubled our annual recurring revenue for school sales. Heartbeat sales in particular have doubled year over year.

The most important result

But, most importantly, we created a tool that helps students understand themselves, gain vocabulary in communicating their needs, and define themselves through self-creation.

“I really like the Heartbeat app because it helps me calm down and be confident.

Student

“I like using Heartbeat because it is like something I can let out how I feel kind of and I can just be me and honest.”

Student

“I like Heartbeat because it helps me talk about what I do.”

Student

“Heartbeat is a nice way to get stuff off your chest and you can answer questions.”

Student

“It’s like an online therapist except there is no talking.”

Student

Blog at WordPress.com.