Tag Archives: alan cooper

Flashback: A Year Ago This Week on Tyner Blain [2006-03-10]

car mirror

Top Ten Tips for Preventing Innovation

Locked Door

At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.

What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.

Interaction Design, Explained By Alan Cooper

Harry Hamlin and Medusa

There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.

Prioritizing Software Requirements Across Releases

popcycle sticks

When prioritizing requirements for the first release of our software, we’ve stressed the importance of including 100% of the ‘must have’ requirements in the first release of the software. We’ve also used Kano analysis to categorize requirements as ‘must be’, ’surprise and delight’, and ‘more is better’ requirements. In this post we’ll talk about an approach to allocating these requirements across releases.

Customer Service and Software Development

customer service

Sometimes we forget that people use our software. Neil Mix reminds us that we should treat our users like people. For anyone who’s worked retail or food service jobs (like yours truly), we shoud treat our customers like customers.

Neil provides a compelling hypothetical situation to put the issue in context:

Consider the following scenario: You go to a bank to open a checking account. In a rush to fill out the necessary forms (you’re busy, after all), you accidentally write your address in the “company” line. Upon handing over your forms, the bank employee firmly says, “Invalid company name.” And then the forms are shuffled back to you.

Wherein The Computer Says, “You Are Invalid”

In this example, we see jargon creeping into the interface, and we see poor customer service. And we have all seen this online. Why? Probably, as Alan Cooper points out, because developers are homo-logicus not homo-sapiens – so this doesn’t even show up on their radar.

Neil builds on this example, focusing on error messaging as something that doesn’t get a lot of strategic focus, yet still represents a key interaction touch-point for the users. We don’t want our product managers writing error messages for us, any more than we want them to be spell-checking a release.

It can be challenging to prioritize improving an error message to speak in humanese, when understaffed teams are scrambling to get functionality out the door. A better approach is to instill a sense of customer service throughout the development process, and expect the team to get it right the first time.

It takes the same amount of time to program “Oops, I lost your network connection, but I have a saved backup right here, do you want to restore it?” as it does to program “Network Error! TCPIP fault, unexpected connection closed.”

Product Managers Play Tug-of-War

tug of war

63% of product managers report to marketing and 24% report to development. 22% of requirements managers report to marketing with 55% in the development organization. These reporting structures can over-emphasize the needs of new users and super-users, while shortchanging the needs of the majority of users. Product managers will constantly be playing tug-of-war to get time to do the right thing.

The Softletter Survey

Softletter executed a survey earlier this year, which found that almost two thirds of product managers report to marketing, and a majority of requirements managers report to development. Detailed survey results are available by Subscription.


The Silicon Valley Product Group recently published an article about this very issue. They point out significant problems with both reporting structures. Hat tip to Nils for finding this one. Nilsnet is on our blogroll and makes good reading – you should check it out.

Product management in the marketing group:

Further, what usually happens is that the product marketing role and the product management role get combined. These roles and the skills required so different that what usually ends up happening is that one or the other (or both) gets poorly executed.

Product management in the development group:

Moreover, it’s easy for the product management team to be consumed in the details and pressures of producing the detailed specs rather than looking at the market opportunity and charting a winning product strategy and roadmap.

Alan Cooper’s Take

In The Inmates Are Running The Asylum, Cooper points out that marketing people tend to over-emphasize the needs of new users. Their interactions are primarily with people who we want to buy the software. As such, they spend most of their time understanding the needs of people who haven’t used the software, or who have just started using the software.

Developers, or as Cooper calls them, homo-logicus, are a special breed of people who are much more capable of dealing with complexity than average users. They appreciate good algorithms, customizability, and full-featuredness. They don’t run into the problems that most people have when dealing with software that has too many features.

Johanna Rothman asked the question in April, “Do engineers use their own software?” Her point was simply that if engineers have to “eat their own dog food” they will introduce fewer bugs. There are definitely benefits to this mindset. However, the engineers should not be specifying the features for the products (unless the products are to be used only by other engineers).

