The Final Story

We’re at home with Jack, a 19-year-old musician. He’s recently decided to turn “professional,” in that he streams live and recorded footage of himself on YouTube with the aim of building an audience and—if he does well—earning an income from it.

As we watch him film a video for later, he lets out a pretty aggressive cough mid-song. We ask him if he’s planning to edit out the cough from the footage, and he says, “No, I don’t know how to remove stuff like coughs. But it’s fine, there’s no problem.”

Later, as we review our research material from Jack and other DIY-ers we’ve visited, we reflect on what we know about the music publishing and streaming market as a whole. It’s clear to us that it’s a show, and that if musicians want to be successful they need to pay attention to the details of how they come across. The pros making all of the money have high quality equipment and spend time on post-processing. Listeners expect them to be good at music— that’s a basic requirement. It’s the other things, such as production quality and the personality of the musician, that bring the footage to life. This can be a frustrating surprise for new musicians who are looking to build a personal brand and grow an audience. When people visit their feeds only to leave soon after, they often wonder why, and it’s only when they’ve become more experienced that they realize how much the “non-music” elements matter.

From this we had the insight that music streaming or recording isn’t about music, it’s about branding. And that our client, a microphone manufacturer in this case, could help streamers by providing top-tier production tools to make them sound good without needing to have any technical know-how. This led to the idea of building a cough detector into the mic software, which would automatically remove a cough from a recording without the speaker having to do anything. We didn’t try to change streamers’ behavior or suggest that our client could teach them how to use a cough removal tool, we simply recognized a latent need that musicians like Jack didn’t even know they had.

If you remember the story of the students who felt anxious about choosing their majors and opted for the wrong ones, you can see the parallels with how we interpret the stories we’ve generated. We come up with an insight statement about the participants’ needs, and then a subsequent “therefore we should” statement about how we could meet those needs. Whenever we do this, for whichever project we’re working on, what we really do is create a framework for imagining new ideas and determining if they’re good enough.

We call this “subjective objectivity.” The boundaries we set around what we should make are subjective because they’re based on our insights, but within them are the objective criteria created by the research. In other words, the insight about what the underlying need is and how it can be met is by necessity somewhat subjective, even if it’s based on what we’ve seen people do and our information about our client’s market. But the criteria by which we judge whether our ideas will work are objective, in that they’re rooted in the participants’ experiences. Is it important for music streamers to present themselves professionally on YouTube? In our view it is, although that’s our subjective judgment based on what we’ve seen in our research and what we know of the market. And, given that, would Jack find an automatic cough removal capability helpful in his quest for YouTube domination? Objectively, he would.

To us, the cough removal facility is a capability. It’s a bit like a feature, but we try to stay away from that word because it can imply that it’s mutually exclusive with other features, and that users can pick and choose which feature to access. For instance, going back to the students picking their majors, our assertion was that we should create a new system that registered them for classes in a way that minimized their anxiety and showed them that their decision-making wasn’t permanent. But this was too broad to be one feature—it was actually a series of interlocking capabilities that helped students to understand the pros and cons of choosing particular classes, in terms of whether they’d be able to change their minds later if they wanted to. As an example, one of these capabilities was to provide an option which encouraged students to pick some of their general education classes before their major-specific classes, so that they weren’t locking themselves into their majors too early on.

Of course, this capability wouldn’t be enough on its own for college students to abandon the process they were already using, or for an academic institution to throw out their current system and switch to a new one. There had to be a stew of ingredients in the design strategy that made up enough capabilities for a proper value proposition. Once we worked out how they interconnected, it was if the capabilities made up a larger storyline—one that described the new journey the students would embark on as they used the revised process.

Hero flows

After we’ve established five or six insights and “therefore we should” statements, our next step is to do two things: create hero flows that describe how we envisage people using the new product, and road maps of how the flows can be made into reality.

A hero flow is a sequence of steps that a customer or user takes in order to accomplish their primary goal. We start by identifying the goal, which in our example would be: “I need to declare a major in order to gain the degree I want.” Major selection is therefore the goal activity. In reality there may be more than one goal for a flow, because the academic institutions who buy the software for the students to use won’t necessarily have the same goal as the students themselves. For instance, they might want to move the students through the process as quickly as possible, without worrying too much about the anxiety aspect. That would be fine if it was something that had come up in the research, for instance if Gina the counselor had identified that she wanted students to choose their options more quickly. But if it didn’t, we wouldn’t include it. We always stay true to the original stories.

Now we have a goal, but how will our students reach it? There could be a number of steps. They might come onto the online platform for selecting their classes and see a series of choices. They pick a choice, and then see a helpful message which advises them that they’re excluding themselves from certain other choices if they choose that one. There’s also a recommendation of a different route that they could take. So they select that route, and see another set of options. And so on. We write this as a story, which might start something like this: “Jim is a sophomore at the University of Texas. The day comes when he has to register for classes. Jim opens the online portal and logs on … “

