Monthly Archives: March 2006

Four Application Development Outsourcing Models

The man behind the curtain

On March 30th CIO magazine published an article titled Do’s and Don’ts of Outsourcing Benchmarks. The article spurred us to write about outsourcing models for product development – it is otherwise unrelated, but interesting. [2015 Edit: The CIO article has been removed, check out these lessons from successes and failures instead]

Continue reading Four Application Development Outsourcing Models

Passing the Wrong Whitebox Tests

broken chain

We’ve talked about the value of using whitebox testing in our Software testing series post on whitebox testing. What we haven’t explored is how to make sure we are creating the right tests. We have to validate our tests against the requirements. This post shows where the flaw is in the typical whitebox testing process, and how to fix it.

A reader emailed us with the comment, “It’s been my experience that developers can’t test their own code.” Their problem was that they were missing a link in the software development chain (missing a step in the process).

Typical whitebox testing process

whitebox process

In the typical whitebox testing process, the developer receives a PRD from the product manager. There is a communication step in the process next (rectangle with two vertical bars), where the developer interprets the requirements. That interpretation leads to the design and creation of tests, as well as the design and creation of code. The tests are run against the software, and results are obtained.

The sneaky problem

The sneaky problem is in the communication step – the developer interprets the requirements document. That interpretation yields both code and tests. If the developer interprets incorrectly, then he will design the wrong whitebox tests. Ultimately, he will deliver software that does the wrong thing very well.

The solution

The number one way to be a better listener is active listening. Listening is the Family Feud #1 answer to “Name a form of communication”. We can, should, and must use the same technique when interpreting requirements documents. We can modify the process to include validation (active listening) of our interpretation of the requirements.

better whitebox testing process

The steps that don’t change in this modified whitebox testing process have been greyed out.

Process changes

  • Split the “Design and create tests” process step into two steps – “Design tests” and “Create tests”
  • Insert a test-design validation step into the process.

The test design validation step involves the developer (who designed the tests) and the product manager who created the PRD. In this conversation, the developer will explain the test design based upon his interpretation of the PRD. The requirements manager will validate that the developer’s interpretation is correct. This requires our product manager to be able to understand from the test designs if the tests will actually confirm that the requirement is satisfied.


Without validation that whitebox tests are going to test the correct interpretation of the requirements, we run the risk of building the wrong software right.

Further reading

For a view of the overall software development process, check out the Software development process example post which organizes eight other articles that focus on other details of the big picture.

To see how other erros like this are introduced in the software development process, check out Where bugs come from, which includes details of how to incorporate feedback loops designed to prevent bugs.

Product management success in the conceptual age

the matrix

The information age is ending and the conceptual age is beginning. In A Whole New Mind, Daniel Pink proposes that six characteristics of right-brain thinking are key to success in the new economy. Nils Davis realizes that these characteristics are embodied by good product managers today. We will define the conceptual age, review the six characteristics, and see how this applies to product management.

What is the conceptual age?

The information age has put almost unlimited information at our fingertips. The problem is that the amount of information can be overwhelming.

In 2001, the amount of information was doubling every 2.5 years – by 2020 it will double every 73 days (per Tom Kelliher).

In the movie, The Matrix, the challenge wasn’t getting access to the information, it was interpreting it. Most of us can’t look at the raw data and see the patterns. The right sides of our brains deal with information and patterns, and the key to success in the future is to be able to absorb and process the information. From this information we develop concepts. We then share those concepts with others.

The use of concepts in communication will be critical, as it provides a simplified way for our listeners to absorb the information we share with them.

What are the key characteristics?

Defining the six aptitudes in a product-management context:

  • Empathy. Being able to approach the product/information/activity from the perspective of the user/listener/actor.
  • Meaning. How do our customers perceive our product – why is it relevant to them?
  • Story. Being able to tell a story about our product or about our users.
  • Symphony. The context, relevance, and big picture perspective. Where does our product fit into the big picture?
  • Design. Interaction design defines how our product is perceived and used.
  • Play. Fun is important

