Narrative Product Development

Using storytelling to improve products

This is a case study and call to action, to envision and build products using stories.

Every product needs a vision, a guiding light to build towards. This can come from many sources — a single voice of leadership, an open source community, maybe a unified team. What I discovered during a project aimed at charting the future vision of our product here at Codecademy was a series of methods that helped our team come together to imagine, and now build such a vision. What unified each of these methods was the ancient tradition of storytelling. But, that’s getting ahead of myself — let me start at the beginning.

I spent the first day of this project digging through hours of user interviews we had conducted the month prior, and data about how our users engaged with our current product. What I kept coming back to was the countless stories about how people had used our product to change their lives, and in some cases how our product was failing them. This was the beginning, the first step in using stories to build product.

The following are the 5 key steps I took to create a vision using stories, methods we are continuing to use on a daily basis to build product here at Codecademy.

Step 1: Frame the problem and opportunities in stories

The first step is to frame the problems and opportunities as they relate to the most important people — users. To do this we used a customer journey which charts the general story of how customers use a product or service, and defines the biggest problems or gaps in the journey.

A key element in this process is gathering rich information and evidence about who the customer or user is and what their experience is like. To do this we took 20+ hours of user testing and interviews to define the key areas that Codecademy either wasn’t addressing, or needed to improve. This resulted in what we call the ‘learning journey’ illustrated below.

This is our “learning journey” that shows the high level stages of our users’ learning stories.

There are many variations of this journey each based on different learner types, but one example of a specific story is Sue’s Story. Sue’s a college student who graduates and uses Codecademy to learn how to code, and ultimately get a job. Sue represents our ‘career learner’ someone looking to gain skills to find a job.

Our physical site map being used in our office.

To gain an understanding of how all these problems and user stories related to our current product, I built a physical site map. This was made up of our courses, users, and each main part of our platform. This proved to be effective not only in grasping what we needed to improve, but more importantly, it was a physical space where our team could discuss ideas about how to solve the problems by improving our product.

Step 2: Solve problems in context

With the journey and problems mapped, the next step was to begin imagining solutions. At this point, it’s critical to involve as many team members as possible in small structured workshops focused on solving specific problems.

A great way to do this is with the How Might We exercise. For every problem you ask “how might we solve this?” and then discuss ideas ranging from technical ideas to business solutions. Be sure to document each solution with a sticky note.

Results from the How Might We exercise. The purple sticky notes are How Might We questions and the yellow are different ideas about solving them.

After a few days of these sessions with different members of our team we had ideas spanning technical solutions, business ideas, and wholly new products. I began organizing the solutions based on where they fit within the learning journey.

Ideas organized into the learning journey. I grouped ideas into categories and for each idea made a quick sharpie sketch and title.

Step 3: Stop designing, and write

Product features and ideas are important but they alone do not make a great experience. For an experience is human, it has depth and often is the result of multiple ideas and features elegantly woven together. This step is where you put your pencil aside, close Sketch or Adobe, and write.

Every good story has a main character and problems they encounter, so I began with our main character — our target persona. Then pulling from research I used quotes from users, the key problems that persona faced, and a ton of ideas from our team — everything I needed to start writing.

I constrained myself to 3 rules for each story: 1. It must begin the moment they need your product and end when they accomplish their goal (such as getting a job.) 2. It had to resolve all of the known problems using ideas from the team brainstorms. 3. It had to explain, in detail the features or product ideas.

Examples excerpts from a few of the stories.

Due to a story’s inherent accessibility, I was able to gather rich feedback quickly. This is the best part of using stories for this step — everyone on the team, from CEO to designer, can read an eight page story and instinctively share if they feel it represents the future of Codecademy. I was able to gather and adjust these stories in a matter of days.

Step 4: Design features to make the stories reality

With the stories written and the team aligned, the next step was to do everything I could to make the stories real.

I had three weeks to move from story to product and to do this I followed three steps. First I used storyboarding to move quickly and explore what would be involved in transforming each story into cohesive product features.

Samples of some of the story boards I made. Each story board followed a different user persona through their entire learning journey. The goal was to begin thinking about what products would need to exist to make the stories come true.

Next, I used the model of service blueprints for each key feature (a blueprint is a map that breaks down an experience into all of the actors and elements.) This challenged the ideas with a new level of detail and reality, forcing me to think through what it would take to build them, and where they would fit within our product.

Blueprint of how a user experiences a project on Codecademy.

Finally, I made high fidelity visual mockups of all the key features or products that were essential to the future vision.

A screenshot of my final vision book. I focused on designing out only the key features that had to be there in order to make the vision happen.

Step 5: Product roadmap and building

We had a vision in the form of a story. Within this vision there were many new features and products. So, how did we go about building, testing, and iterating on them? The key here is to act in context of the vision. We prioritized the features based on our current business needs and how we would implement them.

This last step will differ based on your team or company needs and priorities, but the important thing is to not lose sight of its context and the stories that you’re responding to.

We’re now a few months into building out this vision and continue to use many of these methods in our daily product development. We’re constantly looking to evolve and improve our product process so please leave comments and questions!