A picture is worth a thousand words.  A prototype is worth a thousand lines of code.  Two key elements of product management – and of agile development are elicitation and feedback.  Low fidelity artifacts can significantly improve both.  Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.

Prototyping Anti-Pattern

David Bernstein has three good quick-read articles about prototyping in the agile zone.  The first one depicts the primary anti-pattern of prototyping – mis-set expectations.

As I was walking him through the different screens I could see he was starting to get uneasy. As I talked I could see him becoming paler and tenser, as if he saw a ghost. After a while I asked him if he was ok. He finally said, “You mean to tell me that I just wrote you a check for over $100,000 for less than a week of work?”

Prototyping Caveat

The second article is quick reminder of one of the goals of a prototype.

The purpose of a prototype is to elicit feedback from others or verify a design approach will work. When doing this we generally only concern ourselves with the “happy path” through our code.

A Prototype is Not a Product

David’s third article explores a little more about the mis-setting of expectations, and provides a good parallel from the film industry.

Prototypes are rough sketches without the robustness of a final product and it is often confusing to users when we show them a half-baked version of their project for feedback, even though they know it is not yet finished.

Agile Prototyping on a Napkin

David’s advice is (good and) primarily about using low-fidelity prototypes to avoid disrupting the elicitation and feedback process.  Folks in the user experience community have known this for a long time, and adapted their processes accordingly.  Back in 2006, I wrote about prototype fidelity as part of exploring ways to use this insight in requirements gathering.  Prototyping, in particular, is a great way to elicit implicit requirements – those unspoken (“you should have asked!”) requirements that your customer or stakeholder assumed you knew, or didn’t think to tell you.

Multiple Levels of Interaction

David focused on the initial “will this approach work?” elements of getting feedback on a design – and by inference, some low-fidelity user acceptance testing that the proposed approach will meet your customer’s requirements.  Jan Miksovsky wrote an excellent article (also in 2006) that provides excellent guidance on how much fidelity to build into your prototype, depending on where you are in the design process.  This is important – the type of feedback you need at different stages of your design process varies.  Jan proposes that the first prototypes be rough sketches, just as David points out.  Jan goes on to show how and when to add additional fidelity to your prototypes (read Jan’s article to see his great visual examples).  Like I said, the user experience community has known about this for a long time.

Prototypes Are For Two-Way Communication

The key element, and the reason for creating prototypes, is to get two-way communication.  A prototype is not just a status update about your design.

A prototype is the start of a conversation.

[thanks uninen for the image]

Prototyping is not only useful for design conversations, it is critical to understanding your requirements.  Yes, a prototype will you get feedback about the design-execution of your proposed solution.  More importantly, a prototype can help you make sure you’re solving the right market problems.

Prototypes Are More Than Interface Mock-Ups

The first thing we think about, and everything you’ve read so far in this article, is about getting feedback on the user interface of the product.  Prototypes are also useful for gathering business rules*, understanding system complexity, and defining, clarifying, and validating requirements.

*In that article, I show prototypes as “not being useful” for gathering business rules.  At that time, I was thinking in terms of interface mock-ups only, not other prototypes.

Use interface mock-ups when you need feedback about user interaction.  Use other artifacts when you need feedback about other aspects of your product.  You can use prototypes as an active-listening technique when gathering market data too.  There are lots of ways to draw stuff to help with communication.

I’ve regularly used flow charts to prototype processes.  Within those flow-charts, which are initially prototypes of how the product will behave, are decision diamonds.  Those decision diamonds prototype the enforcement of business rules within the to-be-created product.  In the spirit of DRY (don’t repeat yourself), a quick polishing of your process diagram can serve as a persistent artifact of the requirements.  Just like a user interface mock-up.

In more complicated scenarios, I’ve also used UML statecharts and data flow diagrams to prototype behavior.

In the section on up-front planning in last week’s article on risk management and release cadence, I talked about the mental leap that people need to make to envision a product that doesn’t yet exist.  Prototypes are like big springboards that help people leap that chasm of imagination.

Important Safety Tip

Don’t use the wrong prototype (mock-up, flow chart, etc) for the wrong conversation or with the wrong stakeholder.  Showing when and where business rules are being enforced (in the process being designed) is great for getting feedback about your interpretation and potential embodiment of those rules.  It will be a disaster if you try and have this conversation with someone who is not the owner of those policies – like a representative user.  Sometimes, policies are “owned” by non-technical people who struggle to read diagrams.  You may have to walk them through how the diagram works.  They’re smart – they’ll get it.

Just remember – use the right prototype to emphasize the right ideas, and elicit the right feedback.

I’ve been thinking about the software development process.  Big, upfront, design and requirements.  User research and analysis.  Market insights, gained on exploration or over time.  Release cadence – how quickly you get, and incorporate, feedback from your customers about your product.  How quickly you react to your competitors’ reactions to your actions.

Big and Up-Front

Leander Kahney published the full transcript of an interview with John Sculley, former CEO of Apple, last week.  Of particular interest are the discussions about how Steve Jobs is a designer first, CEO second.

He always looked at things from the perspective of what was the user’s experience going to be? But unlike a lot of people in product marketing in those days, who would go out and do consumer testing, asking people, “What did they want?” Steve didn’t believe in that.

John Sculley interview

The theme of understanding what users want and need comes up repeatedly in the article.  A few years ago, Alan Cooper and Kent Beck got in a debate about the merits of interaction-design-driven versus emergent-design software development.  Four years later, I don’t accept the premise that you have to choose between the two.  You can treat both decisions independently and make the right choice for your team and market.

Thanks Jim Holland (also PM Tribe author), for bringing this article from Wayne Mulligan (guesting on On PM) to our attention today.  It’s a great read, and the money-quote from Wayne about going back to first-principles is:

And that’s the biggest lesson I learned here – you can reap all of the benefits of an agile product development approach without following the rules to the letter.  It’s the spirit of the manifesto that counts and not the precise implementation.

4 Ways that Agile Methods Brought Sanity to My Company

In the spirit of that reality – I believe decoupling how do you plan? from how do you deploy? is fair game.

The Risk of Being (Big Picture) Wrong

[larger image]

When you do no upfront analysis at all, you have complete risk of creating the wrong product.  The more analysis you do, the more likely you are to create a product that solves the right problems – problems that your target customers, in your target market, are willing to pay to solve.  The units in the graphs in this article can be mostly ignored – all you can really capture, when talking generally about this is the trending.  The more time you spend understanding your market, the less understanding you gain.  There is definitely a law of diminishing returns.  This effect is one of the reasons analysis paralysis is so bad.  With analysis paralysis, you delay the launch of your product (at some cost), for no appreciable gain.

The two curves are labeled complex market, and simple market.  The idea here is that the easier it is to understand your market, the less benefit you get from analyzing it.  Complexity can be in the form of competitive concentration, nuances of problems being solved, specifics of the customers for whom you are solving the problem, and even the notion of just how innovative your solution is (think cars, when horses were common, or smart phones in a world of land-lines).

As a product manager, you have to act with imperfect information.  Even if you try and uncover every relevant piece of information (which you can’t do), you will misunderstand some things.  You will develop a mental model of your customers’ problems – and that model will be wrong.  You will also predict competitive responses incorrectly.  To top it off, you’ll make mistakes about “what’s next?” for your customers.

That does not mean you should do no analysis – it means you should not do too much analysis.

Not all product managers are equally good at distilling insights from the vapor of nuanced market data.  Great product managers will have (correct) epiphanies about the important problems to solve, and the impacts of disruption on the market.  Others will not.  The better you are at having these insights, the faster you reduce risk – and the faster you reach the point of diminishing returns of additional analysis.  Some product managers and markets may require weeks of analysis, others may require days.

The Risk of Being (Execution) Wrong

Another great quote from the Sculley interview:

[Jobs] said, “How can I possibly ask somebody what a graphics-based computer ought to be when they have no idea what a graphic based computer is? No one has ever seen one before.” He believed that showing someone a calculator, for example, would not give them any indication as to where the computer was going to go because it was just too big a leap.

John Sculley

In The Design of Design, Frederick Brooks discusses the debate between empiricists and rationalists.  Empiricists, in product creation, emphasize feedback as the means of gaining insight about what your product should be.  Rationalists use intuition and deduction to presuppose what a product should be.  In the hyperbole of many agile-waterfall debates, empiricists are burdened with the impossibility of designing the right product in advance, while rationalists struggle under the yoke of being wrong from the start and wasting their efforts up until the first failed product release.

Obviously, neither of these extreme perspectives is wholly true – while both have significant elements of truth.

True insights about your market grow stale with time.  The damage from erroneous conclusions about your market grows over time.  The risk of creating the wrong product grows over time.

[larger image]

If you released continuously, including getting feedback continuously, you would face the minimal possible risk that the market has changed since last you checked.  You would also maximize the opportunities to correct mistaken conclusions – thus minimizing the risk of being wrong.

You reduce the size of this risk by getting feedback.  You get feedback by “releasing” your product to customers, either as a prototype or as a product.  Jobs (per Mr. Sculley) realizes the catch-22 of not being able to get inputs from others, until they can realize a version of your idea. Sculley attributes the following to Mr. Jobs: “There was no way to do consumer research on it so I had to go and create it and then show it to people and say now what do you think?“