Additional thoughts on each aptitude as they apply to product management

The ability to perceive how our customers will use our software is important. We have to make sure that we don’t create the software that we want, but the software that they want. Understanding their problems is the first step to creating a great solution. We can document the customer’s problems in an MRD.


The relevance of our product to our customers is primarily a function of differentiation. Our customers will think about our product in the context of how it is different and better. Asking ourselves ‘What does this mean to our customers?‘ is a great question to help us focus on the differentiated innovations and ignore irrelevant innovations. Without differentiation, our product is perceived as yet-another-widget. Meaning can also be based upon value, or ROI. And ROI can drive prioritization decisions.


Being able to tell stories about our products is important for marketing and selling our software. Being able to tell stories about our users (or their personas) is a great technique to help us gain insight into how our users will perceive the product.


Context is everything. There is always a bigger picture. We need to understand where our product fits into the bigger picture. When empathizing, we develop an MRD that represents the problems and opportunities. Our understanding of the big picture helps us determine which problems should be addressed with our software. This ideation process drives the creation of a PRD from our MRD.


Alan Cooper has the best perspective we’ve found on design, in his most recent thinking about the role of interaction designer. The interaction designer combines an understanding of the users (empathy) with an appreciation of the value of a particular requirement (meaning) to create a compelling design.


Software needs to be rewarding to users. Those rewards are based upon the user’s personal goals (don’t feel stupid, spend less time on task X, etc). Take a look at the second diagram from this post on interaction design and structured requirements. Play is important, not just because its fun, but because it helps users master the software more quickly, turning the negative experiences into positive ones.

Magic square of innovation

wicked witch of the west

Marcus Ting-A-Kee has a post on his blog with a great magic square diagram describing a perspective on innovation. This framework provides us with an easy way to assess the potential impact of an innovation. We will…

  • show how to use the square
  • look at some example innovations
  • and use the square to prioritize requirements

The square is Marcus’ creation, and his post includes additional content – he’s given me permission to show it here. Thanks, Marcus

innovation magic square

Potential impact

We can use this diagram to plot innovations and get a feel for how much potential impact they could have.

Points further to the right (having greater strategic scope) have more potential for revenue, by introducing new sources of top-line growth (new sales in new markets) for the company that is innovating.

Points higher up (improving organizational capabilities) have more potential for profit, by increasing top-line growth (new sales in existing markets) or by decreasing costs (gaining operational efficiencies or reducing material costs) .

Some examples in each quadrant:

Improve core business

  • Firefox added tabs to browsing.
  • Adobe made pdf documents interactive (you can fill in the forms directly within some pdf files).

Exploit strategic advantage

  • Microsoft leveraged its operating system platform to sell MS Office to corporate clients (where the real money is).
  • Google monetized search with advertising (instead of becoming a portal like Yahoo and MSN).

Develop new capabilities

  • ICQ realized that instant messages could be sent over the web. [We are excluding talk/ytalk/wall, which only supported geeks. People can use ICQ]
  • Paypal made it possible to pay an individual with a credit card.
  • Dell optimized on process efficiency to allow them to dominate the PC industry

Create revolutionary change

  • P2P file sharing utilizing file “fingerprints” and small portions of files (we think Napster was first, but can’t find a trusted answer).
  • eBay enabled millions of people to bid and auction online in a trusted environment.
  • is making the ASP/SAS model viable for enterprise software.

Using this approach for determining the high-value requirements

We’ve talked about using ROI to prioritize requirements – we’re probably starting to sound like a broken record about it. Innovation isn’t assured to be valuable. Differentiated innovation is what we must strive for. Once we have our list of differentiated innovations, we can map them onto this grid to get a gut-check about how valuable they might be. We can also use this grid to sanity check projections based upon these requirements.

One way to do this is to write down all of the requirements that represent differentiated innovation on individual post it notes. Draw this magic square on your whiteboard. Put the post-its where they belong in the square. The further up and right the post-it note is, the earlier the release in which it should be scheduled.

