Back in the dark ages -- okay, the 1990s -- Alan Cooper published two books that forever changed the way people approached product design. In About Face: The Essentials of User Interface Design, (1995) he articulated a taxonomy of design that urged programmers to think about the user in a brand-new way. Then, in 1998, in The Inmates Are Running the Asylum, he outlined his concept of Goal Driven Design (GDD), which acknowledged the importance of the end user in a way that no other methodology had ever done before. As his protegee Kim Goodwin summarizes it, the methodology seeks to “identify the goals and behaviors of users and directly translate them into the design.”

Placing the user front and center was a pioneering concept, and a decided step in the right direction in the world of product design. But, like all pioneering concepts, the work must be refined over time in order to stay current and evolve. And while Cooper’s user-centered methodology is laudable for its forward-thinking, in practice it misses the mark in a few key areas and fails to reliably create adoption-focused products.

Let’s break down some of the underlying issues with the GDD approach.

User Interviews & Personas

Cooper was absolutely correct in his belief in focusing on the goals of users when designing products. But in practice, GDD isn't likely to improve customer adoption as much as you would expect. That's because GDD is focused on — in Cooper's words — a user's attitudes, aptitudes and aspirations. 

Divining a common set of attitudes, aptitudes, and aspirations involves conducting extensive ethnographic user interviews which are then used to describe typical users through carefully written personas, which are then used to tell stories (scenarios) which imagine how users might interact with a product. The problem is, none of these methods, in practice, actually address underlying user needs.

  • User interviews, as they’re generally practiced in the GDD methodology , fall into the trap of asking users what they want in terms of solutions to their problems. The trouble is, users can’t be expected to articulate true product innovations -- that's your job. Users do, however, know what they need and what job they’re trying to accomplish. But without a consistent language (explored in the next section) to ask about and communicate these needs, interviews will lead you down the garden path. These interviews also gather extensive ethnographic data that help create a model called a persona.
  • In GDD, personas are important because they purport to describe a “typical” user for whom the product should be designed. But the truth is, there is no typical user. And it wouldn’t really matter if there were. The desirability of your product should come down to the need it’s going to fulfill, not the demographic profile of your average user. Look at it this way: If you’re creating a product to help people quickly and easily do their taxes, does it really matter if they’re a middle aged suburbanite who likes lattes, or a recent college grad with a yoga habit? Or, do you think you could serve both personas equally as well? If the product fills a need(s) better than any other product then it will be desirable to anyone — young, old, urban, suburban, etc — who wants to hire your product to do that job. No personas necessary.

So, user interviews are gathering questionable data about “what users want” in a product. And, personas take the data from observing throngs of customers and provide a product team with amalgamated demographic and psychographic profile(s) that they can all reference. It is a laudable goal to seek to provide a common reference point, something for the team to all look at and think, “wow, this is who uses this product.” However, creating a common reference point that details the characteristics of a persona does nothing to lay the groundwork to discuss customer needs. Instead, personas are often used as puppets in an ideas-first brainstorming and whiteboarding performance that leaves stakeholders unsure of what to do next.

Ideas-First, Rather Than Needs-First, Innovation

GDD isn’t alone in its adherence to an ideas-first approach -- brainstorming and whiteboarding form the backbone of a number of schools of thought. But a big problem with ideas-first innovation is that it begins in a vacuum that’s divorced from the needs of the users. It isn’t really about desirability at all. Sure, it’s fun! But it isn’t effective -- In the Harvard Business Review, Rivia co-founder Tom Agan shared the results of a 2014 consumer products study which found that “Firms that hold ideation sessions … generate little additional revenue from new offerings compared to those that don’t.”

And whiteboarding those brainstormed ideas only perpetuates the illusion that you’ve come up with a winning product idea. You can’t know from a drawing, no matter how detailed that drawing is, if the idea is viable or feasible, much less desirable. The problems inherent in brainstorming -- ideas first innovating that doesn’t connect with the needs of your customers -- are still present. When you commit them to paper, they just feel more real. We’ve discussed the problems inherent in brainstorming and whiteboarding in more detail here.

Misplaced Priorities

In “Alan Cooper and the Goal Directed Design Process,” an article published in the Gain AIGA Journal of Design for the Network Economy, the author explains that “Underlying Cooper’s approach to design is the premise that products must balance business and engineering concerns with user concerns.” That’s another way of saying that desirability must be balanced with viability and feasibility from the very start.

A subtle and dangerous flaw in this process only becomes apparent if you've participated in the Scope stage, the very first step of the GDD methodology. In this critical stage, managers begin by brainstorming ideas and documenting the constraints and goals of a project. Each of the brainstormed ideas are discussed among management — typically in a conference room with a whiteboard. Managers then provide their thoughts on the viability and feasibility of each idea.

This is where things can go horribly awry.

Viability and feasibility are factors in the success of any technology project. But in today’s market, strong desirability is the number-one predictor of widespread adoption. And to understand what will be desirable to users, you must begin by addressing what they need. Viability and feasibility should never come into the picture until after user needs have been ascertained. But wait — executive-level management has been trained to be the black-belts of viability and feasibility. In fact, they are often rewarded based on incrementally improving viability and feasibility — in other words, cutting costs, improving margins, and streamlining production. 

However, Cooper gives these same managers the responsibility of shepherding the Scope stage of a GDD-driven project. And, when confronted with this challenge, they rely on their years of training and experience as masters of viability and feasibility. Desirability is often an afterthought. By relying on managers to set the scope up front, they end up with a scope that discusses user needs as a kind of second-class citizen.

There’s no doubt that product teams owe Cooper a huge debt. He pointed design in the right direction when he realized the user needed to play a larger part in the process. But his views need refinement to become up to date. Desirability is the number one factor driving adoption -- and everything must serve that end. And more specifically than the user, the needs of the user need to be the true focus. That’s how to create the most important quality for product adoption -- desirability.