Competent Users

Our priorities as product managers should focus on competent users. Most people develop a level of competence quickly and most people stop learning when there is no additional benefit to learning more. Therefore most people don’t become experts. With a lion’s share of our users being competent, we need to make sure we emphasize them in our requirements and design decisions.

Organizational Bias

As SVPG points out, product managers will tend to evolve into the activities most valued in their organizations. Combine this with Cooper’s take on the needs of the everyman, and we end up having to devote energy to overcoming organizational bias in order to prioritize the needs of the majority of users.


Product Management should be represented in its own organization. This allows a focus on the right users, and will likely make it easier to avoid tactical tangents that take away time from strategic decision making.

The Agile Dragon

When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.

Irrelevance of Change

The interesting thing isn’t that Agile teams need changes in the requirements to succeed. The process is relatively immune to change. By waiting until the last responsible moment to elicit requirements, we don’t care how much those requirements change prior to getting them.

Relevance of Change

There’s a chink in Agile’s armor. Imagine we are half-way through a project, using an Agile process.

  • We know that requirements change.
  • We are about to gather requirements for the next iteration.
  • We waited to gather these requirements, because the requirements didn’t exist until the customer saw the last release.

If change happens, and we’ve finished half of the application, it stands to reason that half of the changes will be to stuff we’ve already built.

When 90% of the application is complete, won’t 90% of the changes be to stuff we’ve already done (and now have to do again)?

No Worse Than a Waterfall

Sure, with a waterfall model , 100% of the changes will be to stuff we’ve already built, because we (think we) finish it before we deliver it. With an Agile process, roughly half of the changes should be to functionality we’ve already delivered. This assumes a constant rate of output by the development team.

Good Requirements Matter

I don’t accept the premise that the customer doesn’t know what they want. Customers know what they want – higher profits, greater market share, etc. What customers don’t know is what software they want. With the right requirements, and the resulting implementation, they don’t care. Or at least, they shouldn’t care. Documenting these requirements is very hard. Most people can’t do it well. That doesn’t mean that the job can’t be done. Most people can’t run a four minute mile, or transpose music up a step when sightreading. Doesn’t mean it can’t be done.

Cooper believes that the interaction design process is the ideal one for writing software requirements. He may be right, the jury is still out. There are only two statements that we can make about the “best” software development process.

  1. The best process includes elements of each of the processes that currently claims to be best.
  2. The best process for project A (or team A, or company A) is not the best process for project B.


Without proclaiming what the best process is, we know that some things are very powerfull:

The “best” process is going to combine those strengths, whatever its called.

Gartner research on Agile Requirements Definition and Management (RDM)


Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.

Here’s the excerpt from their website (AD = application development):

The flexibility with which requirements are gathered and managed shows how disciplined an AD process is. AD organizations with automated requirements definition and management environments will better support change control, gain testing efficiencies and reduce future maintenance burdens.

Gartner Predictions

  • The cost of quality for developed systems will drop by 30%
  • Maintenance costs will drop by 10%
  • User satisfaction will go up from ‘fair’ to ‘good’ for medium and large applications

RDM systems have a meager impact on these predictions – other trends and processes are just as likely to affect them, hence our low rating of the Gartner report. Read on to see where they err.

Reduced cost of quality (RDM score 2/3)

Better requirements lead to fewer bugs. In Where bugs come from, we talk about the introduction of bugs from different sources in the process. The area where RDM can help is with misinterpretation of requirements. A structured system makes it easier to validate the alignment of proposed designs with requirements. RDM score = 1/1.

Incremental delivery processes will likely have a greater impact on cost of quality, as they help us correct mistakes in requirements documentation. This source of bugs (doing the wrong thing right) is higher up in the process, and thus has a larger impact on the bottom line. Gartner touches on this trend as well, but does not try to tease out the potential benefits and isolate them from the “benefits of RDM” analysis they present. RDM score = 0/1.