Foundation Series: Feature Driven Development (FDD) Explained

FDD classroom

Feature driven development (FDD) is one of several agile methodologies for developing software iteratively. Iterative development is the opposite of waterfall development.

In a nutshell

FDD is a process that begins with high level planning to define the scope of the project, which then moves into incremental delivery. Each increment of delivery involves a design phase and an implementation phase. The scope of each increment is a single feature. Extreme programming (XP) is a much better known agile methodology. XP is often described as an emergent design process, in that no one knows what the finished product is going to be until the product is finished. FDD, by comparison, defines the overall scope of the project at the beginning, but does not define the details.

Explained by analogy

Consider the writing of a mystery novel as an analogy.

  • Waterfall process. First, our author determines the major characters, the mystery, a detailed plot outline, and outlines for all of the subplots. Then she sketches out all of the minor characters. Finally she writes the novel, following her outline along the way. Immediately after typing ‘the end’ she sends the novel off to the editor. The editor replies with major change suggestions – it seems that the topic might have been in vogue two years ago, but it doesn’t sell very well today. And half the chapters are low-value rambling that are sure to lose the readers. Our author starts over.
  • Extreme programming: XP. Our author decides to write a mystery novel, puts a blank sheet of paper in the typewriter and starts typing. As she writes, she realizes that she’d much rather write a romance, so she edits the chapters she’s finished and keeps moving forward. She sends early drafts to her editor of every chapter as she finishes it. The editor suggests that she change the setting from the Alps to the Amazon, and she edits again. After finishing the book, she has a three-book historical fiction series set in the rain forest.
  • Feature driven development: FDD. Our author creates an outline for the story, gives names to the major characters and prepares to write chapter one. As she starts each chapter, she writes some details of the subplot, makes some notes about how the characters should develop, and begins writing. She sends her outline to the editor, as well as drafts of each chapter as she completes them. She splits her time between incorporating feedback on previous chapters and outlining/writing the current chapter. At the end of the book, she has a mystery with the same major characters that she expected – but they didn’t develop into exactly the people she expected, and she never would have predicted the sub-plots that created themselves as she wrote.

When we look at these approaches, we see that FDD tries to combine the best part of a waterfall process (good planning) with the best part of XP (continuous improvement through iteration).

More detail

There are five phases in an FDD process. The first three phases are planning phases and the last two phases are iterative phases (they are repeated for each iteration).

Planning phases:

  1. Develop an overall model. This is a representation of how the solution will work and what it will do. It is the high-level framework describing the big picture of how everything works together.
  2. Build feature list. This is the list of features needed to implement the high level view from phase 1.
  3. Plan. Create a rough plan of the entire project. Some proponents also talk about creating detailed plans per feature (as each feature is addressed).

Iterative phases (one feature per iteration)

  1. Design the feature. What Alan Cooper would call program design.
  2. Implement the feature. Writing code, testing, documentation.


There is little or no discussion about requirements in FDD. Starting with an overall model is great from a developer’s perspective. The challenge is in determining what to place in the model – what requirements are important to the users? How will users interact with the system? Good answers to these questions can make or break an overall model – and a faulty model will yield low-value software.

This approach to agile development can be very effective when augmented with the right requirements management process.

Learning more about FDD

– – –

Check out the index of the Foundation Series posts which will be updated whenever new posts are added.

Expert systems – do what I say, not what I should have said

albert einstein


We’ve studiously avoided talking about requirements for expert systems because it is such a small niche of software development. Please let us know in the comments on this post if this is an area you would like to read more about. This post is both a discussion of the main barrier to success for these systems and an introduction to future posts if you ask for them in the comments on this post.


Expert systems can solve some of the hardest problems. Yet AI software has not dominated the software landscape, neither Heinlein’s nor Vinge’s fictions have become real. Why has AI software failed? After over 10,000 hours of gathering, validating and implementing requirements for expert systems, we’re convinced that it’s because programmers are being asked to solve the wrong problems.

The problem isn’t that the hardest problems are too hard to solve, it’s that they often don’t need to be solved at all.