And that’s where Adoption Driven Design comes into the picture. (You didn’t think we were going to leave you hanging without a refined approach, did you?)

Adoption Driven Design

Rather than practicing ideas-first innovation, Adoption Driven Design begins at the root of desirability: user needs. This means sussing out what people are trying to accomplish and why, and using a common language to discover and communicate these needs.

Ultimately, creating adoption-focused products well and truly begins by understanding the job that users would hire your product to do. It’s a deceptively simple shift in perspective, but it’s a profound one. In the famous words of Harvard Business School professor Theodore Leavitt, “People don’t want to buy a quarter inch drill, they want a quarter inch hole.” That means if you’re in the business of making drills, don’t imagine how to make the prettiest or fanciest drill. Don’t imagine the kind of person who would want your drill. Instead dig deep and discover how you could help people make that quarter inch hole -- for anyone who needs to make one -- better than anything else out there.

And to be adoption-focused in practice, your design MUST do one primary thing: remove friction and facilitate the progress people are trying to make to accomplish they job they hired your product to do.

We've identified four main steps to accomplish this and drive adoption and engagement

Step One: Identify the Job (and sub jobs)

It’s all well and good to understand that it all begins with the job your users would hire your product to do, but how can you identify that job, along with the sub jobs users need to accomplish? There are a number of ways to discover this crucial information.

  • Job Desirability Mapping: We’ve discussed this process in detail here. Simply put, rather mapping out (often imaginary) user stories and scenarios, a Job Desirability Map helps you visualize the actual obstacles users currently face, and identify the ways you can remove those obstacles and provide value. This map will help you come to an understanding of the way your customers will measure success when using your product, and the ways you can provide value and motivation for them to become avid users of your product
  • Stakeholder interviews: Unlike in GDD, where stakeholder interviews explore what the involved parties think or imagine will be the expectations and desires of the user (as well as viability and feasibility constraints), adoption-focused stakeholder interviews center around the job your product will do for your customers. In our stakeholder interviews, we gather as much information as we can about the purpose of the product, its potential value to customers, and the struggles and obstacles that users may face as they seek to make progress in the job they’re trying to do. We go into more detail about these interviews here.
  • SLOW Interviews: Unlike typical user interviews, which aim to gather a laundry list of wants and irrelevant ethnographic data, the SLOW interview digs deep and focuses on what really matters: your users’ motivations, needs, and the job they are trying to accomplish. In these interviews, we draw out details from users about the job they’re trying to do, learn how they try to do that job now, the struggles they face, and the obstacles they wish could be removed as they try to make progress. We talk about SLOW interviews in more detail here.
Step Two: Identify the steps necessary for success

Once you understand the job, next on the agenda is understanding how your users define success. That’s important: These moments must be user defined. You can’t define them yourself. We call these critical moments “progress markers.” And once again, the S.L.O.W interviews plays a key part in digging deep and uncovering these user-defined successes.

Simply put, a progress marker is a description of when and why a user feels like they were able to get something done successfully in your product. It clarifies the purpose of their actions. It shows you what they care about. And in doing so, it helps you truly see which aspects of your product your users find valuable. Think of progress markers as tiny “yay” or “aha” moments -- in a word, successes -- that must be written down in the the mother-tongue of the user’s own language. And, for your own sanity, they should probably include a description of the user’s motivation and desired outcome. We explain how to implement progress markers in more detail here.

Step Three: Align design around adoption

Your design should always facilitate the progress your users are trying to make. The goal here is to accelerate the rate of progress between “yay” moments in order to drive adoption and avid use. Put what you’ve learned in steps one and two into practice through design with the strategic use of elements such as triggers and microcopy. In general, effective triggers should:

  • Trigger the action: This could be via emails, notifications, or in-app reminders.
  • Make it easier: A hot trigger (one which allows the user to take immediate action) makes it easy for users to immediately perform the action you’d like them to perform in order to make progress. It should also clearly convey the action you’re asking them to perform.
  • Provide Feedback: Feedback (clean and clear microcopy is your best friend here!) can help clarify confusion or uncertainty, alleviate worries or concerns, and reinforce value
  • Celebrate progress: Celebrating users’ successes can keep motivation high and propel them through their “yay” moments

We’ve discussed these techniques and how to implement and measure them in more detail here.

Step Four: Boost and sustain intrinsic motivation

Motivated users are generally the most open to techniques that will push them towards engagement and avid use. And intrinsic motivation -- an internal drive and desire for accomplishment -- is more effective and sustainable than extrinsic motivation, which only focuses on external rewards that will eventually lose their novelty.

Rewards that boost and sustain intrinsic motivation must be tied to the progress users are making in achieving their goals. And there are effective ways to do this through design:

  • Increase the user’s sense of mastery by showing them the skills they’ve gained and progress they’ve made as a result of using your product (You’ve increased your speed at X task by 52% in the last two weeks. Great job!”)
  • Help create a strong sense of identity that’s tied to your product. Reinforce their new positive, get-it-done work persona that your product has helped them achieve (“Thanks to your hard work accomplishing X, Y, and Z, you’ve become a ninja-level sales rep!”)
  • Show them the value of the future benefits they will enjoy as they increase mastery

These techniques help create a loop that continually drives the user’s rate of progress, intrinsic motivation, and engagement. We discuss how to boost and sustain intrinsic motivation in more detail here.

When it comes to his forward-thinking emphasis on the user's place in product design, we bow down to Alan Cooper. But in order to cure Adoption Deficit Disorder and stay relevant in today's competitive landscape, GDD must be refined with a needs-first approach and a focus on desirability.