"Tobias": Progress tracks

Scoping

My first step was to scope down this larger initiative (internally termed Tobias) to something that would be manageable in a roughly 4-week design sprint and would enable us to address our lack of structure as soon as possible. I met with our Head of Piano to discuss the broader scope and feature base he had in mind. We also identified specific ways Tobias could help us mitigate churn.

That became the basis for the initial release of Tobias: Progress Tracks. Progress Tracks are sequences of learning-focused tutorials and interaction-focused labs that build a user's competence toward a particular goal.

However, Tobias was conceived of being (and ultimately should be) much more than sequenced lessons. We had to be mindful of being able to accommodate additional features (such as user-created Tracks) in the future and to create a plan to do so, while leaving time to learn and pivot from each release we push to the site.

Research

I started with competitor research, centered around other music-focused subscription e-learning apps. However, Progress Tracks were designed to solve relatively specific problems for us so I had to ask myself a lot of questions during the research process, including:

• How do other services help people decide which course to start?
• How do other services help people tell if a course is appropriate for them?
• What kind of options do other services provide people to customize their learning? (Although we weren't planning to make this feature available in V1, we wanted to see what kind of accommodations we might need to make when this expansion is made later on.)
• How well do various approaches to learning structure (strictly regimented vs. free to choose) serve the specific problems we're wrestling with at tonebase?

I also did a lot of internal research. Because Progress Tracks were a completely new feature, we asked as many questions of ourselves and each other as possible to try to surface everything we would need to account for during the design process. (Seriously, you should see some of these Notion docs ...) Examples include:

• What are the fundamental differences between our existing lessons & courses and the contents of a Progress Track?
• How will tutorials and labs fit into our existing data structures?
• To what extent should we 'gamify' Progress Tracks? In what ways does that kind of interaction resonate with the people we expect to use them?
• Should individual tutorials and labs, being shorter and differently structured than our normal lessons, be accessible through search? If so, how do we set appropriate expectations for that difference through our existing interface?
• How will we (and to what extent do we need to) indicate progress through a Track as a whole versus progress through an individual tutorial or lab?

Ideation

My next step was to start sketching and throwing together low-fidelity explorations and picking apart their weak points.

One approach I like to take is 'Frankenstein-ing', during which I cobble screenshots from comparable services together into a pre-low fidelity version of what we imagine a page or feature to be. I then imagine it functioning on our site and identify aspects of existing design patterns that don't necessarily work for our use case. That enables me to then design individual page elements having already gotten a high-level view of how they will fit together on the page.

At this stage, I worked closely with our Head of Piano and another member of the content team (both musicians), meeting for short periods of time once or twice daily to bounce ideas off them and facilitate rapid iteration cycles. This also enabled me to pick a musician's brain throughout the design process in terms of typical learning (and teaching!) habits.

Testing

I designed a user test to stress test a few different areas of the prototype. This was most useful for refining interaction details in the flow. There were no huge, glaring issues with the product but we did change some details as a result of the behavior we observed during the test. For instance, we initially wanted a way for people to jump straight into the player from the Progress Tracks page. These expectations weren't set correctly in the initial design and quite a few people were surprised to find themselves there when they simply wanted more information about a given Track. Although these changes seem small and didn't take long to address, avoiding unexpected interactions makes for a much better user experience.