Case Study: Schoolio

The Challenge

For this project, the challenge was to reinvent an outdated curriculum customization platform so that it would meet the real needs of K-12 teachers and students. It was old, cluttered with features, had poor usability, and was difficult to change because of legacy code and infrastructure. It also didn’t integrate well with Google Apps, which had been adopted by our school district partners.

The product owner and stakeholders wanted to modernize the design and functionality of the platform. It was still too confusing for teachers, and the big push was to make it useful for students as well. After some team discussions and analysis of products in the same space, it became clear that we needed to leverage and integrate with existing ecosystems such as Google Apps.

The Approach

I recommended using the Google Design Sprint methodology to develop a concept and prototype for the new product. I was convinced of the value of the focused, rapid design iteration and prototyping process, and it didn’t take long for the P.O. and team to agree to it as an “experiment.”

We customized Google’s process a little bit, shrinking the design activity itself to just 2 days instead of 5 (largely due to the difficulty of getting the whole team in a room for 5 days), yet otherwise we followed it closely. We had one facilitator, and a diverse team to collaborate on design which included Cognitive Psychologists, Educators, and Software Engineers.

Having already “set the stage” and done the “unpacking,” we were able to focus our formal “sprint” time over 2 days to the Sketching and Deciding part of the process. Based on that work, I designed and built a prototype (with lots of feedback along the way from team members). Finally, we tested our prototype with both students and teachers we’d recruited for that purpose.

Schoolio Storyboard
Storyboard for Schoolio

Most of our first workshop day was spent creating the Storyboard. Once the team was satisfied with the story, we worked individually to generate as many design ideas as possible, then came back together to evaluate them. We repeated this a couple of times and had tons of good ideas to choose from.

On our second workshop day, we worked as a team to narrow down to our best ideas and decide what to prototype. Everyone was exhausted by the process but had a great time, and we all felt like something new and different was taking shape. The vision was coming together, and could be something really cool.

Finally, it was time to start prototyping, and it was up to me to deliver. I knew it had to be done fast, and that coding would take too long. I decided to keep it simple and use Omnigraffle to create clickable wireframes. I iterated over the prototype for a day with one of the software engineers on the team, and then were ready to show it to some real people!

Mockup of Schoolio New Event
Mockup of New Event in Schoolio

Mockup of Ecology Lab in Schoolio
Mockup of Ecology Lab in Schoolio

The Results

The response from teachers and students was overwhelmingly positive. While a few of our team members tested it with their K-8 aged children, the rest of us took it to a digital educators conference for ad hoc testing with teachers. The prototype product was seen to be a massive improvement over the existing product, very clear and easy-to-use, and something that would be incredibly useful.

This project was a lot of fun and a great learning experience for myself and the entire team. It laid the foundation for what could become a tremendously useful product in the K-12 classroom. The Product Owner had a vision, and by using the Google Design Sprint methodology we were able to really bring it to life. I would highly recommend the Google Design Sprint Process to any product team, and hope to participate in many more Google Design Sprints in my career.

Learn more about my work for NCAR/UCAR.

This entry was posted in Case Studies, Product Design, User Experience, User Interface, Web Applications and tagged , , , , . Bookmark the permalink.