Expert systems are often referred to as knowledge engineering systems. An expert system takes a database containing data, and adds engineering rules to it. This database is then usually known as a knowledge base. An engine can then process inputs into “the system”, and generate outputs in accordance with the data and rules embodied in the knowledgebase.

Catalyst for this post
We recently were linked to from Nilsnet (thanks!), and the first article we read was titled ‘Expert System = program that almost solves a toy version of a non-problem‘ by Nils Davis. In that article, he also links to an article that presents a criticism of AI. This just started the gears turning…

Business applications of expert systems
There are a few ‘common’ problems that are addressed with expert systems:

  • Resource planning and allocation: Minimizing the amount of work-in-process inventory that has to be carried to achieve a given production schedule, determining the lowest-cost manufacturing facility to source an order, airplane route scheduling.
  • Equipment configuration: Custom-configuration of high end equipment (telecommunications hardware, super-computers and clusters) with validation that the equipment will be operational as ordered.
  • Travelling salesman: Minimizing the distance or time spent travelling to multiple locations to save costs in scheduling of deliveries.
  • Resource optimization: Resolving otherwise computationally prohibitive constraints to achieve optimal selections of services, software, or hardware.
  • Automation of tedious engineering work: Calculating and validating layout and placement information in association with engineering rules (aircraft interiors, card placement in modular systems, traffic routing in a pbx, etc)

Migration projects are the norm
We’ve talked in the past about the migration continuum, here’s a diagram from that post depicting the range of projects

migration continuum

Every expert system project we’ve seen has been a migration project from an existing process. Fewer than 10% have involved major process changes. These projects almost always get relegated to being plug-ins into existing business processes. The client companies simply automate a step in their existing process. In one major engagement, the client was coincidentally re-engineering their entire project, but the expert systems portion was no more than a box in a flowchart from an executive perspective. A multi-million dollar box, true, but still a second-class portion of the project.

Mis-application of technology
If engineering is the application of science to practical problems, then knowledge engineering is the mis-application of science to impractical problems.

Using expert systems to solve problems requires programmers that are “wired differently.” There are two factors that at least correlate with this.

  1. The experts in these technologies tend to be unappreciative of the other elements of successful software.
  2. The non-experts in most organizations do not understand the technology – neither its capabilities nor its limitations.

Myopic viewpoint

To quote the Gary Martins reference (from Nils’ post):

While all other areas of technology have enjoyed heroic advanages since [1955], AI advocates continue to pick over the same stale chestnuts that seemed so fascinating way back then.

I chuckled when I read this. I remember a project that was undertaken at my previous employer to rewrite/migrate an existing expert system engine to a new platform. The first thing the developer did was create a set of these chesnuts (9-queens, bin-packing, etc.) as his criteria for validating his work. Only after getting feedback did he incorporate real-world problems (pbx trafficing, frame-relay network design, card-slotting). This is exactly the lack of appreciation that prevents the technologists who understand the technology from thinking about valuable applications.

We’ve talked, in Intimate Domains about the importance of operating and communicating in the intersection of these domains, as the following Venn diagram shows.

Domain expertise diagram

The expert system experts tend to conspicuously avoid any overlap with the stakeholders/users/marketing group. My favorite quote from an expert system developer about users:

I’d rather pick up garbage than design user interfaces.


Lack of understanding

Even technically savvy business people don’t have an appreciation of the applicability of expert systems to their problems. Unfortunately, there aren’t many people who can live in both worlds (switch hitters) and provide that synthesis of ideas. Many a glazed eye has ignored a powerpoint presentation attempting to explain the technology.

Lack of collaboration

Ultimately, both of these problems result in a lack of collaboration. A typical conversation might go like this:

