Put usability in your Agile backlog

We’ve all seen it: waterfall projects that deliver the wrong thing, too late. So we understand the appeal of the Agile method, delivering working software sooner, so the intended users—our clients and their customers—can provide feedback that steers us to deliver the right thing. Agile reporting tools also help us estimate how long the work will take, which makes it possible to deliver on time.

But there’s a tension between delivering the right thing and delivering on time. And as a UX practitioners, we sometimes see usability sacrificed in the rush to release on time. This happens despite the first of the Agile Manifesto’s principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Valuable software is usable software, among other things. Data about what’s usable comes from testing. And much of that testing can’t take place until after the development—done in Agile stories—is completed and signed off. Development teams—consisting of analysts, developers, testers, usability researchers, and interface designers—often consider an Agile story to be completed despite the lack of feedback from the intended customers about its usability—or unusability. We can do better. Continue reading “Put usability in your Agile backlog”

Divergent thinking and collaboration

I watched an illustrated video of an illustrated speech by Ken Robinson on changing education paradigms. I believe the paradigm shifts he calls are also needed in the development process of software and information products.

In his speech, Robinson cites a study on divergent thinking—thinking in an unusual and unstereotyped way—which isn’t the same thing as creativity. Divergent thinking is an essential part of creativity. It is the ability to see:

  • lots of possible ways to interpret a question.
  • lots and lots of possible answers to a question.

Interaction designers engage in divergent thinking when they explore multiple ideas and try to “saturate the problem space.” Divergent thinking Initially, this exploration isn’t linear or convergent. Instead, it’s about trying different things, borrowing ideas, letting go of ownership and letting go of the idea that your idea is too good to edit or to combine with the ideas of others. Brainstorming is a structured form of divergent thinking. Only after the divergence—after the problem space is saturated with ideas—is it time to converge, to assess, to use judgement, and to make design decisions.

You can engage in a divergent-then-convergent process on your own, but for people new to the process, results are much better when they can borrow and combine each other’s ideas during the divergent stage. In the workplace this is called collaboration, and we need to add it to iterative, Agile development processes.

If development teams find collaboration difficult, it could be because of the paradigms we learned at school. As Robinson points out, the education system refers to sharing as copying, refers to re-using as plagiarism, and sees both as forms of cheating?

Although children innately engage in divergent thinking, Robinson cites a study from Break Point & Beyond that shows how our Return the fish to water ability to think divergently dries up as we pass through the education system. In school, divergent thinking is a fish out of water. At work, we need to put the fish back in the water.

It’s true. There’s a mismatch between what business leaders say they need and what schools teach, according to a 2009 Asian Development Bank publication, which reports:

What best demonstrates creativity?   (1 is highest) Business Schools
Problem identification or articulation 1 9
Ability to identify new patterns of behaviour or new combination of actions 2 3
Integration of knowledge across different disciplines 3 2
Ability to originate new ideas 4 6
Comfort with the notion of “no right answer” 5 11
Fundamental curiosity 6 10
Originality and inventiveness in work 7 4
Problem solving 8 1
Ability to take risks 9 (tied) 8
Tolerance of ambiguity 9 (tied) 7
Ability to communicate new ideas to others 11 5

In the table, above, compare where business ranks originality and inventiveness versus where schools rank it. Similarly, note the contrast between problem identification and problem solving.

Where to start? Sketching is one method that supports divergent thinking because a sketch intrinsically says: “As an idea, I am disposable. You can change me, or discard me, and then have more ideas.” Ideas are cheap, so have lots of them—that’s key to divergent thinking. There are people in your workplace who know this, already. People formally trained in design have been taught to use divergent thinking. Ask them for help. For other ways to learn to collaborate and to reward collaboration, an Internet search will identify many ideas and methods. One of the first things you’ll read is that collaboration requires support at all levels. Here’s a to-do list for executives:

  • Make sure the vision and mission are clearly communicated. This helps others to understand the problems to solve.
  • Remove the bureaucratic obstacles that strangle creativity.
  • Create a climate for an open flow of ideas, collaboration and knowledge sharing. Freedom and trust are key to creativity.
  • Embrace diversity. The more personality types (or team roles) are on the team, the more likely the project will succeed.
  • Give employees an opportunity to reap the rewards of the success they helped create. Stage celebrations to benchmark success.
  • Cultivate continuous learning. Revitalise by cultivating outside interests.