The longer you wait to get feedback, the greater the cost of effort invested in the wrong ideas.  The longer you wait to get feedback, the greater the risk that your market has changed since you formed your ideas.

In stagnant markets, where problems and their solutions are well understood, and change happens slowly and competitors don’t innovate, you can release less frequently with less risk.  Until someone decides to innovate, and make your market more dynamic.  Markets with active competitors, customers who’s expectations change, and problems that evolve are more dynamic.  The risk of delays is greater.

Rationalism and Empiricism Can Co-Exist

My experience has been that both concepts – “think before you act” and “fail fast, get feedback” can happily co-exist.

• You can develop an understanding of your market, your customers, and the very real problems they face, before creating a product that solves those problems.
• Introducing a new product / solution into a market changes that market – so you have to revisit what you know at least as frequently as your market changes.
• Even when you understand the problem, you need feedback to know if the product is actually the solution.  The greater the “leap,” the more representative your prototype must be for people to give you feedback about the (eventual) product.

What have your experiences been?

Almost everything I’ve read about use cases focuses on describing what needs to be added to your product.  Agile development says “get it working first, make it better second.”  That means changing the way the software enables a user to do something they can already do.  How do you manage requirements for incremental improvement?

Iterative Development and Incremental Improvement

Iterative development is the process by which you release software in iterations – small, incrementally better versions of your software.  People usually think about this solely in terms of enable the most valuable capabilities first, then the next most valuable capability next.

That’s fine, when your product is new.  Eventually (or quickly!) you will reach the point when the next most valuable improvement is not to add a new capability, but rather, to make an existing capability more valuable.

Everything is an Upgrade

In a couple earlier articles about organizing migration projects and requirements for migration projects, I wrote about how migration is a bit of a misnomer.  Everything is a migration.

My argument in those earlier articles is that the problems you’re solving with your “new” solution are not new.  Your customers are currently solving them in different ways.  The relevant question for migration projects is around how much your users are changing the way they solve their problems.

[As a slight segue, failing to appreciate this distinction can lead you to a project that is based on a faulty problem statement.]

When you are delivering incremental improvements to your product, through iterative development, you are upgrading your software.  You are migrating your users from their old solution to their new solution.  It just so happens that you are replacing yourself, as you migrate them from the old version to the new one.

A viable strategy, that appeals to me personally, is to continuously innovate, disrupting your market, before someone else does.  With this approach, you are intentionally reinventing your solution, making it difficult for someone else to out-innovate you.  This is a great way to approach developing your roadmap strategically.

Your market will change.  Rapidly. Do you want to react to your competitors, or keep them on their heels while you stay on the balls of your feet?

The reverberations of the “new” Twitter still haven’t settled, and many of Twitter’s competitors are on their heels – some of them only now realizing that Twitter has always been a competitor and not just “a platform.”  The new Twitter doesn’t really change anything about how people use Twitter, except make it (markedly) better.

Avoiding Featuritis

When is it more valuable to improve what your software already enables, versus enabling users to accomplish more with your software?  Kathy Sierra introduced us to the concept of featuritis, the idea that too much is too much.

In an article on viral product management, I proposed that by making your software better, you can tap into an altruistic mechanism by which people will promote your product.  As an example, I proposed improving the usability of your software as a means to cross this viral tipping point.

One of the key ideas is that making it better for users makes your product better for your company.

Managing “Improvement” Requirements

Now that we all agree that there is value in making your software better [comment below if you disagree] the question becomes “How?!”

Use Cases can be used as the keystone to your requirements arch.  Sometimes, user stories are better than use cases, but use cases are perfectly agile.  When you’re starting a project, you want to apply an outside-in approach to defining the scope of that project – or more particularly, to define the scope of problems you are solving in your roadmap. This article will talk in the language of use cases, but identical concepts and approaches apply when using user stories as well.

When you have prioritized a use case as “the next most valuable capability to introduce” you add it to the backlog for your sprint.  The implementation team then provides feedback that use case is “too big” and you have to slice it up.  It is important that you don’t split the use case  in such a way that you only solve half the problem.

You also shouldn’t deliver a “bad” product.  In fact, the ideal way to introduce a new capability is to satisfice, and not introduce the “perfect” solution in your first iteration.  Make your first solution “good enough.”  Part of the art is defining “good enough,” but rest assured, it is not the same as “the best you can possibly do.”

Summarizing some key elements from above demonstrates the eventual reality you will face:

1. Every problem* your users face is already being solved, you are just providing a better solution.
2. There is diminishing, and eventually negative return on adding more capabilities to your product.
3. Your first release of a given capability will only be “good enough.”  That leaves room for improvement.

*Yes, you can pedantically define “the problem” as “the existing solution is not good enough” – but you still end up in the same place, so why bother?

Eventually, the value of improving something you’ve already released will be greater than the value of releasing something new.

What do you do?  You implement the same use case again.

If your product is Software as a Service (SaaS), you absolutely should be thinking about things this way.  Becoming better is a continuous improvement objective that is implicit in the economics of SaaS products.

Revisiting Use Cases

Not to be confused with re-use of use cases, revisiting a use case is specifically revisiting – with the goal of improving – the implementation that is already in place within your product.  This is a special case of a migration project – you’re migrating your users from your old solution to your new and improved solution.

You may be migrating to an identical process, perhaps with faster performance than your previous release was capable of.  Or you may be improving the procedure (improving usability, interaction design, visual design, etc) without affecting the process. Generally, a “make it better” use case improvement effort will have no more than a minor process impact.  Your users are still doing the same thing, they are just enjoying it more, or doing it more effectively.

When slicing use cases to make them fit within a single sprint, you may design them for a single user persona in the first release, knowing that you won’t meet the expectations of a different user persona until the next release.  In this case, your non-functional requirements, constraints, or acceptance criteria will be different.  Your use case may also be different (in the details) while appearing to be the same.  This also common scenario can be addressed with the same approach.

Find that old use case (from several iterations ago) and put it back in the backlog.  Remember, agile is about conversation, not artifacts.  If you need to add an explanation to the use case, because your team fixates on the fact that it is “already working,” add a qualifier that it needs to be “better.”  Then have a conversation, and explain how it needs to be better.

Is Design Part of Implementation?

Some teams organize such that designers (both architects designing code and designers designing interfaces are being addressed here) are part of the implementation team.  Other companies treat designers as stakeholders – providing guidance and input to the product managers and product owners.

When a “new design” is being requested from outside the team, include that design guidance as part of the input to the implementation team – through artifact and / or clarification.

When a “new design” is being requested of the team (the designer is part of the team), express the new acceptance criteria to the team.  Note that these need to be measurable requirements if they are to be considered good requirements.

Summary

There will come a time when the most valuable thing you can do is improve the user experience for a capability your product already embodies.  When that time comes, use the same use case again, updated with the new constraints, non-functional requirements, and acceptance criteria.

I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.

Bonus: the idea is cool.

Mad Libs Input Form