Business: We want the software to configure the optimal racked storage system based on our customer’s needs.
Developer: Define optimal. Lowest cost? Highest performance? Highest profit (to our knowledge, no one has implemented a profit-maximizing configurator)?
B: Lowest cost. Can you make it propose upselling suggestions?
D: Of course we could, that’s trivial. But it’s not a good application of this technology. You should focus on the configuration.
B: OK, you’re the expert. How much will this cost? How fast will it run?
D: Optimality is hard. We did a prototype, and we expect it will take a minute to process for a fully maxed out system. Also, it will cost you (really large amount).
B: Well, we need it – go ahead. [Makes note to himself: Replace these guys asap – too expensive]

Here are a couple improvements to the conversation. We start by putting a requirements analyst into the loop.

Business: We want the software to configure the optimal racked storage system based on our customer’s needs.
Analyst: Do you want to optimize on cost to your customer, profits to your company, or some other metric? How important is optimality?
B: Lowest cost. What do you mean important? It’s critical – that’s how we compete!
A: Well, there’s a theoretical lowest cost for any solution. An engineer can figure it out in a day, our software can do it in about a minute. And it will cost you (really large amount). But if we only had to get within 1% of the optimal solution (say $1,000 for a $100,000 storage system), we could do it for half the cost and it would take about a second for our software to find the answer. Besides, our analysis shows that your average system cost your customers 10% more than the “optimal” price. You would be getting 90% of the benefit of the system at half the cost.
B: Our sales reps have the authority to adjust prices up and down 3%, and sales managers can cut them by 5%. We can live with 1%.

Maybe if these conversations had taken place, the companies that failed to capitalize on expert systems would still be around. The problem is that the technologists, in their eagerness to please, do whatever is asked of them (if they can). They never learned to question the value of what they were being asked to do. In our example, the customer didn’t need to get the optimal price – any improvement would make them more competitive. And the business person knew it. The technologist didn’t know to ask.

There are many examples like this in the engineering domain as well. A subject matter expert may say “It must be X,Y,Z” and the developer will say “not a problem.” X,Y,Z might be a choice that saves a penny over X,Z,Y. And implementing “X first” might be a lot easier. Furthermore, the SME should have said ” is important.”

Someone who understands the particular expert system, and who understands business and engineering rules needs to act as an intermediary to gather the requirements. This need is no different than with any software project. The problem is there are so few people who can fill it that the industry is languishing (again) before the problem can truly be addressed.


There are a lot of amazing things that can be accomplished with expert systems. The challenge is in knowing when those solutions are unneccesary. Again, please add a comment if you would like to read more (or not) about expert systems at Tyner Blain. Thanks in advance!

Definition of sunk cost


Sunk cost is an expression representing the unrecoverable amount of money that has already been placed into an ongoing investment or project. It is one of the simplest, yet most commonly misused financial measurements of a project. We’ll learn how to avoid the most common mistake in project (financial) management, and how to survive when our boss makes the mistake.


In The Shawshank Redemption, Andy Dufresne asks the Warden if he’s obtuse. Andy gets a month in solitary confinement for his impertinence. We should remember this when our boss makes a statement like “We can’t cancel the project – we’ve already invested a million dollars in it!” If we want to avoid a month in the pokey, we need to restrain ourselves from telling our boss that he is irresponsible or ignorant.

Reinvestment decision example

Consider a project, with a projected return of $100,000 and a projected cost of $75,000. We previously determined that the project would be a good investment for us, so we funded it. Six months later, we’re reviewing the financials of the project, and discover that our project manager has already spent the $75,000, has not completed the software, and wants another $50,000 to complete the project. Assume that we believe the project manager, and it really will take an additional $50,000 to finish. If we don’t finish the project, the projected return is $0.

We’ve looked at methods for calculating the ROI of a proposed project. How do we make a decision about a project that is partially completed?

Financially incorrect reasoning

We now look at the project as having a total cost of $125,000 and a return of $100,000. We would lose $25,000 with this project – we should kill the project right now.

Financially sound reasoning

