Tag Archives: Interaction design

Measuring Great Design – Mad Libs Input Form

image of mad libs pads

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.

Continue reading

User Goals and Corporate Goals

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.

Continue reading

Use Case Management is a Tough Balancing Act

balancing act

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.

Continue reading

APR: Persona Development

Creating Personas

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:

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

Continue reading

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

driver mirror

Interaction Design Process Overview

businessman on laptop

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

How To Create Personas for Goal Driven Development

Artist creating personas

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

Interaction Design and Structured Requirements

Borg queen

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

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

car mirror

Top Ten Tips for Preventing Innovation

Locked Door

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

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

Interaction Design, Explained By Alan Cooper

Harry Hamlin and Medusa

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

Prioritizing Software Requirements Across Releases

popcycle sticks

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

Product Management and User Experience

bee

There’s a buzz going around about the conflict and collaboration between product managers and user experience professionals. It started with a pair of articles co-written by Jeff Lash and Chris Baum. In short, with a user-centric view of products, both roles are responsible for the success of the user-interactions. Who makes the decisions?

Ultimately, since product managers are responsible for the overall success of the product, they are the final arbiters of what the product should do. A good market-focused product manager understands the market context and customer needs and makes appropriate decisions about features and functionality based on first-hand experience and all available research.

Jeff and Chris make a really good point, but note that they do not propose delegating decision-making to the UX professional. While this statement is certainly true, it reads as if there is an opportunity to delegate more.
Roger Cauvin wrote an excellent summary of the conflict and proposes a resolution that involves more delegation.

“A product manager frames the usability metrics… An information architect designs the user interactions and interfaces that will satisfy these usability metrics.”

We agree with Roger (mostly*).

Don’t Do Someone Else’s Job
They won’t do yours.

Very few product managers would argue about “back end” architecture decisions. The decision that the implementation team makes (say relational database versus flat files) is intuitively not a “Why” decision but a “How” decision. Why do product managers then get involved in debates about user interface decisions?

Do you argue for things like:

  • The user must be able to order their item with no more than two clicks.
  • The UI can not use a CAPTCHA to validate that users are actual people.
  • The information must be presented in a tree control.

These are implementation and design choices. Not requirements. They may be classified as constraints, because someone (the customer) mandates it – perhaps you are writing custom software for a company that enforces a style guide or other interface-guidelines. But they are not requirements. If they come from the customers, they are constraints – if they come from you (as a product manager or business analyst), they are “design ideas.”

Usability Requirements

This is a very difficult thing to do. Here’s how we would approach the examples above. Comment below with alternative suggestions, there are probably better ways.

  • The ordering process funnel (from decision to purchase until purchase has been executed) must have no more than 10% fallout (customers who initiate, but fail to complete an order).
  • (A) The user interface must prevent access by bots (automated external systems). (B) The user interface must meet accessibility guideline [insert spec here] for visually impaired users.
  • The hierarchical nature of the information must be presented to the user.

*This is the one area where we disagreed a little bit with Roger above. We completely agree with his view on responsibility, we just disagree on his (referenced) approach to documenting usability metrics.

Comparing Approaches

In the first example, we replace “two clicks” with a fallout metric. This is more aligned with our actual goal (high conversion), without specifying design. If the design had ten clicks, but they were compelling enough that people were not giving up, we would be fine.

In the second example, we specify accessibility criteria for visually impaired users (technically a constraint) and the requirement that automated systems not have access to the system. There are “audio captchas” that could work, and “interrogation systems” (pick the picture of a dog, what is 8 divided by 2, etc) that would not meet our true requirement.

The third example is more obvious – we require that hierarchical information be communicated. We don’t specify that it be in a tree.

Summary

The product manager should be just as “tapped in” to the customers as the UX professionals on the team. That doesn’t, however, mean that the product manager is as good at making user experience decisions. The product manager gets a veto vote, but should be very cautious in using it. Likewise, the product manager can veto the choice to use AJAX vs. Flash. That doesn’t mean he should.

Roger’s approach of delegating responsibility for implementation decisions (including interface design) is definitely the right one. The challenge is to define those requirements without specifying design or otherwise being arbitrary (like specifying a maximum number of clicks).

Also – even if you aren’t interested in the user-experience side of product management, the article starts with another great description of the product manager as the “president of the product.” It’s a good read.

Gathering Implicit Requirements

magic hat

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.