[full size image available in Luke's article]

The idea being presented is to replace the old boring web input form designed for a computer. The new, fun form is a fill-in-the-blank (aka Mad Libs) layout. The article is on Luke Wroblewski’s site.  The team at Vast.com created and tested a version of this form for the Kelly Blue Book site. [Luke cites Huffduffer.com as the first place where he saw this technique.] Thanks, Luke for sharing this with all of us!

Outside-In Development

Product managers are acutely aware of the need to solve market problems. We are regularly reminded that we’re creating solutions for people in our markets who use our products to solve their problems. When we write requirements, we avoid writing design specifications, and thereby lose the ability to enforce that the proposed solutions also take an outside-in approach. We maintain an outside-in perspective, but we lost the ability to influence an outside-in aesthetic.

Note: Outside-In Software Development is a great book, you should read it.

That’s one area where user experience works well in concert with product management – assuring that the same drivers of what to build are informing the design of how it is built.

The genius (or at least elegance) of this Mad Libs form from Vast / Kelly Blue Book is that it humanizes the experience of requesting that a nearby dealer contact you to discuss a possible purchase of a car from them. The forms we’ve all had to fill out on countless web sites are very inside-out. They expose the inner workings of the program – “gather this info, and that info, and this other info.” Those forms force users to do what the program wants. Blech. The form that Ron Kurti designed, however, forces the program to do what the users want. Huzzah!

Bad Requirements Prevent Elegance

I’ve written about the importance of writing design-free requirements several times.  Avoiding design constraints in your requirements is even one of the pillars of the big 10 rules of writing requirements.

If you had written the requirements for this contact the dealer page, would you have specified the design of the form?

Most of the requirements analysts I’ve worked with would have. I’ve even worked with companies that have developed templates / stencils defining how these interface specifications must be documented – requiring that all the fields be aligned, with specific pixel gaps, etc.

If you had specified the design (read: limited the choices of the designer), you would have prevented this solution.

Mr. Kurti’s elegant solution is clearly better.

One way to write the requirements that would not have prevented this solution would be with a user story and acceptance criteria:

As a car-shopper, I want to engage a car dealer, once every few years, so that I can purchase the car I selected.

• The car-shopper can provide his contact info (name, email, phone) for the car dealer.
• The system will display the information identifying the selected vehicle.
• The system will display the information identifying the dealer being contacted.
• The system will include an opt-in newsletter-subscription option.
• The system will notify the specified dealer when the car-shopper indicates.

The user story nudges the developers into an outside-in perspective by emphasizing the user’s goal. The acceptance criteria make it clear that any solution that meets those criteria is acceptable to the product manager. It allows the interaction designer to create a compelling solution, rather than forcing him to recreate a boring experience.

Measurement Rocks

The Vast team measured the impact of making this change to their form, and saw between a 25% and 40% increase in conversion (people contacting dealers versus people abandoning the process when they see the form). That’s a lot more leads for the dealers, and presumably a lot more money for Kelly Blue Book and Vast. This is a great example of how you can measure the impact of investing in user experience, because it should spark ideas for you.

What can you measure and test and improve?

Now that’s ROI for you.

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Design-Free Requirements – Revisiting

It has been three years since I wrote Writing Design-Free Requirements as part of The Big Ten Rules of Writing Requirements.  In that time, agile development practices have moved from being an esoteric development methodology to being the topic on the tips of everyone’s tongues as executives and organizations try to either (1) get the benefits of the state of the art in software-development process or (2) do something shiny and fashionable.

The previous article centered on elements of designs within MRD, PRD, and SRS artifacts.  A regular alphabet soup of artifacts.  Honoring the values behind the agile manifesto encourages us to emphasize working software over comprehensive documentation.  In that light, we’ll take a “what is needed” approach to talking about how requirements, design, and implementation are all needed – rather than issue an edict about where that information should be captured.

Agile Development Inputs

When creating software, someone needs to know:

• What problems are being solved, and how important (valuable) they are to be solved.
• Who has the problems and who is using the software to (help) solve those problems.
• What constraints limit the space that defines the universe of possible viable solutions.
• What acceptance criteria define if the delivered solution will be acceptable.

Subject to those inputs, someone needs to make design decisions:

• User experience design - what interactions will a user of our solution love?
• Program design – how (in a nuts and bolts way) will our solution function?

When talking about agile and talking about design, we should take a look at how Kent Beck and Alan Cooper, as respective though leaders in each space, view this.

Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.

[...]

Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.

Interaction Design Process Overview

I don’t believe that Beck is arguing for “don’t do design” – I believe he is arguing for “don’t do big upfront design that would delay implementation.”  He’s championing the agile values that emphasize creating working software and responding to change.  I can imagine him saying “no one will buy a design, they want a solution.”  Cooper’s point is that create a solution without first understanding how someone will use it, you can’t create a great product.

Program design has many hidden impacts – cost of maintenance, cost to change, and the performance of the solution.  You can have a design (or architecture) that makes everything easier to do in the future – at the cost of delaying the delivery of anything.  Or you can have a design that minimizes the time to deliver the first thing, while increasing the cost to deliver any particular next thing.  Or you can design a solution that falls somewhere between those extremes.

If you say “we don’t do design” you’re lying.  Every solution includes design.  Your team’s design process may be “big and upfront” or it could be a couple sketches on a whiteboard, or some email exchanges.  You may create storyboards and wireframes.  Or design may be the thing that happens right before the programmer’s fingers strike the keys.  Design may be explicit or it may be implicit – but it never “doesn’t happen.”

In the movie Amadeus, Salieri is astounded that there are no rough drafts of Mozart’s compositions.  That’s because Mozart did the design in his head, not because he didn’t do design.  I’ve worked with programmers who’s “implicit designs” were great, but that is the exception, not the rule.

Who Owns Design?

Since design happens sometime before fingers strike the keyboard, the real question is – “who owns the design?”

• You have a product manager developing an understanding of market problems, and prioritizing the problems that should be solved with your product.
• You may have a product owner managing the backlog and clarifying those requirements (problems) for the development team.
• You may have an interface (or interaction) designer or team of designers who are broadly responsible for “how users interact with our products.”
• You may have an architect or lead engineer who is responsible for the “big picture design” of how your product works.
• You have developers and testers who are responsible for delivering your product. [Note: coding without testing is like typing code without compiling - maybe it works, but probably not.]

You may not have distinct individuals with each of these titles – every small team I’ve worked with has people wearing multiple hats.  This is especially true when you have an agile team full of specializing generalists – any given story (or task) may have a different architect and different implementer.  I’ve only worked with one company where the architects are NOT part of the development team.  If your team is set up that way, please comment below – I had never seen that before, and I’m not convinced that it is the best way to organize – what have your experiences been?

Generally, “program design” is clearly owned by the development team – and product managers (and product owners) know better than to specify program design in their requirements.  Neither the lead engineer nor the product manager believes that the product manager is a better programmer – so the product manager better not be specifying program design and mislabeling it as requirements.  Coincidentally, Steve Johnson, at Pragmatic Marketing has a post running right now with a bit of a quiz – is this a req(uirment) or a spec (design)?

Where the line is more blurred is around interface and/or interaction design.  Some development teams have interface designers as part of the team.  Some companies organize with interface design as a “shared service” within the company.  Either approach can be the “right one” – it depends on too many details to make a sweeping generalization.  When the designers are members of the development team, the solution (from a product management perspective) is the same – the “team” is responsible for all design.  When the designers are not part of the development team, the developers have to consume two sets of guidance – “solve this problem” from product management, and “the solution needs to look like / act like this” from the designers.

Collaboration between product management and user experience people is the ideal solution.  The “requirements” and “design” inputs to the development team are comprehensive and consistent.

Design-Free Requirements

There are benefits – especially when being agile and minimizing documentation – to delivering requirements and design at the same time.  Just don’t do it by embedding design constraints within the requirements.

• When people on your team misinterpret design as requirements, they are unnecessarily constrained.
• As a product manager – are you the best designer on your team?  If you’re busy designing, who’s product managing?

This is trickiest when writing use cases – sequencing a set of interactions is interaction design.  That is one benefit of writing a user story instead of a use case.  An approach that has worked well for me with multiple teams is to deliver user stories (requirements) combined with storyboards (interaction design) and wireframes (interface design).  When details are needed (usually when “changing” versus “creating” an interface), screenshots can replace wireframes.  When business processes are complicated, process flows can replace storyboards.

Just don’t embed the designs within the requirements.

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

User Goals

A user centered, or user-centric approach to developing software is one where you start by identifying the key persona in your target market.  For each of those personas, you identify their most important goals.  You then identify the user stories or use cases that represent the things these people do in order to achieve their goals.  These “things” are manifested as practical goals.  For these activities, you design user interfaces (process, layout, architecture, look and feel, etc) that create customer delight for those users, doing those things.  This is how your product exceeds the suck-threshold (good enough that it doesn’t suck to use your product).

Corporate Goals

There’s a reason your company is creating or improving a product.  It may be to gain market share, or improve profitability, or increase sales.  Whatever it is, there’s a corporate goal that your decisions should be supporting.  The (subset of) corporate goals that are relevant to your product could be communicated in a vision and scope document, that constrains the domain of problems to be solved, and provides nuanced insights into viable approaches to solving them (example vision and scope).

Corporate goals are achieved when customers do things with the products.  These “things” are manifested as practical goals.  For those activities, you document what should be accomplishable and why.

Alignment and Conflict of Goals

Notice that both the user goals and corporate goals manifest in terms of people doing things.  When the person (user) wants to do the same things that your company wants them to do, you’re in alignment.  When the user goals and corporate goals suggest different activities, you’re in conflict.

You can see visually that these worlds collide at the “practical goals” stage  in the following diagram, from an article on combining interaction design and structured requirements principles.

It may be great – when the user and corporate goals are in alignment, the practical goal and associated scenario (activity) are easily defined.  What about when the goals are in conflict?

Vending Machine Example

Last Thursday morning, as I interacted with a vending machine, the idea for this article was dispensed along with my Diet Mountain Dew.  Yes, I know that’s odd.  Move on.

It occured to me that the process of buying a cold, caffeinated beverage can be both aligned and unaligned from the perspective of user and corporate goals.  If you imagine writing a use case for purchasing a beverage from the vending machine, your most important scenario is the one where a person wants to purchase a beverage that is available in the machine.

• User Goal: Get refreshed and vitalized.
• Corporate Goal: Sell a beverage.

I want to buy a Diet Mountain Dew, as a means to realize my personal goal.  The owner of the vending machine wants to realize her corporate goal of selling me the beverage I want to buy.  We’re in alignment.  Our requirements definitions and design decisions will be pretty easy – everything that increases the likelihood of and improves the experience of purchasing that beverage is good.  I put my money in the machine and push the button.

Then it occurs to me – there’s a situation where my personal goals are clearly not aligned with the corporate goals of the vending machine owner.  When there is no Diet Mountain Dew available to be purchased.

Consider the following procedure I’m forced to endure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I put my money in the machine.
3. I push the button for Diet Mountain Dew.
4. The tiny display on the machine presents a message in taunting, scrolling red LED lights: SOLD OUT.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

Consider an alternate procedure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I view the ‘current availability’ of Diet Mountain Dew and see that this machine is currently sold out of Diet Mountain Dew.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

The differences in these two possible procedures indicate that there is a conflict between the corporate goal and the user goal.  With the first procedure, the “Sell a beverage” goal is given more importance, because it makes me more likely to purchase a beverage that I don’t particularly want.  My utility is potentially sacrificed, while the owner of the vending machine is just as satisfied.

By failing to tell me that I can’t get what I want, until I’m further invested in the process, I am more likely to purchase something else.  That purchase creates just as much value for the owner of the vending machine, but less value for me.

If the vending machine owner had allowed me to use the second procedure, it would demonstrate that the  owner believed the improved customer experience, while risking the loss of this sale, would encourage me to purchase more over time.  The owner would have been prioritizing the requirements and design that supported the user goal ahead of those supporting the corporate goal – in hopes that my user loyalty would result in better word of mouth (more business from other people) and more business from me over time.

Generalizing User and Corporate Goal Conflicts

In this vending machine example, the annoying procedure is probably the right one – I’m going to treat the “point of use vending of cold, caffeinated beverages” as a commodity product.  This market has a very low barrier to entry, and relatively small problem being solved.  I’m not going to tell my friends about how much I love the vending machines from Joey’s Vending and encourage them to go out of their way to find and use those machines.  Nor will I purchase more Diet Mountain Dew because the emotional cost of the occasional “sold out” scenario is trivially smaller with Joey’s machines.  I would, however, be more likely to buy a Diet Pepsi when I’ve already invested time in the process and put my money in the machine – especially when the alternative is to find a water fountain.  I’m emotionally invested at this point.

However, this experience did jump out at me as one that is worth explicit consideration when defining requirements and designing solutions.  It does come up regularly.

The new iPhone 3GS hardware allows tethering (using the phone as an internet-connection device for your laptop).  ATT (the exclusive carrier for iPhones in the USA) is indicating that they will charge customers an extra monthly fee for this capability, when they eventually allow it on their network.  The user already has a data plan, and the traffic that ATT would have to carry is just “data.”  The user just wants it to work.  ATT, however, may want more money, or may want to limit data traffic on its network – perhaps to improve the quality of service to all customers.  This could be ATT’s corporate goal of “provide better service quality” conflicting with the user’s “increase the flexibilty of how I use my data plan.”  The former would likely influence customer satisfaction (and abandonment) over time, while the latter would influence customer acquisition rates.  Another conflict in goals.

Think about how different goals can lead to conflicting solutions, requirements, and designs.  And tell me when you’re out of Diet Mountain Dew before I’m emotionally invested in the purchase.

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

Goal Driven Use Cases

In the world of structured requirements, we apply an approach of top-down decomposition to determine what we need to build.

In an article stressing the importance of non-functional requirements, we summarized the relationships from the above diagram as follows:

• Goals are achieved by enabling use cases.
• Goals drive non-functional requirements.
• Use cases are enabled by implementing functional requirements.
• Use cases influence non-functional requirements.
• Non-Functional Requirements define the characteristics of functional requirements.
• Functional requirements drive design decisions
• Design choices are restricted by constraints
• Design choices guide implementation
• Implementation is product

Non-Functional Requirements Equal Rights Amendment

The key element, with respect to this article, is that goals are achieved by enabling use cases. In other words, without the use cases that people* perform, the goals of the business can not be achieved.

[*Sometimes the use case is performed by a system - not all actors are people]

Principal Stakeholders Own Business Goals

We learned a lot from Outside-In Software Development, by Carl Kessler and John Sweitzer. One of the important things we learned is how to understand the goals of principal stakeholders. Principal stakeholders are the “owners” of the ROI that we are attempting to achieve with our product or solution. The business has the goals, but the business is an abstract entity. If the goal of the business is to increase sales by 10%, we can’t call up the business and ask “did we meet your goal?” We have to call up the vice president of sales. The business is organized so that there are people who are responsible for the initiatives and goals of the business – they are responsible for growth, profitability, costs, strategy. The insight we got from Kessler and Sweitzer is an appreciation that this ownership lies with one or more individuals.

When a goal has an owner, we can validate that we have met the goal. We can validate that we have satisfied the owner of the goal. You can’t do that validation with an abstract entity, a “business”, but you can with a person. Certainly, we can do the math ourselves, but if we want someone to pay the bills – and more importantly – invite us back to do more projects, we have to satisfy an individual. And that individual is our principal stakeholder.

Principals Own Use Cases

Our principal stakeholder owns the business goal – and therefore owns the use cases that enable that goal to be achieved. Our stakeholder will validate the completeness of our use cases by answering the question, “If we enable all of these use cases, will we completely meet your goal?”

End Users Own Use Cases

User-centered design is also one of our core principles, and an acknowledged best-practice. For many companies, it is more than mandatory – it is a way of life. The entire software development process is sometimes built around a focus on the end users. This approach puts the user in the center.

You can identify end user goals with the following approach:

1. Identify the actors that interact with the software.
2. Identify the personas that represent those actors – thus avoiding the elastic user syndrome.
3. Develop an understanding of the personal goals of the personas – and by extension, the actors through ethnographic research.

Stakeholder Goals: Principal vs. End User

This creates what appears to be a conflict – do principals own the use cases, or do end users own the use cases?

Mixing Interaction Design With Structured Requirements

One approach to resolving this conflict is to eliminate it by mixing interaction design with structured requirements. In this approach, the interaction design component applies end user ownership as an input to the design, but not the content of the use cases, as the following diagram shows:

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.

Interaction Design and Structured Requirements

This approach side-steps the issue by relegating the end users to “design input” and not allowing them to contribute to prioritization and management. For many applications, this is a great way to approach things. Specifically, it works very well when the user’s goals are tightly coupled or highly aligned with the principal stakeholder’s goals.

When Goals Conflict

User goals are not always aligned with stakeholder goals. In our earlier article on identifying these conflicts, we proposed a simple grid view for identifying these conflicts.

In that article, we looked at situations where the goals of the actor were primarily aligned with those of the principal stakeholder, and therefore the business. We discussed using the grid to inspire solutions that removed the conflicts. Two birds with one stone would be the easiest way to summarize.

What about when goals are implicitly in conflict – or even diametrically opposed? We’ve worked on systems where that is exactly the case. Consider a two-tier sales model, and products / websites designed for the people in the second tier.

Two-Tier Sales Models

Here are some common business models where the users have goals that are directly in opposition to the goals of the principal stakeholders.

• Automotive Manufacturer and Dealer. A website, designed by a car manufacturer, to allow dealers to improve their ability to sell cars. The automotive manufacturer makes money by selling cars to the end customer, and the dealer makes money by causing the sale to happen. The manufacturer is compensated by profits on the sale, whereas the dealer is compensated simply by making the sale. In other words, the dealer is motivated to lower the price because a sale at any price generates the same profit for the dealer. The manufacturer is motivated to raise the price because fewer sales at a higher margin generate the same profit, but higher ROA (return on assets) than more sales at a lower margin. This is an implicit conflict.
• Book Publisher and Book Retailer. A book publisher sets a price for sale to the retailer, and a suggested (list) price to the end customer. The retailer will typically pay a negotiated discount, in the form of a percentage off list, for the book. Any books not sold by the retailer are returned to the publisher or (usually) destroyed. The retailer does not have to pay for books that are not sold. The retailer has limited shelf-space, and makes money based upon a combination of the size of the discount and the number of books that are sold, regardless of publisher. The retailer is therefore incented to increase the discount, and thus increase profits for a particular title – and the publisher is incented to reduce the discount, and thus increase the profits for a particular title. Since the list prices are fixed, the retailer negotiates the discount, and as leverage over the publisher, gets to influence the placement of the book within the store. Each publisher is forced to compete with other publishers. These goals are also in conflict.
• High-Tech Equipment Manufacturer and Value-Added Reseller. A value-added reseller (VAR) provides solutions to end customers. They do this by combining products from manufacturers, and adding value – in the form of planning, custom engineering, installation services, etc. The VAR will negotiate a price with the end customer for a solution. The typical VAR sells products from multiple high-tech companies. The VAR will negotiate with the manufacturers to get the lowest possible prices from the manufacturers. The manufacturer wants the end-customer price (when it includes their equipment) to be as low as possible – to increase the number of sales that are made. The manufacturer gets the same profit (based on the price to the VAR) regardless of the end-customer price. Every dollar that the end-customer saves, the VAR loses in profit. The VAR makes profit on the difference between price-to-the-VAR and the final selling price. The VAR will also want to drive down the price it pays to the manufacturer. Reducing the price-to-the-VAR transfers profits directly from the manufacturer to the VAR. These goals are diametrically opposed.

When goals are in conflict like this, we can’t just relegate the “end user” goals to design inputs – we have to incorporate them into the prioritization process. In these examples, the “end users” are the VAR, the book retailer, and the automotive dealer.

Imagine that the high-tech equipment manufacturer sells networking hardware. The manufacturer has an internal (direct) sales force, as well as the VAR channel (indirect) sales force. The manufacturer identifies tools that help sales reps to close deals. Large purchases are commonly made at as much as 80% off list price. The list prices are irrelevant – they are not even guidelines in many cases. So the manufacturer develops tools to help sales reps know what prices to set for end customers.

Internal sales reps have generally well-aligned goals with principal stakeholders. The sales rep will be compensated based on a combination of revenue (sales) and margin (profits). This compensation model creates implicit alignment between the user goals (get a bonus) and the company goals (make profitable sales).

One approach to helping the sales rep close profitable deals is to share an indication of the profitability of the deal with the rep. The rep can (will!) set a price that is designed to maximize the sales rep’s bonus. If the compensation system is well designed – this is also optimal for the business, and therefore the principal stakeholder. The sales rep will get increased compensation for raising the price (and still closing the deal) by getting a percentage of the increase in margin. The sales rep is motivated to increase the manufacturer’s profits.

The VAR, however, should not know the profitability of a particular transaction. The VAR is motivated to lower the price (the price to the VAR) as much as possible – even at the expense of losing a “profitability bonus.” If the VAR is given a percentage of the increased margin (to the manufacturer) it comes at the cost of losing 100% of the change in price to the VAR. Remember, the VAR makes money on the difference between the price from the manufacturer, and the price to the customer.

Depending on the manufacturer’s business model, this could lower the priority of a margin-inspection capability, or dramatically raise the priority of features that restrict margin-viewing to only internal sales reps.

Also remember that the manufacturer and the VAR also have aligned goals – like closing the deal. And the VAR can close the deal with the manufacturer, or with products from a competitor. So the manufacturer is incented to provide valuable functionality to the VAR. The manufacturer cannot ignore the VAR’s needs, or the VAR will work with a competitor and the manufacturer will lose all the business.

You have to determine the value to the principal stakeholder of the value of the feature to the end user. In other words – even if a feature “hurts” the manufacturer, is the pain “worth it” because of the value of the relationship and expected future business that the company will do with the VAR?

Once the value of all of the functionality is identified, you can prioritize it. An enlightening way to visualize this value is with a value-delivery matrix. Thanks again to Roger Burlton for inspiring our approach to prioritizing based upon a combination of pain and gain.

A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.

Types of Stakeholders

Carl and John present a framework for understanding stakeholders that groups them into four categories – principals, end users, partners, and insiders.

• Principals - the business sponsors for a product or project. These folks have business goals they are trying to achieve. Your mission is to understand those goals. You also need to recognize that they may be moving targets, and be prepared to adapt to those changes. And we need to understand why they want what they want.
• End Users – the people who ultimately interact with the software. The best software development processes are focused on satisfying the end users. And a lot of authors are out there teaching us how to do that, although none perhaps as visibly as Alan Cooper.
• Partners - people who are neither principals nor end users. These are the folks who don’t directly benefit from your product, don’t use it directly, and didn’t help create it. But they are responsible for helping your product live, thrive, and interact with other products. Think IT people, keeping your system running, and keeping other systems talking to it.
• Insiders - the people who define the product. Your (internal) team. Not only product managers and developers, but business folks, marketers, testers, support staff, finance, etc. The people creating a product influence what ends up being created. And they are stakeholders in a narrow scope – they are affected by the creation and ongoing support of your product.

Outside-In Software Development: First Look

In the book, they go into more detail on the different types of stakeholders. One interesting thing that jumped out at me is something the authors mentioned about competing agendas for different stakeholders.

Support Or Not

Carl and John mention that end users have goals that usually, but not necessarily, are aligned with the goals of the principals. This makes sense – someone responsible for the ROI of an improved process would likely have some aligned goals with the person who uses the software within that process. Users are represented with personas, and those personas articulate goals – both personal and practical. This is one are of stakeholder goals. The user’s practical goals are (or should be) aligned with the goals of the principal responsible for the results of what the user does.

Tracing Among Goals

We use tracing to represent the supporting relationships between requirements artifacts.

The diagram above shows the general relationships between different types of artifacts. The following diagram shows how this tracing can incorporate the needs of users.

The top portion of this diagram accentuates that there is tracing within a requirement type. That is – goals can support other goals. From the perspective of stakeholder analysis, Carl and John describe it as alignment.

When we think about traceability, a good way to represent these aligned goals is through subordinate “supporting” relationships and traceability. Carl and John mention that the challenge is to identify conflicting goals and adjust prioritization accordingly (not all stakeholders are created equal!). This is great advice that resonates. The authors also point out that you need to be careful to not ignore a user goal that is critical to the achievement of a principal’s goal.
By tracking principal goals as corporate goals, and end user goals as practical goals, we can identify when goals are aligned (and supportive). We can also identify when goals are unaligned. This is exactly the visibility we need to address the two key elements the authors suggest we look at. Rewording into representation-centric maxims:

• Don’t ignore persona practical goals that support principal (corporate) goals.
• Question persona practical goals that are not aligned with principal (corporate) goals.

Conclusion

Outside-in Software Development continues to be a good read with good ideas. Understanding the relationships between the goals of principal stakeholders and end user stakeholders is one of those good ideas.

Using traceability to manage and communicate our understanding of those relationships will help us to make good decisions about supporting and prioritizing those goals.

Implementation continues on nexus, and we’ve re-factored the way that items in a bundle are ordered, as mentioned in our earlier post. We talk a little about affordance, and show a couple screen shots.

Drag and Drop Affordances

An affordance, to oversimplify, is an appearance of an object that causes users to intuitively know how to interact with it. We found a couple good articles on this challenge and posted them to nexus.

Drag and drop user interface elements are becoming more common on the web. The challenge is that many implementations do not make it obvious to users that the elements can be dragged and dropped. In the best case, users are missing out on powerful functionality. In the worst case, the user interface is frustratingly unusable. Here are the nexus links for the two articles we liked. Please read them, rate them, and comment on them.

• Drag and Drop Controls
• Drag ‘n Drop is Invisible to Users

Nexus Design Choices

The design decisions that we came away with from reading these articles were

1. Include a text explanation like “drag to re-order” so that people would know that it was an option.
2. Create an image that conveys the ability to drag to re-order the items.

Here are the screen shots of what we came up with for our first usable iteration on the task of re-ordering items in a bundle:

1. Two items, in order.

2. Dragging one of the items to re-order them.

3. The two items, in the new order.

The design element we created is a double-headed arrow, with some cross-bar lines that give it a tactile feel. When you drag one element past another, the second element moves into the space previously occupied by the first element. Screenshots don’t do it justice. It is really cool. Effectiveness will be determined by you – but I believe it will work.

The last step in our agile software development project was documenting our understanding of our users. In this article, we will define the personas that we will use to guide our design and requirement development. This definition of personas is built by combining our experiences in consulting, product and program management, and business analysis.

A couple other good articles on how to create personas:

• Leisa at disambiguity on the merits of creating personas.
• Practical persona creation at evolt.org.

In this article we define our primary, secondary, and supplemental user personas.

One of the main benefits of developing personas is that we avoid the “elastic user”, where we map characteristics to “the users” at our convenience. The risk of the elastic user is that we design part of the interface for an expert, and part of it for a beginner – all the while calling them “the user.” By defining personas, we can make sure that a particular design is well suited to an archetypical user, not an amalgam of ill-defined users.

Primary Persona: Jill The Business Analyst

Jill just got promoted to senior analyst at her firm. She’s on the road 4 or 5 days a week working with clients, and doesn’t have time to read a book in order to get one or two new ideas she can use. Her Blackberry is a lifeline to the people at her company – the reason she went there anyway is for the great people, and now she’s on the road working with clients all the time.

Jill is 28, lives in an apartment, her car lives at the airport, and she’s looking for the day when she can make partner and cut her travel down to every other week. She knows she has to grow the scope of her role to step up to the next level, and she’s focused on doing exactly that.

Secondary Persona: Paul The Product Manager

Paul is 43 years old and is one of 5 product managers at his company, and has half a dozen books scattered around his home in various stages of completion. He drives a hybrid Escape because he wants to help push environmentalism, but needs the utility of a larger car for taking his twins to soccer games. Paul is always looking for ways to make his company’s products better, and whenever he finds a new idea, the first thing he does is share it with the rest of his team.

Paul’s iPod playlist reads like the top-10 songs from Billboard in every genre – he doesn’t care what type of music it is, as long as it is best of breed. He buys blank CDs in bulk and is constantly burning mix-discs for his friends to help them stay on top of “the best” music.

Secondary Persona: Brian The Blogger

Brian had always been a little bit counter-culture, and was regularly frustrated with how his team was forced to run their development projects. He went to an Agile conference when it happened in his city, and began researching agile processes. He convinced his project and eventually his department to convert to agile approaches and he loves how it has changed his work environment, and his team’s success.

It is important to Brian that other people benefit from what he’s experienced, and he started a blog as a means to spread the word. He also uses the blog to foster communication with other people that push him forward in agile practices, which he then rolls back into his job. At 26, John is a big open-source advocate and contributes to a project that is building open source publishing packages. His blog also serves as one of the deployments of that package, allowing him to combine his efforts and passions so that he gets the most results from his efforts.

Supplemental Persona: Ellen The Program Manager

Ellen built her career as a project manager outside of IT in a large corporation, and loved helping her teams deliver great solutions. But she wasn’t enjoying the high percentage of time she spent asking people “how much longer?” and “if we change this, what will happen?” What Ellen thrived on was seeing how all the parts worked together, and knowing when something didn’t matter. She just moved, at 36, into a new role as a program manager on a team in IT, and now she gets to spend most of her time “doing valuable stuff.”

Ellen loves that she’s leveraging her big-picture understanding in her daily work. But she’s scrambling to get up to speed on the tools of the trade. There’s so much to learn. Ellen realizes that if the IT team can’t deliver well, their jobs will be outsourced (and she’s acutely aware of the negative perception IT has in the rest of the company). Ellen goes to lunch with the co-workers from previous departments (who her co-workers now call “the users”), because those folks are more real than her IT cohorts. This helps her stay “tapped in” to what people are actually trying to do – and when she needs to know something, she just calls a buddy and ask. Her great network is ready to be leveraged, as soon as she learns how.

Who Are You?

In an earlier post, the question was asked – who are the readers of Tyner Blain (presumed to be representative of the users of this new site)? In the poll below, please select which persona (if any) you feel helps to identify you. It may not be any of them, or it may be a combination of all of them. If you have a different approach or set of goals that aren’t covered above, please tell us about how you would approach a ratings site.

[poll=5]

Continuing the articles in our agile project case study.

The next step in our agile requirements management process is to develop an understanding of our target users. We believe a user-centric design approach is important. The user interface should conform to the way our users think about what they are doing and trying to accomplish. We should minimize the amount that we force our users to think like our software, and maximize the amount that we should force our software to work the way people want it to.

In this article we document some of the thoughts around who are target users are, and how we think about finding patterns in the way that they would approach using our product. This is a micro-example of market definition / segmentation. We’re looking for patterns that provide interesting commonalities. We’ll use this as a foundation for developing personas.

Starting with the classical breakdown of users…

Beginning, Intermediate, and Expert Users

This is the canonical breakdown of users – classification by level of experience with the product. We’ve written before about designing for competent users. And we also wrote an article focused on the need to help people bridge the canyon of pain from beginner to expert user.

All users of our site will start out as beginning users. And when the site first launches, all of our users will be beginners (except maybe some beta testers).

But none of them will stay beginners for long. They will either quickly become intermediate users, or they will stop using the site. Some people will also become expert users. But most of them will stay perpetual intermediates (as Alan Cooper calls them).

Domain Expertise as a Differentiator

We have another interesting dynamic with the site. All users will either be looking for, or promoting articles. Any given exercise will generally be in one of the topics we’ve identified in our scope document. A user can be an expert business analyst and be a beginner in interaction design. Or she can be a skilled product manager who is exploring business process modeling for the first time. Someone might have written hundreds of use cases, but be new to using UML to describe processes.

So we have an odd situation – people can be both experts and beginners at the same time. Everyone has a different pattern of domain expertise. Someone could understand market analysis techniques far better than go-to-market strategies. But in terms of a single set of interactions with the site, the user will be exhibiting one of their domain expertise levels.

So, any given interaction will have some combination : New User / Domain Expert, Intermediate User / Domain Proficient, etc. I don’t believe that domain expertise will affect how we design interactions for someone – it will only affect what the user wants to do.

User Needs: Initial Thoughts

As a first pass or pre-amble to developing user personas, here are some general ideas about articles that someone would want to find in a particular area as a function of their domain expertise in the area. The lists are numbered not to show relative importance, but to make it easier for people to refer to them individually in the discussion of this article.

Beginner

1. Find an overview of the area, to understand if it is worth exploring, or to help put the ideas in perspective with what the user already knows.
2. Find tutorials on how to do specific things, like “how to write a use case” or “how to faciliate a JAD session.”
3. Look for suggestions and reviews of tools that might help them to do work in the space.
4. Participate in discussions on good articles.

Proficient

1. Look for reviews of tools that might help them to do work in the space.
2. Read detailed articles that will serve as refreshers on how to do something, or improve their depth of understanding in a narrow area, like “estimating projects with use case points”
3. Share articles that would help beginners get up to speed – this is the bootstrap approach (you’ve learned it recently, you’re better positioned than an expert to help someone else learn it).
4. Share articles that are good additions to the toobox in a domain for other proficient users.
5. Participate in discussions on good articles.

Expert

1. Look for thought-leadership articles that combine or extend ideas in novel ways, like “goal driven documentation” or “combining interaction design and structured requirements” or “combining pairwise testing with use case scenario analysis.”
2. Promote articles that you have published elsewhere for community review.
3. Share articles with beginners and proficient users that you know to be very good – this is the ‘stamp of approval’ model.
4. Participate in discussions on good articles.
5. Create tutorials / lists / links that combine multiple good articles into informal “learning packets” that mix the best content from multiple authors on a single topic.

How You Can Help

Care to validate, refute or extend any of the lists above? Or suggest better ways to look for patterns in behavior or to organize users?

Its easy for us to overdo almost anything. Kim Goodwin offers some good advice about how not to overdo it when using personas as part of our software development process. Hat tip to Steve.
Personas

Personas are the representation of archetypical users of our software. They are used as a component in an interaction design approach to developing software. Start with our earlier article How To Create Personas for Goal-Driven Development.

Then check out Kim’s article about how to not overdo it (and good practical advice about what is important).

Thanks Kim for the great advice.

Actor Hierarchies give us an overview of the people who will interact with the system. We can extend this model to provide a visual indication of how use cases are distributed through the organization. Further, we can leverage a hierarchy to show how use cases are rolled out to the users – a targeted communication for our stakeholders.

Actor Hierarchy

A hierarchy is a model for representing the classification of things. The example we probably all learned first is the hierarchy of phylums, used to classify animals (dogs are a kind of canine, which is a kind of mammal, which is a kind of animal).

The hierarchy is a presentation of classification. Imagine that we were developing a GPS system for after-market addition to cars. As part of determining the requirements for our product we would want to identify the users of our product. In use cases, these users are the actors. We might identify casual drivers, taxi drivers, and couriers as the potential users of our product. What we need to do is organize these users in a logical way. We can use a hierarchy to do this.

All of the actors in the above diagram are “Car Drivers.” Some are casual drivers, and others are professional drivers. There are also taxi drivers and couriers, both of whom are types of professional driver.

If we’re using interaction design, we can build a similar hierarchy for our personas.

Mapping Use Cases To Users

We can create a simple table that shows how our targeted use cases map to our users. We can present the information in our table so that the hierarchy is evident. The pretty pictures above are cool and all, but harder to put in a table

Communicating A Delivery Schedule With Use Cases

The top of the hierarchy is Actors, branching into sales and accounting as two types of actors. With sales, we have a salesperson and a regional manager. Each column represents an actor, and the groupings of columns give us the hierarchy.

Each row represents a use case. We could put “X”s in each cell to represent which user can do each activity. We get more value from our document by populating each cell with the release-information for each use case (see the cited article on scheduling releases for details).

Evolving Use Cases

Yesterday we presented the concept of evolving use cases. We can use this approach to make communication of this evolution even more effective.

Imagine that we were evolving the Review Regional Orders use case to have an initial version in the Q2 release, and a second version in the Q3 release. In the first (Q2) release (of the functionality that enables the use case), we have all of the features needed by the regional manager. In the second (Q3) release, we add the functionality needed for corporate accounting to use the use case. The diagram above sort-of implies this – but it could be much more effective.

Our chart would look like the following:

The highlighted region shows that we are going to manage two different versions of the Review Regional Orders use case. Version 1 is released in Q2, and version 2 is released in Q3.

Summary

Actor hierarchies allow us to organize our use cases and understand how our users interact with the product. We can combine this documentation model with the concept of evolving use cases to provide powerful communication.

[Updated Below] There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?

Hat Tip

Joel (on Software) has an article where he lambastes the Vista team for providing 9 different ways to stop using the computer. Add in the hardware options on the laptop (like Fn F3), and closing the screen down or hitting the physical power button, and you get to 15 different ways to shut down.

Inevitably, you are going to think of a long list of intelligent, defensible reasons why each of these options is absolutely, positively essential. Don’t bother. I know. Each additional choice makes complete sense until you find yourself explaining to your uncle that he has to choose between 15 different ways to turn off a laptop.

Joel Spolsky

Make Everybody Nobody Happy

Joel posits that the unreasonable number has grown out of the desire to make everybody happy. We know that too many features makes everyone unhappy. This bloated list of choices is just one manifestation of too-many-features, and it doesn’t make anyone happy.

Inadvertantly Causing The Problem

It is pretty easy to imagine how we might inadvertantly cause this problem.

A structured requirements approach allows us to track and manage different requirements, as well as the implementation of those requirements. In Joel’s example, imagine requirements like the following:

• User secure the computer in order to walk away from it without other people getting access.
• User can shut down the computer such that it will stop consuming power.
• The computer will support rapid switching from one user to another.

Each requirement could drive an independent solution approach. As Joel points out, each requirement, evaluated in isolation, may lead to a different solution. The problem is that we are finding local optima, and not looking at the problems introduced by the complexity of supporting all of these solutions.

Avoiding This Problem

How can we avoid this sort of problem in our own product development? A holistic view of the proposed solution is required to assess if there are too many features. Prioritization of those features will help us reduce the number to a reasonable level.

Incorporating elements of interaction design into our solution approach may be the best way to do this (short of abandoning a structured requirements approach).

Each of the shutdown scenarios leads to a functional requirement. Each element of program design leads to one of the many ways to shut down or lock or restart the computer. Addressing the personal goals of each persona provides us with a cross-feature, holistic perspective. If our target audience includes Joel’s uncle, then we can make sure that our design approach accounts for the appropriate level of complexity and choice.

[Update]

Moishe Lettvin, one of the developers on the shutdown team for Vista, formerly at Microsoft, has written an article about the organizational and situational challenges faced by the team. He titled the article The Windows Shutdown Crapfest. That should give you a feel for how the now-Googler feels about the experience. There were 43 people involved, and they spent over a year. And the source code control system was frightening. Check out the comment thread on Moishe’s article too – it includes comments from other Microsoft and knowledgable anonymous people. Hat Tip to Scoble. Also, a followup from Moishe.
Summary

Multiple requirements can lead to multiple, locally-optimized solutions or features. A holistic view needs to be taken to assure that we aren’t introducing too much complexity with these variations of similar features. Interaction design gives us a big-picture perspective to make sure we aren’t making our software too hard for our target users to use.

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question – how do we gather implicit requirements?
Johanna’s Experience

Johanna describes the process of installing updated drivers for an all-in-one scanner/fax/printer. The installation process did not live up to her expectations. It took too long, caused additional inconveniences for her, and when she was done, the user interface was inconsistent with her other applications. In short, her expectations, her implicit requirements, were not satisfied.

How Could This Happen?

When we prioritize the requirements for, and creation of a new product, we focus our effort on the most important elements. We may even exclude everything but the most important requirements. We spend time and money on those things that create the most value for our customers (or at least maximize our sales).

Even with a Kano Analysis driven prioritization approach, we start with must-be requirements, then surprise-and-delight, and eventually more-is-better requirements. We may never get to “implicit requirements.” Even if we have the time to get to them – we may not have identified them.

This could have been avoided, and we don’t need a magic wand to identify implicit requirements.

Interaction Design Will Help

An approach to software development that uses interaction design is much more likely to identify implicit requirements. Like user experience disciplines (UX), interaction design focuses on the users. The interaction design approach starts with identifying the typical users, represented as personas, and documents and prioritizes their personal goals. This user-centric approach would probably identify the personal goals that would guide software designers to prioritize a consistent interface and pain-free installation. This approach is a powerful way to design products that don’t suck.

We could also use an approach that melds interaction design with traditional requirements approaches.

Making Traditional Requirements Work

The biggest challenge in addressing implicit requirements is identifying them. Once we identify them, we can conciously prioritize them. Prioritization is a function of ROI, but ROI requires user adoption (or purchase). Bad user experiences create bad marketing, prevent repeat business, and prevent future sales. This is the mechanism by which we prioritie them, once we identify them.

Eliciting Implicit Requirements

One way to identify these requirements is through observation. By observing users of the product (or a competitor’s product), we can get a perspective on how users interact with the product. This is also known as ethnographic research. We may still miss requirements – the competitor’s product may not push on the pain points that would fail to live up to expectations. Or they may identify pain points in the competitive product that present opportunities for us.

We can combine this observation with the use of prototypes. Prototypes can be used to document requirements, and they can even be used as the first iteration of an incremental delivery. More importantly, they can be used as a tool for gathering requirements.

Prototypes Uncover Overlooked Implicit Requirements

Prototypes simulate the product. Interacting with the prototype simulates interactions with the product. If we’ve done something wrong, or are about to do something wrong, a prototype will help us uncover it. We need to get feedback from the users (or people who match our target personas) about how the prototype meets and fails to meet their expectations. Other requirements gathering techniques can help us define the explicit requirements, and then interacting with the prototype will help us identify the implicit requirements.

Conclusion

Implicit requirements are real. And we have ways to uncover them. We can use interaction design as our approach. Or we can use traditional requirements techniques, and elicit the implicit requirements through prototyping and observation.

Michael Shrivathsan just wrote an article presenting five tips for creating products with great design.

Michael’s List

1. Start with the user interface. [Roger Cauvin adds, start with a working first iteration]
2. Work closely with UI designers.
3. Pay attention to details.
4. Simpler is better.
5. Be brave.

Our Thoughts

User centric design is the core of UX and interaction design. It is the most effective way to design something that is a pleasure to use. As Michael points out, almost no one does it. Kent Beck (founder of Extreme Programming) argues with Alan Cooper that all the up-front design work to understand the users is wasting time that could be used to build something valuable. Cooper argues that designing for the users is the most important thing. They are both right. There isn’t a black-and-white answer to that debate.

Simpler is the key to avoiding featuritis, where too many features actually make a poduct less effective.

Being brave. Great point. Great designs are product leaders. Many politicians try and predict where the population will be (test polling, trial balloons, etc), and then try to get there first – so that it looks like leading. Not very brave. Michael’s examples of the iPod and GMail are good ones. Both products demonstrate design departures from “everybody else.”

Our Additions

We would also add

1. Have Valuable Innovation. Innovation for it’s own sake isn’t worth much. GMail uses tagging (instead of folders) because it is valuable. Folders require every email to only be in “one place.” Tags allow emails to be in more than one place. That’s valuable innovation. [Here are ten tips for preventing innovation too - one of the most-read posts at Tyner Blain]
2. Focus On Killer Features. Prioritization drives the identification of what is actually important. Don’t do the other stuff. Combine this prioritization with Simpler Is Better to get the most bang for your buck.

Conclusion

Great ideas from Michael. Thanks!

Mike Mace provides us with some great insight about market research – helping us to avoid ‘the gap’ and ‘the blender’. The gap is a reflection of the inability of most customers to innovate. The blender is the loss of useful market information into a homogenized input that pushes only the lowest common denominator – again stifling innovation. We have to avoid the blender and the gap to get useful data from our research.

We know we need to base our product decisions on data, not opinion. How do we avoid the common pitfalls of misinterpreting the data.

The Gap

The gap, simply put, is the possibility gap between a customer’s perspective on what is and a product vision of what could be. Mike argues that customers are so focused on what is wrong with their product that they will respond with only incremental improvement suggestions. We won’t find innovative new ideas by asking customers what they don’t like about their current products. As a curmudgeon giving directions would say, “You can’t get there from here.”

The Blender

When surveying a large group of people, such as all customers in the market for our product, the feedback that we will see is that the items that get the greatest response are the items that get a response from the most people. The counter-intuitive notion is that these may be the least valuable features or capabilities. These only represent those things that are at least mildly beneficial to the most people – a lowest common denominator.

Mike points to the fact that the most successful products aren’t the ones that have bland, somewhat useful, wide spread appeal. They are the products that are loved by a minority. He uses the Blackberry and Treo as great examples – the vast majority of cell phone users have no interest in the features they provide. The minority that cares about email love both products – and both products succeed remarkably.

Avoiding The Blender

To avoid the blender-phenomenon, we need to get a more precise classification of the audiences in our target markets. Market segmentation is what we need to do. Mike points out that this is generally applied, and easy to do, when discussing existing markets. The SUV buyers, for example, were not a segment until after someone bought an SUV. The luxury SUV buyers weren’t a segment until someone bought a luxury SUV. So how do we define segments before segments exist?
Personas

By focusing on the creation of personas, we identify the personal goals that would provide useful segementation for a new market. When reading Mike’s list of three groups of cell-phone users, we can see how persona identification would have led us to a similar conclusion (emphasis mine).

When you do that with advanced phone buyers, three groups emerge. One group gives high ratings to all communication-related features — e-mail, instant messaging, built-in fax, etc. Basically, they’re communication junkies, and they’ll pay extra for a communication-enhanced phone. These are the people buying RIM Blackberries and Palm Treos today.

The second group gives high ratings to information-related features — large memory, document display, databases, etc. These are people in information-intense jobs who need a mobile memory supplement. Think of a doctor looking up drug dosage information on the go, or a lawyer trying to find a case reference in court.

The third group responds best to entertainment-related features: music, video, games, and other ways to have fun. These entertainment-focused users tend to be younger than the others, and don’t want to give up their electronic lifestyle even as they enter the job market.

Thanks Mike, for a great article!

Conclusion

There is an interesting point in this analysis – that for a product to succeed, it does not need to be perfect for everyone, it only needs to address the needs of a subset of people in the market. Several people have written that for a product to really succeed, it must be both hated and loved. We can interpret this to mean that a product targets one segment of the market (who loves it) to the exclusion of another segment (who hates it). Most people hate minivans, but the people who love them really love them. A persona-based approach to segmenting the market will help us identify these collections of like-minded individuals.

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.

Our proposed documentation approach is to write about what users are doing with the software, not what the software can do for the users. Using a power drill as an example, we proposed the following representative approach:

1. How to drill a hole in a flat surface (wood or plastic, metal, masonry).
2. How to select the right screw for fastening items.
3. How to drive screws (phillips, flat-head) with your drill.
4. How to stir paint with your drill.
5. etc…

Suddenly, the documentation is helping us to achieve our goals.

Extending Structured Requirements

When we use a structured requirements approach, we have established a framework for defining the problems that our software will solve. We articulate how people solve those problems with use cases. These use cases define exactly what we need to document.

When we view structured requirements, they look like the following diagram:

From Non-Functional Requirements Equal Rights Amendment

We extend this structure by leveraging the fact that the use cases identify the highest priority tasks that users will perform to achieve goals. These are therefore the highest priority tasks to document. The documentation represents how a user would achieve a use case, with the implementation that we’ve created.

We can even trace each portion of our documentation work to the use case that it supports.

Extending Interaction Design

With interaction design, we are again focusing on what people intend to achieve while using our software. Even if we are writing game software (which is designed to be played without a “goal” in the traditional sense), the user still has a goal of “being entertained.”

With interaction design, we would write documentation that demonstrates the way that scenarios play out with the given implementation that we created.

Even when combining interaction design and structured requirements into a hybrid approach, we still have a source from which to define our documentation needs – the scenario.

Summary

We’ve previously defined the benefits of documenting what users do with our software instead of documenting what our software can do for users. In this article we present a framework for defining and tracing that documentation – building upon use cases or scenarios. This documentation approach makes for software that is easier to use, and therefore better.

One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?

The Big Rule of Value

From our previous article, Writing Good Requirements – Big Ten Rules:

Pragmatic uses necessary as a criteria of good requirements. We believe that valuable requirements are good requirements. When prioritizing requirements, we should do the must-have requirements first. But other valuable requirements are critically important – even if they aren’t mandatory. Prioritization and release scheduling should stress necessary requirements first, and then the most valuable requirements next.

Requirements that can differentiate our product from the competition are by definition not necessary – or the competition would have done it already.

Valuable How?

Ultimately, we care about requirements that are valuable to us – they help us sell more software, more profitably.

We might sell more software by selling additional products to the customer. Our customer could become an advocate for our products, helping us sell the software to more customers. We could get a maintenance, subscription, or renewal contract. Or we might offer services that can be sold in conjunction with our software.

When we solve the right problems, we can sell our software for more profit.

Valuable to Whom?

While value to us is our ultimate goal, we sell software because it is valuable to our customers. There are two key groups we need to listen to, and one we need to ignore. We address the needs of the purchasing persona and the key user persona. We don’t let our salespeople have undue influence over our requirements.

Salespeople are correctly focused on a single sale. “Add this feature, and I know we can close this deal!” And a good salesperson is likely to be right about that. This, however, is a slippery slope. When we are writing an MRD we are writing market requirements, not customer X requirements. Salespeople give us input that is overwhelmingly driven by the influence of the current deal. Its possible that the salesperson is tapped into a single example of a market requirement. But it isn’t the salesperson’s priority to vett that requirement as one that applies to multiple customers. We have to do that.

The key user personas are the primary beneficiaries of our software. We are helping them improve existing processes, or we are introducing new capabilities that allow them to introduce new business processes. We help them in a way that helps their employer to make more profit. Since this is a market requirement, we need to validate that this problem is one that applies generally to our potential customers in the market, and not specifically to this customer.

A market requirement may look like the following:

Customers are waiting an average of five minutes for customer support when they call for assistance. We need to reduce the time that people wait on for support to an average of under a minute without adding support staff.

The supporting product requirement might look like the following:

Our best technical people are spending time on easy-to-solve problems, and our new-hires are wasting time trying to solve problems that they can’t solve. We need a way to make sure that our new-hires are not trying to solve problems they can’t solve, and our experts are not spending time solving trivial problems. We need a solution where new-hires solve >90% of all calls they handle, and experts only handle calls passed on by new hires.

In this example, the user persona is the call-center support staff member. The key user would be the new-hire. This requirement is valuable to them. The new-hire might have a personal goal of getting promoted. The ability to process more calls to resolution (by immediately rerouting hard problems) will help them achieve their personal goals.

The corporate goal of increasing the effective capacity of the team is also achieved. Our buying persona cares about this. And our buyer won’t buy if they don’t understand the value. A valuable requirement will be measurable. In this example, reduction of waiting time from over five minutes to under a minute is an easily measured market requirement. We can also easily measure that more than 90% of calls get re-routed, or that all expert-calls are previously vetted by the new hires.

How much value is too much?

Why did we set a goal of moving from over five minutes per call to under one minute? Why not under two minutes, or under ten seconds?

We’re dealing with a measureable goal that operates on a continuum. Most continuum-based goals operate under the law of diminishing returns. A reduction in time from five minutes to three is worth more than a reduction from three minutes to one. In our example, we have data that indicates that most people who will wait ten seconds will wait a minute. After we have asked them to wait a minute, more people become unhappy with the service with each passing moment. We have a data-driven utility curve that we can measure caller-happiness versus wait time. This gives us a good understanding of value versus wait time.

We also have to understand the cost function. Our engineering team, in this example, has studied the previous call logs and believes that we can achieve the one-minute mark by providing a solution that helps new-hires triage a call in ten seconds, and know if they need to forward it to an expert. To get the triage process under ten seconds, our engineering team has told us that they would have to build a system that automatically knows if the problem is easy to solve or hard. And this solution can involve voice recognition, or online-connectivity to the product being supported, or other cutting edge technological solutions. These clever solutions are also dramatically more expensive. This gives us a good understanding of the cost of solution versus predicted wait time.

By combining these two sets of data (benefit versus cost) we can produce a curve that tells us exactly how much is too much.

Making the tradeoff

Our customers will be willing to pay more for more value. However, they will have a target ROI or hurdle rate for making an investment in our solution. The cost axis of the curve becomes the cost to our customer for a particular measurement of the requirement (three minutes, one minute, ten seconds). The customer’s hurdle rate is tangent to the cost-benefit curve (representing customer cost and customer benefit) at the customer’s optimal point.

We should target this point for the requirement.

When Should We Get the Value?

We might not target this point for the earliest releases of our software.

In an incremental delivery process, we may prioritize a partial delivery of the feature in an earlier release. When scheduling requirements across releases, we start with a focus on the must-have requirements, and then introduce the more-is-better requirements.

In our example, we may choose to solve this problem with a database that provides keyword lookups for the new-hires, who can ask two or three simple questions, and then quickly identify the problems that are beyond their capacity to solve. This system might be designed to also log the solutions based upon the answers to the triage questions (allowing new-hires to solve more and more of the problems). In our first release, we might choose to implement the logging features. In the second release, we may include the ability for experts to input post-mortem results (to make the system get smarter over time), and in the third release, we may focus on entering data from the previous call logs, so that the system is sufficiently smart to allow for routing of more than 90% of incoming calls.

Conclusion

• Make sure our requirements are valuable.
• Make sure that the value is expressable to the buyers and ideally directly achievable by the primary users of the system.
• When developing requirements along a continuum, use data (not opinion) to set the target for the requirement.
• Prioritize incremental delivery of the functionality across sequential releases.

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”

It isn’t much different for most software users. Users don’t typically know what software can do, or don’t have the skills to synthesize software based solutions to their real problems. Users are rarely the source of innovative solutions. So how do we gather the real requirements?

We can make our user interviews much more valuable by talking to different users. We can use Geoffrey Moore’s Crossing the Chasm description of technology adoption as a basis for segmenting our users. Ken Norton proposes that we do exactly this, and combine the different perspectives to reach our conclusions.

Classifying Users

We use personas to identify different classes of users in a software system. We use those personas to drive feature prioitization and design decisions. When making design decisions, we focus on the level of competence of the users to prioritize features. When we are eliciting requirements, it is before we get to the prioritization stage, and we are still defining what the features might be.

We can use the same techniques to increase the value of our requirements elicitation efforts.

For any given role that we identify as a user of our software, we can use Geoffrey Moore’s classification to identify four distinct user archetypes (personas).

• Innovators (Influencers) – people on the bleeding edge of the technology curve.
• Early Adopters – our first customers.
• Majority – most users of our software.
• Late Adopters – people who follow the crowd.

There are pros and cons to interviewing representatives from each group. With Ken’s guidance, we can separate the wheat from the chaff and combine their inputs to drive innovative and valuable solutions. Our goal in these interviews is to understand the pain-points and market opportunities.

Innovators

• pro – Innovators can prevent tragically bad mistakes. They can also help us to identify opportunities to solve problems most people don’t realize are problems.
• con – Innovators struggle to distinguish cool from valuable. There is also a risk that they can fixate on something that is irrelevant.

Early Adopters

• pro – Early Adopters easily develop a deep understanding of our products and goals. They can tell us in advance what problems majority users will face, and provide a bit of a sanity check on the ‘problems’ that innovators suggest
• con – Early Adopters tend to be power users, and are genuinely enthused about our product ideas. They tend to gloss over the negatives and focus on the positives. They also tend to communicate in terms of features, not capabilities.

Majority

• pro – Majority users can give us the best insight into what is painful. We can use this insight to drive market requirements and solution ideas.
• con – Majority users don’t think about software, they think about how software affects them. We have to keep a focus on the problem not the solution when gathering requirements. We also have to dig deeper with why questions to understand the underlying cause of a particular problem.

Late Adopters

• pro – Late Adopters avoid change. Use them to help us identify where we need better interaction design and more documentation.
• con – Late Adopters will drive us towards “… just like product X” solutions. They will be disinterested in novel solutions until they are mainstream.

Triangulation

Ideas that survive the innovator-filter, make sense to early adopters, and solve a painful problem for the majority are the ones that we want. The late adopters won’t be using early versions of our software, so we can focus our attention on the other groups until we become the dominant solution. Then we can look to the late adopters to help us manage incremental improvements.

Thanks Ken for suggesting that we triangulate these perspectives into great ideas!

Conclusion

Even if we don’t go out in search of these archetypes, we should try and understand the people we do talk to, and put their inputs into the proper perspective.