Unfortunately, the first $75,000 has already been “lost”, so we should not include it in our analysis. The previous calculation is wrong. Financial decisions are always made about future events, not past events. No decision we make now can recover the sunk costs. We should therefore ignore those costs in any decision making.
At the beginning of the project, the projected value of the project was $25,000 ($100,000 return minus $75,000 cost). [Note: This is similar to, but not the same as expected value]. The projected value of the additional investment is $50,000 ($100,000 return minus $50,000 additional cost). The first $75,000 we spent doesn’t matter any more – it’s already been spent and can not be recovered.

What we are faced with now is the decision to spend $50,000 to get a return of $100,000. There are two possible scenarios: invest nothing and get nothing in return, or invest $50,000 and get $100,000 in return.
sunk ship

The first $75,000 is a sunk cost in that we don’t get that money back just by choosing to not invest more money.

There’s usually more at stake here

In another example, imagine that we’ve invested a million dollars to get a return of 1.5 million. We’ve just discovered that we will have to invest another two million dollars to complete the project. Should we do it? Financially, no. This is where the pointy-haired boss might say “We can’t cancel the project – we’ve already invested a million dollars in it!”

However, that manager may be optimizing on his reputation, not the company’s finances. The reference to previously invested funds could be a red herring. What the boss is really saying is “We can’t cancel the project – the CEO knows that I’m in charge of making this happen!” It may also be that we don’t have all the information. There might be other hard to quantify benefits to completing the project (like goodwill or investor-perceptions) that would justify the added expense. In other words, the return exceeds 1.5 million dollars, we just don’t realize it, even if our boss does.

In cases like this – tread carefully. Those of you old enough to remember the SALT treaty will remember Reagan’s famous statement – “trust, but verify.” Take the same approach with your apparently illogical boss. And if you find out that you can’t trust your boss, find another boss.

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.

How To Create Personas for Goal Driven Development

artist creating personas

How do we create personas?

We mentioned the creation of personas in our overview of the interaction design process. In this post we will talk in more detail about how to create them. We will cover identification and prioritization of the personas, defining the practical and personal goals for the personas, and creating the anecdotal stories that give each persona an identity against which we can make design decisions. Scenarios are also defined for the primary personas, which drive the creation of the functional requirements specification.

Identifying the personas

The first step is to identify who all the users of the application will be. For enterprise or corporate (internal use) software, this process is pretty straightforward. Identify the roles that are expected to interact with the software (sales, tech support, accounting, engineering, etc). Then figure out if there is a homogenous population within each role.

call center rep

For example, tech support may have tier-one support (users who are measured on call-throughput, and start with “is the computer turned on?” questions) personnel and tier-two personnel (the people tier-one support calls in <5% of their calls, when the tasks are too complex or too involved for them to resolve). Tier-two support people may have a very different interaction with the software, as the problems they are addressing have already been vetted (and probably don’t have an answer in the online database).

The tier-one folks may have interactions that are primarily customer-relations and look-up-the-answer scenarios. The tier-two folks have much more of a trouble-shooting role, and may primarily do external research to find solutions, and also add new solutions to the database of known solutions. If the roles are significantly different, then create seperate personas for each.

Defining the practical goals

The practical goals for a persona are the goals that our representative user needs to accomplish for his employer. The employer has corporate goals, and an individual persona will have a set of relevant to them practical goals that represent how they help achieve the corporate goals. Gaining market share, increasing profitability, and growing profitability are all great corporate goals. These goals, however, are too nebulous to be actionable.

Our tier-one support person, call him Jim Turney, may have a practical goal of handling 15 support calls per hour. Our tier-two support person may have a goal of addressing 90% of her calls without deferring to tier-three support.

Defining the personal goals

The personal goals of each persona represent the motivations of the individual. These goals are distinct from corporate or practical goals. “Don’t feel stupid” and “Get a promotion” are personal goals. These goals help to identify the individual, and provide insights to the designers that help them design the most intuitive, usable interfaces for the application. All users are not created equal, so it is imperative that we capture the essence of the persona using the computer before attempting to design the perfect user interface for her.

Defining scenarios

Each persona will have a set of scenarios that represent the activities that they perform with the software we’re designing. We don’t capture every activity that the user performs, only those that involve interaction with the software. The frequency of occurance of the scenario is represented by classifying the scenario as daily-use, necessary-use (infrequent, but required), or edge-case (very unlikely to occur).

