The Hypothesis-Driven Design process can help your team figure out how all the pieces fit together in a complex storytelling project. (Deborah Lee/NPR)

More than ever, news organizations want to build immersive storytelling experiences for audiences, where users can interact with visuals, audio and data — sometimes all at once.

But the pace of technological change and our desire to tell stories in new and innovative ways often outstrip the capabilities of our content management systems and existing workflows. Coming up with a new storytelling approach on a complex project may involve risk and uncertainty. When working with a professionally diverse team — from reporters and editors to designers and developers — things can quickly get complicated.

And yet, it’s possible to apply a repeatable formula to make format-breaking stories. At NPR, we have used an editorial development process called Hypothesis-Driven Design (or HDD for short) on many successful projects. It is inspired by similar processes in product development, like Lean UX, that emphasize lightweight testing and prototyping to validate ideas. We’ve used aspects of HDD to create everything from live fact checks of presidential debates to a virtual reality experience in the Rocky Mountains.

This post provides an introduction to Hypothesis-Driven Design, as well as our step-by-step guide for taking projects from concept to completion. The guide, which you can view in Google Docs at n.pr/hdd or download as a PDF, is geared toward folks with experience leading digital storytelling projects and includes recommended roles and responsibilities on an HDD team as well as templates for each step to help you get started.

Applying the scientific method to storytelling

The title card of the story What Does Music Look Like? includes a headline and subhead. For the story Rain Forest Was Here (right), we hypothesized that introducing the story with a sentence would lead more users to continue through it. (Wes Lindamood/NPR)

The word “hypothesis” might conjure up images of science fair projects. If you think back to science experiments in school, you’ll remember that the purpose of a hypothesis is to offer an explanation for a phenomenon. Then you conduct an experiment to see if your explanation was right. Through testing, you prove or disprove your hypothesis.

You follow a similar process with HDD. Starting with an existing approach, you and your team form an educated guess about how you might improve the approach. Using experiments, you measure and learn from what works and what doesn’t.

In the story Rain Forest Was Here, we hypothesized that introducing the story with a sentence on the title card would provide a better understanding of what the story is about, and get more users into the flow of a story than the headline and subhead approach that we had used in the past. To test this, we tracked the “begin rate” (the number of users who continue past the title card) and compared it to other stories we’ve made that use title cards.

This focus on experimentation is something that distinguishes HDD from design approaches that only focus on layout and presentation. But arbitrary experimentation is risky. You can waste a lot of time with bad guesses and conflicting viewpoints. To increase the likelihood of success, HDD provides teams with a structure for developing an informed and shared opinion to test and learn from in quick and lightweight ways.

The versatility of Hypothesis-Driven Design

The types of stories we have published using HDD techniques have taken on many forms, but they all have required collaboration across groups with expertise in reporting, editing, design, technology, video, photography and audience engagement.

Wireframes and a mockup in the prototype stage followed by an animated sequence from the final project show the evolution of the story design for the project Stand At The Edge Of Geologic Time. (Wes Lindamood/NPR)

When working on a story about the aftermath of Ebola in Liberia, we wanted to tell the story in a direct, close-up way. Liberia had been the subject of extensive media attention during the peak of the outbreak, and public interest in the topic was waning, so we knew we needed to do something distinctive to help the story stand out. We believed the story would be more successful if the audience could hear directly from survivors in an immersive way, and we used HDD to explore approaches that supported this goal.

When working on fact checks and analysis during the 2016 Election, we wanted to improve upon how we had done fact checks in the past and create a real-time platform that would not be possible in a standard article template. We believed that by providing live annotations in the context of a full transcript we would build audience trust in our analysis, and showcase the expertise of our newsroom in an engaging way.

And when exploring the potential for 360-degree audio in virtual reality, we believed it was important to explore multiple modes of experience and make the story accessible to VR and non-VR audiences.

The Hypothesis-Driven Design process, at a glance