Traceability in RDM tools can provide large benefits in the cost of quality. To achieve these savings, RDM users must trace their testing to the requirements. This traceability helps uncover gaps in test coverage of the requirements, resulting in fewer bugs released to the field. RDM score 1/1.

Maintenance costs will drop (RDM score 1.5/3)

There are three trends that can drive lower maintenance costs for software. RDM can reasonably play a role in 1.5 of the 3.

  1. Improved design and implementation. RDM doesn’t make design better. Incremental construction creates opportunities for refactoring the code. RDM score = 0/1.
  2. Fewer gratuitous features. Most software today has too many features. Optimizing the features for a product will reduce the size of the code, and therefore reduce costs. RDM provides traceability of features to top level objectives (ROI), making it easier to identify and descope marginal features. RDM score = 0.5/1.
  3. Cheaper labor. Outsourcing can reduce the cost of development labor, but not as much as you might think. Joel Spolsky shows us that 80% of the costs aren’t programmers, so the upper bound on savings is small. Tarun Upadhyay provides some real world data showing that the total cost savings can be between 8% and 38% when replacing 70% of US developers with Indian developers. The extra savings comes from moving some of the abstraction layer (supporting roles and overhead costs) to India as well. RDM makes this possible by providing a means for rigorous asynchronous communication between team members operating in different time zones. RDM score = 1

User satisfaction will rise (RDM score 0/1)

User satisfaction is ultimately increased when software is focused on user task-accomplishment, or goal-achievement. Process approaches like Alan Cooper’s interaction design process make this more likely to happen. Existing RDM products use a structured-requirements representation, most aligned with Karl Wiegers’ framework. With Wiegers, the main tool for capturing user tasks is the formal use case.

While it is possible to combine interaction design and structured requirements processes, none of the current RDM products do this. Our prediction – none of them will make this change in time to impact Gartner’s predictions. As interaction design gains momentum in the product management space, customer satisfaction will definitely go up. But it will be in spite of RDM systems, not because of them. RDM score = 0

Conclusion (RDM score 3.5/7)

The optimism about improved economics of software development and improved levels of user satisfaction is heartening. Unfortunately, Gartner has tied too much of this optimism to the proliferation of RDM systems (they also forecast strong growth in sales of RDM systems). We pointed out that requirements management software will not solve the problems with bad processes.

We are excited to see Gartner focus on RDM and on RAD processes. Executives are very swayed by Gartner opinions. If RDM retools to support interaction design, it could indeed live up to these predictions.

Competent Users and Software Requirements

student driver

We were all student drivers at one point. But no one stays a beginner indefinitely.

expert driver

Almost no one becomes an expert driver either.

normal traffic

Most of us are competent drivers. Driving skill probably even follows a bell curve distribution, with most drivers being OK, some “bad”, some “good”, and very few experts or beginners. We’ll show in this post how to apply this pattern to software requirements and design.

Most users are competent users

When we’re designing software we need to keep in mind that most of our users will be competent – neither experts nor beginners. Alan Cooper’s studies tell us that user skill levels follow a bell curve. He talks about competent users as perpetual intermediates. Some users drop out of the bell curve when they stop using our software. The rare user becomes an expert. Most users only learn enough to get their real job done.

Most requirements are written for beginners and experts

On most teams, the bulk of the requirements are written for either beginner users or expert users. This is because marketing and engineering groups can have an overweighted influence on requirements prioritization. There are good reasons to design features for both of these groups of users, but if the bulk of our users are competent, shouldn’t we prioritize the bulk of our requirements to optimize on those users?

The case for beginners

There are two good reasons to optimize on beginner users. Software that is never used frequently (like TurboTax on the web) will always have beginner users. This post doesn’t apply to those applications. Ignoring the beginners will kill us too. If users are unable to learn quickly enough to get past the suck threshold, they will never become competent with our software, they will switch to another application.