Testing in the UX-design process

Three weeks ago, a client called me. They had just completed release 1.0 of a new Web application that will replace their current flagship product. The client was asking about summative usability testing to evaluate how well the product performs in the hands of users, because they want their customers to succeed.

Since the product is an enterprise-wide product that requires training, one thing the client specifically asked about was whether the Help is a help to users.

Do you need help?A quick heuristic review I did turned up no obvious problems in the Help, so we decided on user observation with scenarios. In a preparatory dry run done a few weeks ago, I supplied a participant with a few scenarios and some sample data. The participant I observed was unable to start two of the scenarios, and completed the third scenario incorrectly by adding data to the wrong database.

The Help didn’t help her. The participant was able to find the right Help topic, but she completely misinterpreted the first step in the Help’s instructions.

The team had not anticipated the apparent problem that turned up during the dry run. Assuming it is a real problem—and this can’t be more than an assumption given the sample size of 1—this story nicely illustrates the benefit of summative testing, as you’ll see below.

Best practices working together

The team, including a product manager, several developers, a technical communicator as Help author, and me as a contract usability analyst, used these best practices:

  • The Help author used a single-sourcing method. The most common GUI names, phrases, and sentences, are re-used, inserted into many topics from one source, like a variable. In almost every Help topic, the problematic first step was one such re-usable snippet.
  • The product manager assesses the bugs based on severity and cost, ensuring the low-hanging fruit and most serious of defects get priority.
  • In a heuristic review of the Help, I (wearing a usability-analyst hat) did not predict that the first step in most topics would be misinterpreted. Heuristic reviews, when conducted by a lone analyst, typically won’t predict all usability problems.
  • The developers use an Agile method. At this stage of their development cycle, they build a new version of the product every Friday, and, after testing, publish it the following Friday.

After the dry run uncovered the apparent problem, the product manager said: “Let’s fix it.” Since the Help author used re-usable snippets, rewording in one place quickly fixed the problem throughout the Help. And the company’s Agile software development method meant the correction has already been published.

Was this the right thing to do? Should an error found by one participant during a dry run of upcoming usability tests result in a change? The team’s best practices certainly made this change so inexpensive as to be irresistible. With the first corporate customer already migrated to the new product, my client has a lot riding on this. I can’t be certain this rewritten sentence has improved the Help, but—along with the other bugs they’ve fixed—I know it increases my client’s confidence and pride in their product’s quality.

It’ll be interesting to see what the upcoming user observations turn up.

Reminding myself of things I already know

The actual user-observation sessions are still ten days away, but the dry run reminded me of things I already know:

  • Despite each professional’s best efforts, there will always be unanticipated outcomes where users are involved. Users have a demonstrated ability to be more “creative” than designers, developers, and content authors, simply by misinterpreting and making unintended use/misuse of our work.
  • The best practices in each discipline can dovetail and work together to allow rapid iteration of the product by the team as a whole. A faster response means fewer users will be affected and the cost of support—and of the rapid iteration—will be lower. A good development process adjusts practices across teams (product management, research, development, user experience, design, tech-comm, quality assurance) so the practices dovetail rather than conflict.
  • Summative testing helps validate and identify what needs to be iterated. Testing earlier and more often means that fewer or perhaps no users will be affected. Testing earlier and more often is a great way to involve users, a requirement for user-centred design, or UCD. It also changes the role of testing from summative to formative, as it shapes the design of the product before release, rather than after.