This linear hero flow is deliberately optimistic—it paints a beautiful picture of how everything will be great when people follow it. We make it like this because we’re trying to create a vision that everyone can get behind. The idea is that our participants’ stories, combined with our ideal solutions, will create a groundswell of enthusiasm in our clients. It’s only with this positivity behind them that they’ll feel enthused to take the product to the next stage.

A great deal of any debate that’s sparked by the hero flow is about what’s the right thing to build. We have the data (the stories) to support what’s right for the customers and users, and our clients have the data about what’s right for the market and their business. In a perfect world there’s a considerable amount of overlap, but even if there isn’t, there’s usually a sweet spot somewhere in the middle. Finding this can take a lot of talking, and drawing. We can lead our clients so far, but ultimately it’s their decision and our role is to help them to reach one that they feel comfortable with (as long as it’s within the boundaries of the objective subjectivity that we mentioned earlier).

In reality, within the five or six journeys that our hero is traveling along, there may be a cast of other characters involved. For instance, the system for picking majors might coordinate a referral to a student counselor like Gina, and after she’s done the work she needs to do, it reverts to the student. Any time a person other than the hero plays a role, we highlight it. A good example of this is when we design products for heavily regulated industries such as insurance. We might include a hand-off to the company’s underwriters, which signs off that part of the process, and then returns the flow to the user, because we recognize that step is non-negotiable (even if undesirable).

Our hero flow is different from the traditional process flows created by software developers in that it’s based on stories, not requirement lists. Developers often write use cases, such as “Jim clicks the button labeled ‘Register’. After that, the screen displays the following items … “ These are devoid of the nuances of humanity. Of course, we’ll need these kinds of functional processes to be set out later, but for now we avoid boiling down human behavior into a series of bullet points. We want inspiration and optimism instead.

Wireframe testing and beyond

Our hero flow story is now written, but it’s a conceptual narrative. It needs to be made into a concrete series of steps which depict how we envisage users achieving their goals. To this end, we create a series of “wireframes.” These are black and white screens which show the software as the user will see and experience it, but they’re plain and rough. We print out the screens onto pieces of paper and show them to our research participants, saying, “You know what? This isn’t real. It’s only on paper and we haven’t even designed it to look nice yet.” We find this to be the best way of gaining feedback that takes into account people’s natural reluctance to upset the status quo; if they know that the work is just a draft, they feel OK about criticizing it or making suggestions for changes.

By having trial users go through the process of “using” the software, we gain insights into what they think about it. We do this by showing the participants the pieces of paper, with one of us acting as a manual computer. “Here’s your activity,” we say. “How would you start?” They might reply, “Well, I’m going to click on that.” And we say, “OK. Pretending that you clicked on that, here’s the screen you would see.” We turn over the next piece of paper and ask similar questions about it. Or we do it the other way around, so that when they click on something we tell them that if they’d pressed another button they would have seen a different screen, and we ask them to explore that. We keep things simple by not including all the flows that they could travel along, but we want to know why they picked the ones they did rather than the ones we were thinking they’d choose.

Although the wireframe has no color, iconography, or pretty pictures, it does contain the language that we envisage using in the final product. We never create screens with fake wording or “lorem ipsum” filler text. More often than not, real information on the screen is a key ingredient to understanding if a concept resonates with users. For instance, what might originally have been called the “Course entry” screen for students choosing their majors now has the following text instead: “Welcome, [User’s name]. It’s time to pick your classes.” The human elements of the vocabulary, work-flow, and hand-offs can point us to any emotional stumbling blocks that might lurk under the surface. Suppose we realize, from our field research and user testing, that students are unlikely to complete the process in one go. They feel overwhelmed and need to take a break, or maybe they become distracted by other things. We might then decide to build a “save” feature into the system so that students can come back to their application later.

It’s worth pointing out that we should always be able to track the decisions we make back to the participants’ stories. Take the example of the “save” button. If we were to introduce this, we’d ask ourselves if anything that we saw during our time with students led us to believe that they would abandon the process of choosing their major if saving it wasn’t possible. If we witnessed people like Jim feeling overwhelmed by the experience, we’d include this type of stop-and-come-back capability. This helps us to vet whether what we’re proposing is right, or whether we’ve gone off track and are designing what we want based on our own opinions.

We usually carry out two rounds of wireframe testing. It’s rare that we have to scrap what we’ve done and start over, although that does occasionally happen. Most of the time the kind of feedback we receive is along the lines of, “I didn’t understand that page. I didn’t see the words I was looking for when I clicked on that. And what I saw next was surprising.” This gives us valuable data for the next round.

Our next step is to apply a visual design to the black and white layouts. If our client has a brand language, we work it into the visuals in a way that still supports our users’ goals, and everything now starts to come to life. We’re looking at things such as the color of buttons, the placement of labels, and the words and imagery that users see. This dictates the tenor of the users’ experience—the aesthetic, emotional feeling of it.