The case for experts

As differentiated features are added we increase the likelihood that all users will use our software. Many applications attempt to differentiate by doing more. When our differentiated features represent more instead of better, we end up creating a more cluttered application. Eventually we reach the point that only experts can use our system. And experts may demand these additional features.

The not-so-good reasons for both

Cooper makes an interesting assertion in The Inmates are Running the Asylum, that marketing folks overwhelmingly represent beginner users, due to their primary interactions with people who haven’t bought the software yet. Marketing people are paid to think like non-users (non-owners, technically), to help convert these potential customers into customers. Cooper also points out that engineering teams push for (or fail to push back on) expert-style features. Our technical people are software experts – they understand how software works, and are not confused by how it might appear to work. They lack the genetic resistance that normal humans have to overly complex interfaces. It may not even be concious.

When we combine legitimate reasons for beginner-user features and expert-user features with over-promotion of those features by influential team members, we end up with undersupported competent users.

How to bring balance to our requirements

We use goal-driven development, and more precisely, well-designed personas to drive our prioritization decisions. We make sure that our personas represent all of our different users, and that the primary persona is a competent user. We validate that our highest priority requirements support of this competent user.

Interaction Design and Structured Requirements

Star Trek Borg Queen

subtitle: Wiegers and Cooper assimilated

Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at different parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.


Regular readers can brush up on the following posts. Folks who are new to Tyner Blain (welcome aboard!) can get the immersion treatment to understand our perspective on requirements, design, and product management / development process by reviewing the following posts.


Our combination of interaction design and structured requirements principals makes it even more difficult to differentiate between “requirements” and “design.” We’re ok with this, because the distinctions are purely semantic, and distract us from our goals – developing great software. The combination we promote is to replace use cases (from Wieger’s structured requirements approach) with scenarios. This replacement adds interaction-design elements into the process of goal-definition. It is also worth noting that it splits the nebulous design activity into two activities – program design and interaction design.

First we will review the Wiegers structure, then a modified structure incorporating the interaction design elements.


This approach provides us with the organizational benefits of a structured approach, while incorporating the techniques of interaction design that can lead to great software by driving proper prioritization decisions. The decision process is key to choosing to build the most important stuff, and more importantly, not build the unimportant stuff. Avoiding the less valuable features improves the product for the most valuable users. Wiegers’ approach doesn’t prevent this from happening, nor does it encourage it. Our approach will encourage it.

Wiegers’ structured requirements

Structured requirements diagram

The structured requirements approach starts with the goals, expressed in a product requirements document (PRD). There is a step that happens before the Wiegers process. Market requirements are identified before this first step, and captured in a market requirements document (MRD). This MRD is converted to a PRD, as requirements are identified as being in-scope or out-of-scope for the software. Wiegers doesn’t address this preliminary step (but Cooper does).

Once we have our PRD goals, we define the use cases to support them. Then we write functional requirements to support the use cases. The functional requirements are augmented with non-functional requirements and must comply with constraints.

The design and implementation phases follow this process, and again are unaddressed by Wiegers.

Adding interaction design to the mix

interaction design in the process

In the diagram above, the changes (relative to the Wiegers process) are marked in blue.

The interaction design process starts with two parallel activities. On the left is the identification of corporate goals, which is analogous to the creation of an MRD. An MRD can be a reasonable mechanism for documenting the corporate goals. It provides more detail than “Increase profits” with statements like “Increase profits with improved pricing.” On the right side is the creation of personas to represent the most important users.

The persona creation process involves identifying the practical and personal goals of the representative individual. The personal goals are used later when designing the user interface. The practical goals are integral to the requirements process. The practical goals represent the role that the persona plays in achieving the corporate goals. A practical goal for a pricing analyst might be “Increase profits for product line X by 10%.”

