Running our First Design Sprint
This is a cameo post from our amazing Head of Product, Jocey Karlan!
Make Learning Fun
Learning should be fun. Amidst the many debates raging in the education space, this concept is rarely contested. But while we may agree on the mission of creating inspiring, supportive, and fun learning environments, the method is harder to pin down. Certainly, learning can be fun, but it can also be arduous, tiring, and, at times, frustrating.
At NoRedInk, we believe in mastery-based learning, a paradigm that requires students to prove their understanding of a concept before progressing to the next one. This is drastically different from many traditional models where students move from unit to unit or grade to grade based on a strict timeline. In the world of mastery-based learning, students can’t simply move on after 20 minutes or 20 questions. Rather, they progress at their own pace as they learn.
When we take away easy outs and guaranteed advancement, preserving the fun of learning presents a greater challenge. To make learning fun, we must…
- Foster a growth mindset and motivate students who are really struggling
- Develop resources to help students feel supported as they work
- Celebrate progress and not just completion
- Provide a delightful visual environment that fosters joy as well as learning
Sprint
Last winter, an advance copy of Sprint arrived from our investors at Google Ventures. Our Product team was drawn to the book’s core premise: carve out 5 days to work on nothing but a single tough problem, condensing a full design-develop-test cycle into one week.
We had a tough problem at hand. For months, teachers and students had voiced feedback about our mastery-based practice engine. We heard regularly from students who felt discouraged or frustrated by progress bars that filled for correct answers and then emptied for mistakes. Instead of fun, for a subset of students, our engine was creating stress. Though we had tried to chip away at developing a solution, we had made little progress.
Thus, Sprint proposed an appealing course of action, and we set out to answer one core question: How might we make students feel like they’re continually making positive progress toward mastery? We called this question “the mastery problem.”
The Team
We put together a cross-departmental team composed of one PM (myself), one developer, and two UX designers.
The Plan
Sprint suggests setting aside 5 neatly slated days. The schedule progresses from mapping out the problem, to sketching solutions, to deciding on a best option, to building a prototype, to finally testing with real users.
We used this calendar as inspiration and built a schedule that allowed more time for prototyping and less for decision-making. This was made possible by assigning pre-work to each member of the Sprint team, which included preparing competitor analyses and reading messages from teachers and students.
The Schedule
Day 1: Map and Sketch
- Lightning talks: Members of our Support, School Partnerships, Product, and Engineering teams gave 15-minute presentations, sharing their context on the mastery problem.
- Competitor analysis: Each member of the Sprint team presented on 2-3 mastery-based learning platforms.
- Problem mapping: The Sprint team organized our notes and ideas into various themes (see image below).
- Sketching: We tried a few sketching activities suggested in Sprint and also allowed for quiet, contained sketch time.
Day 2: Decide
- Gallery walk: Each member of the Sprint team posted 1-2 solution sketches around the room. With stickers in hand, we marked the elements of each design that stood out to us.
- Core themes: We looked for trends in the solution sketches and identified the features that we wanted to implement in our prototype. We trimmed down the list to 6 core themes.
- Ongoing sketching: We spent another hour sketching and discussing ideas as a group before electing one of our designers to mock up our favorite designs.
Days 3-5: Prototype Here’s where we really “broke process”: Sprint recommends building an extremely low-fidelity prototype that leverages Keynote or prototyping software like InVision. In our case, however, these options wouldn’t cut it. InVision and Keynote are fantastic for testing in controlled environments with a limited number of possible user behaviors. We, in contrast, needed to give kids of widely varying abilities enough freedom to succeed or struggle; only then could we test authentic emotional reactions to our interface.
With exponential possible paths to completing our activity, we opted to engineer a solution (see GIF below). While this solution took a few extra days, we were able to move to largely asynchronous communication to free up team members not immediately involved.
Day 6: TestOn the last day of our Sprint, we visited a San Francisco high school and worked 1-on-1 with 8 freshmen students. In case you’ve never done user testing with 14-year-olds, it’s worth noting that their brutal honesty provides data of unmatched quality. These students’ insights and reactions informed many of the changes we implemented after our Sprint.
In summary, here’s how our schedule turned out:
What’s Next
In the weeks that followed, we visited one other school to work with students of a different age group and demographics. One of our designers continued to build out various interactions, pairing closely with two developers. Our Product team started to flesh out a spec and brought in a QA analyst to evaluate those initial guidelines.
Conducting our first design Sprint allowed our team to take a long-standing, messy, and emotional problem and come to a solution. Today, we’ve committed to addressing the “mastery problem” in the first quarter of 2017, an undertaking that requires redesigning our entire quiz engine, overhauling old code, and moving student answer data to a new part of our database. While much work remains, we’re confident in developing a solution informed by and built for our users. We can’t wait to release to production.
Like learning itself, creating fun learning experiences for students isn’t easy. But tough problems, a great team, and an inspiring mission are what make being a PM at NoRedInk a delight. Looking for your next role? We’re hiring.
Stay tuned for a follow-up post on how our mastery problem became our mastery solution.
Head of Product at NoRedInk