To give you a better feel for what’s in the HDD guide, here’s a bird’s eye view of its six stages: Research, Plan, Prototype, Develop, Launch and Review.

The arrows in the graphic below show that HDD is an iterative process and that the amount of time that you spend in each stage varies. In the prototype and development stages, it is not uncommon to go through several rounds of prototyping and testing before a project is published. The arrow after review stage shows that the goal of the final stage is to summarize what was learned to inform subsequent work (future versions of the project or related projects).

How long does the HDD process take?

Past HDD projects at NPR have ranged from two weeks to three months. While timelines will depend on the unique needs of the project, this is a common distribution of time:

• Research 10%
• Plan 10%
• Prototype 30%
• Develop 40%
• Launch 5%
• Review 5%

Research: Identify the project’s goals

From left, Team members Wes Lindamood, Kainaz Amaria, Claire O’Neill, and Alyson Hurt discuss the structure of the project Planet Money Makes A T-Shirt. HDD projects are collaborative and cross-disciplinary. Group edits, sketching session and daily face-to-face meetings are common practice for the process. (Brian Boyer)

All HDD projects start in the research stage. At this point, you have a subset of the full team involved. The goal is to define how the proposed project will support editorial goals and audience needs. You are building a “why.”

You can think of this as the story pitch stage, where a reporter comes to an editor with an idea. The editor is there to help the reporter figure out the shape of the story. If it’s a topic without a story, the editor is going to ask the reporter to go back and find a story. Like in our reporting, we want to be strategic about the digital projects we work on. Before starting a project, we should be able to clearly explain the editorial value of the project and how it will serve our audience.

Plan: Build a shared understanding of the project’s goals

HDD projects are cross-disciplinary and collaborative (typically involving 5 to 7 participants), so you need techniques for building a shared understanding of the project’s goals. That’s what the planning stage is designed to do. There are many ways to address editorial goals and audience needs. Activities in the planning stage help to get all the good ideas out on the table, and get the team on the same page.

Prototype: Sketch out an approach to use as a starting point

Team sketches from a sketching session exploring the Fence Facts section of the NPR story Borderland. To make the sketching session accessible to remote participants, the team used screen sharing via Google Hangouts to share drawings (Wes Lindamood/NPR)

With a shared understanding of the project’s goals, you are ready to enter the prototype stage. Here, the team will put potential approaches to the test in quick and lightweight ways. Through sketching and prototyping, the team will develop a tangible sense of the approach they will take.

Develop: Build, test and improve your approach

When you enter the development stage, you are ready to build a production-ready project. Often the solution you start with in the development stage looks nothing like the project you publish. But you need a starting point. The benefit of having an informed starting point is that you enter the development stage with focus and flow, instead of trying to figure out what the story is and build it at the same time.

The work of the development stage is structured around a cadence of feedback, learning and refinement. This comes from stakeholders, usability testing and a better understanding of what’s technically feasible. Work in the development stage will continue in this way until the team has determined that the story is ready to publish.

Launch: Create a publishing plan

Once the story is ready to publish, it advances to the launch stage, where the team and stakeholders will meet to discuss the internal and external launch communication plan and schedule.

Stakeholders from your audience engagement, marketing, and public relations teams — who should be monitoring the progress of the project through regular reviews in the development stage — will assist with launch planning to help the project reach the right audience at the right time.

Review: Document what you learned

The learning doesn’t stop when the project is finished. For the benefit of the organization and future projects, it is important that the team review and document what it has learned.

For projects that achieve their editorial goals and connect with audiences, the goal should be to figure out how to create a repeatable pattern. The rigor and focus on learning in a hypothesis-driven design project are geared toward this. Over time, projects that start out as experiments become established approaches, and the focus of the work shifts from discovery to improvement.

Ready to learn more? View the guide online at n.pr/hdd or download the guide and let us know what you think. Trying something similar in your newsroom? What’s worked and what hasn’t? We’d love feedback. You can find us on Twitter at @nprtraining.