A great example of how design can dictate how using a product feels is a popular online project management tool we use in our own business that you may recognize. It gives a visual “high five” when we complete a task by showing a rainbow unicorn flying around. Because of our experience with designing products, we know that it wasn’t included by accident. It was probably as a result of the product team thinking about feelings, not just actions. They could have decided that other features were more important, but they didn’t—they prioritized this one and assigned money and resources to building it. In the same way, when we think about how to help students feel less anxious about choosing their majors, we want to make sure that the way the system feels to a user minimizes anxiety. We achieve this partly through what we design the system to be able to do, and partly through how it looks.

Our hero flows are now aesthetically appropriate, emotionally sound visualizations of the new software. They look realistic because they resemble the finished version, and they also represent what the product should do for people. We have a vision of the future; it’s not the complete product, but it’s the hero flow through the experience. And it’s important that the visual flow stories at the end are just as persuasive as the participants’ stories at the beginning, because our clients need to believe in the proposed solutions just as much as they did in the original needs and desires of their customers.

Road-maps

Our final activity is to create a road-map. This is essentially a diagram which shows the sequence of work to be done to create the capabilities we’ve specified, and it plots a progressive pathway to more and more value. In terms of what gets developed first, we want to give our clients and users the most value as quickly as we can. Software developers often prefer to build the hardest thing first—it seems logical to them to knock out the difficult stuff before tackling the easy pieces. But sometimes the elements of a capability that are the hardest to build are the ones that users care about the least. We want to prioritize the most important ones, which means that there needs to be some give and take between the design strategy, the developers, and the client’s business.

Another way that things can change during the road-map creation is that developers identify potential pitfalls in the hero flow. We call these “whatabouts.” A developer says, “So Jim clicks on ‘explore majors’ and sees a map of the majors. But what about if we don’t have all the majors listed? What about if the system doesn’t have all the current data for that year? What about if Jim wants a list, not a map?” This is often defeatist—it’s easy for us to “whatabout” ourselves into inaction. We try to retain the optimism of the hero flow story while we react to the pragmatism of the developers’ thinking, with the result that we create something that’s both practical and transformational for users.

These roadmaps are not yet a detailed breakdown of stories and sprints. That comes later. Instead, they break a concept into key chunks of value that loosely map to a time cadence that makes sense for the client’s business or development process. We call these chunks of time “milestones.” Depending on the business, each milestone of delivery might represent a quarter, half, year, or more. The key to building a roadmap at this level is to describe specific outcomes that the user should be able to achieve at each stage. In this way, they can begin to think about how to break apart functionality into chunks that work together to support a larger goal.

The hand-off

The completion of the road-map is usually the point at which we hand over to our client for them to create the new product. However, in the grand scheme of the product coming to life, this moment is nowhere near where it ends. We know that there will be many tasks ahead before the job is done, but also that it matters how they carry them out. We encourage our clients to think about the process they’ve been through with us—learning about their customers through the research participants’ stories, and creating new product stories based on them—and to do it themselves, continually and “forever.” We hope that it will stop seeming like a set of steps and become their preferred way of doing business too.

In a way, we’re trying to change the DNA of a company, which is almost impossible to do quickly. If the business has been around for a long time and has its own way of working, we’ll be pushing a rock vertically uphill if we instantly expect it to be more like our own. Some companies manage to transition out of their culture, but most are stuck with what they have. Take the example of General Electric under the leadership of Jeff Immelt. His aim was to turn GE from a manufacturer of heavy industry products to one that was also a software innovator, embracing the world of digital. So he invested billions in hiring software teams, designers, developers, and product managers. And yet there was a huge culture clash between these new people, with their agile approach, and the engineers and designers who had been working there for years. The latter were accustomed to taking 20 years to build an aircraft engine to a safe standard; it was unthinkable for them to speed it up and release it in stages as the software developers would do with their products. Despite all the money poured into the culture change, GE Digital failed, and GE ended up returning to its roots in industrial equipment.

Although we can move the Titanic only a little to the left or right, it’s still a worthwhile aim. We know this because we spend our professional lives finding ways to improve products which, early in a company’s history, were created purely to land new customers. This is short-term thinking, which is a great way to start and grow a business or product user base, but not so good for sustaining it. Over the years, the additional features add up and often lead to a Frankenstein mess which we’re later charged with tearing down and rebuilding.

A classic example is Apple’s iTunes.

The software started with a humble purpose: to help customers play digital music. Yet over time, it evolved into the centerpiece for music, video, podcasts, device syncing, purchasing, device backup, recovery, and more. This wasn’t deliberate, it just kind of happened, because the company didn’t have a plan for growth. You can imagine how, without a proper strategy, the software slowly became a shamble of complexity. It had been created with the best of intentions but at the expense of a logical, thoughtful whole. Eventually it became unusable without specialist knowledge, so the company started to embrace a modular, non-iTunes-media ecosystem. Now, individual apps, and services, like Apple Music, are the centerpiece for Apple’s media—yet iTunes still exists as a massive and complex legacy reminder.

This shows how a product with promise can grow into a bloated mass of features if there are no user stories to guide its development. However, when design strategies are based on an authentic and consistent storytelling approach, they stand an excellent chance of giving birth to products that delight the people they’re aimed at, right from the start.