We previously explained the categories as follows:

  • The edge cases are immediately discarded by the interaction designer – these happen so infrequently that the penalty of enabling them outweighs the benefit. The penalties are not just measured in implementation costs, but costs to the user of having to understand, ignore, or otherwise work around the added capabilities needed to support the edge cases.
  • Necessary use scenarios are scenarios that must happen, but happen very infrequently. The requirements specification will include the functional capabilities needed to support these scenarios. Interaction design effort will not be spent on optimizing these scenarios, however. The theory is that since they are so infrequent, users will tolerate whatever implementation exists to make them happen.
  • Daily use scenarios are the ones that the primary persona performs most often. Most users will have one or two daily-use scenarios. More than three is rare according to Cooper. This is where new users must get up to speed the fastest, benefits from good design are reaped the most, and the lion’s share of interaction design effort is applied.

The daily-use and necessary-use scenarios drive the functional requirements specification.

The daily-use scenarios drive investment in interface design decisions.

Prioritizing the personas

After we’ve created the personas representing all of the users of the application, we must select the primary persona. We will design the application for the primary persona. We can make this selection based upon the inherent value of the persona’s practical goals and their associated scenarios. We have written previously about using ROI to prioritize requirements with value-based prioritization. We can apply the same general techniques to selecting the primary persona.

The practical goals of each persona represent their personal ability to help the company achieve its corporate goals. Corporate goals are enabled via the practical goals. These practical goals embody the particular business processes that are being created, enabled, or improved with the new software project [background on software migration projects]. Each persona achieves their practical goals through scenarios. The frequency of each scenario can be combined with the number of users represented by a particular persona to identify the magnitude of the impact. A project that will reduce the cost of submitting a quote by $1 per quote, for example, is worth $1,000,000 per year if 100 people each submit 50 quotes per day.

Select the persona who’s practical goals represent the greatest impact on the corporate goals. Another way to think of it – pick the person who stands to benefit the most from the software.
Creating a sense of identity

There are two ways that we create a sense of identity around a persona. First, find a picture of a person that superficially has the characteristics of the persona. This becomes the face of the user. Or find a picture that “matches” the name you give the persona. The following pictures might represent a tier-two tech support person and an executive assistant. Pick a face that represents the persona to you.



The second thing we do is tell stories about the persona. The more detailed the stories, the better. Relevance of the story to the software is irrelevant. What we are trying to do is characterize the individual in a way that will inspire good design decisions. We might write a story for our tier-two tech support person as follows:

Sam is an avid video-game player, and values the level of knowledge she has about her favorite games. Sam reads all the forums, knows the cheat codes, and plays the games against herself. Sam’s latest trick, to save time, is to focus on perfection. Sam plays Galaga, but only plays the first level, and tries to achieve a greater than 100% hit ratio for shots fired (which is possible only if she gets a ship captured and can kill two aliens at a time). Sam is also an avid frisbee golfer, and plays every Saturday with a regular team. Sam’s also the one who keeps a website running with all of the stats and schedules. The only thing Sam doesn’t like is talking to new people. Sam’s friends describe Sam as someone who ‘takes a while to warm up to.’ Sam would much rather answer someone’s questions on a forum than over the phone.

How do we use the personas?

We use the personas to identify the primary user(s) of our application. These users drive the development of requirements and features needed to support the persona’s daily use scenarios. Interaction designers will also use the details of the persona (captured in stories and personal goals) to drive design decisions in the creation of the user interface, and more generally the interactions that the user will have with the software.

We often rely on the persona to prevent internally-driven scope creep. When a team member suggests that someone may want to browse the database of tech-support call logs, organized by the tier-one person who received the call, we can respond that Sam wouldn’t do that. And if Sam would not do it, the software won’t do it either. This is a great technique for focusing on the most important requirements.

This focus helps us create software that helps the most important users achieve mastery of the software the fastest.

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