The practical goals are an analog to the Wiegers goals – they represent the software-relevant goals of the company, in actionable language, associated with a particular persona (class of users). The association with the persona is the key element that allows for great design. The actionable nature of the goals may incorporate or imply particular business process design decisions (made outside of the scope of either process).

The main benefit we get from this approach is the ability to not implement the non-essential features. The absence of these fluff-features allows the most important users to master the software faster without having to deal with low-value complexity.

The scenarios are effectively the same as informal use cases. The distinction may be that Cooper stresses that it is more important for a scenario to run end-to-end than it is to be deep with precision or detail. A use case is normally scoped to a subset of the overall process, where a scenario may cover behaviors that would map to multiple use cases.

Functional requirements, non-functional requirements, and constraints are all defined in support of the scenarios – with the same approach as in the Wiegers model.

The design step is distinguished as having two clear elements in our combined process. Cooper separates program design (what users don’t see) from interaction design (what users do see). This makes sense for two reasons. First – the personal goals of the persona influence how the user will interact with the software. These goals will only indirectly influence the program design decisions. Second – these two tasks require different areas of expertise and should probably be covered by different individuals. The program designer is our canonical developer. The interaction designer is an expert in psychology as well as the other user experience disciplines.

Interaction Design Process Overview

middle manager using computer

Interaction design creates a focus on (some of) the users

Interaction design, as described by Alan Cooper in The Inmates are Running the Asylum, is a process for designing software by focusing on the most important users. Unlike traditional requirements gathering and solution design processes, interaction design focuses on the goals of a specific class of users, represented as a persona. Those goals are considered when defining scenarios that represent how the primary persona will use the software. The combination of goals and scenarios leads to design artifacts and a functional specification. We will explore these steps in more detail in this post.

Continue reading Interaction Design Process Overview

Software design and specification and making movies

movie reel

Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. [This is a fantastic book for getting an understanding of exactly how Cooper’s perspective evolved over the last decade.] Cooper is presenting the analogy in the context of validating the business case for investing in interaction design.

Cooper points out that they’ve been making movies for a lot longer than we’ve been making software, and he’s exactly right that there is something to learn from the film industry.

How the movie industry works

The movie industry manages movies in three phases:

  • Pre-production. Determining what the movie will be about, raising funds, storyboarding and designing the movie, getting actors signed, writing the script, etc.
  • Production. Shooting the film. Directors, actors, and crew all working very expensively to get the film shot.
  • Post-production. Tweaking and finalizing the film.

How software development parallels movie making

Software development involves three phases as well: Decide what to do, do it, and deliver it.

The interesting thing to note is that the film industry universally invests time upfront in pre-production, to minimize the costs of production. They recognize that production is more expensive than pre or post-production. Many software teams take the same approach, although Agile development explicitly does not. We gleaned some insight into Cooper’s perspective from our coverage of a debate between Cooper and Kent Beck.

If we accept Cooper’s premise that production is more expensive than pre-production, then software should follow the same model.

It’s worth noting that an agile process results in more design, not less. Beck might argue that redesigning as we go is less expensive, because we improve our ability to understand what we actually want to create during the process of creating it. Cooper disagrees.

As much as we like Cooper’s insights, the movie cost structure is not paralleled in the software development structure. When we hire developers, it is analogous to the old movie studios keeping actors on retainer – the cost is “fixed.” And the infrastructure costs of production (set creation, for example) are not affected by the time spent in production – they too are fixed. If we have a project with contractor developers, then we have a variable cost, and we lose money while those developers are “sitting around.” However, today’s projects leverage outsourced overseas contractors more and more – and these actors are a lot cheaper than script writers.

What we know in spite of the analogy’s flaws

We absolutely save time and money by defining requirements before we write the software. We also know that it is important to design before we code.

Neither of these statements conflicts with agile philosophies, if we take the approach of treating “design everything” with “design this one thing” similarly. An agile approach will simply have multiple design/implement cycles, each focused on a subset of the software (and allowing for a redesign phase prior to delivery).