Simpler software—software that is discoverable, easy to learn, and easy explain to others—frees its users to focus on tasks that add value. It may also frustrate former expert users as they suddenly find themselves less-than-expert users of the new tool.

If the software you’re replacing is so complex that it requires a dedicated group to mop up the errors of other users, then the impact of a very simple replacement is potentially disruptive. The users’ jobs are going to change.

The discipline of change management would advocate using a structured approach to transition individuals and teams to the new software, in a controlled manner, by following a pre-defined framework with, ideally, only reasonable modifications. But for an in-house UX-design team tasked with replacing a complex legacy system in one fell swoop, questions arise:

• How much workflow change is reasonable? How much process change is reasonable? How much is too much?
• How much organisational restructuring will a simpler system trigger? Who prepares the company’s other teams for significant change and possibly for job reassignment?
• Should any inefficiency be deliberately ported from the legacy system into the new system, merely to reduce the scope of change, for the comfort of existing users or to reduce the soft costs of workplace disruption?

In a business environment, where data—numbers—often have more sway than wireframes and design walk-throughs, one way to prepare stakeholders (that is, managers) for significant change is to test the designs and prototypes early and to measure their impact on user performance. User-experience designers and usability researchers then need to communicate their projections far enough in advance to permit the user groups to plan for change.

The connectors and attachments suggested this pump would fill North-American and European tire tubes as well as air mattresses, soccer balls, and basketballs.

But the thing is, neither the pump’s owner nor I were able to make it work. We couldn’t pump up my bike tires.

Was it me? Was it the pump’s owner? Or was it the pump’s design?

If the user can’t use it, it’s broken (…or it may as well be).

This year’s focus is on practical how-to methods for designing better user experiences on a budget. Speakers include Rahel Bailie of Intentional Design, one of two speakers who will discuss content-management strategy. Also on the speaker list: Kristina Halvorson of Brain Traffic, Lane Becker of Get Satisfaction, Nathan Curtis of EightShapes, Peter Merholz of Adaptive Path, Chad Fournier of Shaw Communications, and more.

Last year I was a CanUX speaker, presenting lessons learned while developing a method for designing with developers. This year I get to take in CanUX as a participant. Will I see you there?

Deliver working software frequently [in short sprints that last] from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

From discussions with other practitioners, I know that software teams can get dogmatic about the above principles, and often work in sprints of one, two, or three weeks in duration to ensure they deliver frequently. Since the classic software-development problem has been delivering the wrong features too late, I understand the desire to deliver working software frequently, with more frequent opportunity for customer feedback.

When the “deliver frequently” principle becomes a fixation, though, other things can get bruised in the rush to produce working software. Consider design and usability research. Sometimes a system’s features are complex and interrelated. Sometimes an elegant and simple solution is elusive. (Technical limitations can contribute to this.) Sometimes a weak design needs testing to make sure it is usable. To ensure design and usability work gets the time it needs, this work is often moved to preceding and successive sprints. This sets the designer and usability analyst apart from the rest of the team.

Here are my ideas to help design and usability work integrate better into short sprints:

• Ensure a designer understands the entire set of features before the first sprint. Ask for a broad-strokes design for the whole, and share it, so the team has a vision for the user experience. Before a sprint completes, compare the working software to the user-experience vision.
• Agile tries to keep the deliverable as simple as possible, but simple features from different sprints may not combine into a good user experience. This is a defect, to be fixed like any other bug, before the sprint completes.
• Ensure that usability and design bugs are resolved, by testing with users to validate the changes.
• When you need work done that substantially shapes the user experience but that is not related to a specific feature, regard this user-experience work just as you regard database, architectural, or other foundational work. Foundation work is easier for the team to prioritise when planning a sprint.

The above suggestions work within the “deliver working software frequently” principle. I have another suggestion that pushes at Agile’s envelope.

I think the words “working software” are too restrictive. In my opinion, there are other deliverables that are equal to working software, especially for teams that use very short sprints. A deliverable such as a paper prototype or a low-fidelity interactive prototype is equal to a piece of code, and allows team members—all team members on an Agile team—to focus on design, prototyping, and validation together instead of making a designer or usability work one sprint ahead or one sprint behind the rest of the team.

In one pair of light switches, the left switch controlled a lamp to the right, and the right switch controlled a lamp to the left. The previous resident’s solution to this poor mapping was to put a red dot on one of the switches, presumably as a reminder. I put up with that for about 3 days, and then it was time to fix the mapping.

Now, the left switch is for the lamp on the left, and the right switch is for the lamp on the right. That’s natural mapping.

If you want to read more about natural mapping, check out this blog about interaction design and usability. It presents a classic natural-mapping problem: on a kitchen stove, which dial controls which burner?

Meanwhile, at my home there are other problems with light switches, but they aren’t about mapping. In one case, the light switch is far from the door, so at night I must cross a dark room to reach the switch. In another case, the light over the stairs is controlled by two switches that are improperly wired, so both switches must be in the “on” position. If you guessed that one switch is upstairs and the other downstairs, you’re correct. To light the stairs, often I must run up or down the dark staircase to flip the switch.

All this is both amusing and irritating and, as I already said, a daily reminder that usability doesn’t just happen. To get it right, usability takes planning and attention during implementation.

Get the latest Flash Player to see this player.

I imagine the metal inserts in the wooden banister (see the video, above) are detectable warnings for people who are visually impaired, but that’s only a guess. If you watch the video again, you’ll see that the metal inserts do not occur at every bend in the staircase.

Whatever the intent, the banister fully met my needs.

A sudoku puzzle consists of nine 3×3 squares, sprinkled with a few starter numbers. The player must fill in all the blanks by referring to the numbers that are already filled. A number can only occur once in each row of 9, each column of 9, and each 3×3 square.

I regularly complete difficult sudoku puzzles, but this easy one—more starter numbers makes the puzzle easier—was taking much longer than I expected.

I soon realised that my slow performance was due to a design decision by the graphic artist!

In the original puzzle, shown at left, the graphic designer used  shading  for all the starter numbers. In my reformatted version, on the right, I used shading to separate the 3×3 squares. Both puzzles also use thicker lines to separate the 3×3 squares.

The shading for starter numbers, on the left, is unfortunate because it interferes with the player’s perception of the nine 3×3 squares. Instead, players perceive groups of numbers (in diagonals, in sets of two, and sets of five).

I assume the designer’s intention was to help identify the starter numbers. Regardless of the designer’s intention, the human brain processes the shading just as it processes all visual information: according to rules that cognitive psychologists call gestalt principles. A sudoku player’s brain—any human brain—will first perceive the shaded boxes as groups or sets.

In sudoku, the grouping on the left is actually meaningless—and counterproductive. However, since the brain applies gestalt principles rather involuntarily and at a low level, the grouping cannot easily be ignored. The player must make a deliberate cognitive effort to ignore the disruptive visual signal of the original shading. This extra effort slows the player’s time-on-task performance.

You can check your own perception by comparing how readily you see diagonals and groups in both puzzles above. On the left, are you more likely to see two diagonals, two groups of five, and many groups of two? If you are a sudoku player, you’ll recognise that these groupings in the puzzle are irrelevant to the game.

If you like, you can print the puzzles at the top, and give them to different sudoku players. Which puzzle is faster to complete?

Interested in gestalt principles? I’ve blogged about the use of gestalt principles before.

One thing I’ve noticed is that about ¼ of seatback touch screens are poorly registered. By registration I mean that the system and the user agree on where the user is tapping or touching the screen:

I recorded a video of two common tasks for a seatback entertainment system: selecting the language and adjusting the volume. As you can see, the registration is off, so I initially get the French interface instead of the English, and I must press an unrelated button to adjust the sound:

Get the latest Flash Player to see this player.

The registration error is significant. My fingertip tapped about 2 cm left of the centre of the EN button. The larger the registration error, the harder to tap a small target—as was the case with the volume controls in the video, above, where I appear to be tapping the Fast-Forward button. On more than one flight I have unintentionally increased the sound to painful levels while attempting to lower the volume!

A system such as this could be made to detect and auto-correct poor registration. If we assume that repeat taps on a blank location indicates poor registration, the software could:

1. After several repeat taps, select the nearest target—a reasonable guess—even if it is a centimetre or two away from the user’s tap.
2. Ask the user to confirm the guess. “Did you mean [this one]?”
3. If the user confirms, calculate the amount by which to correct the registration, and then fix the registration error.

This solution requires a screen—perhaps the start screen—whose choices are spaced far apart, so the system can detect when the user appears to be tapping a blank space:

If user testing were to show that auto-correction needs human involvement, after calculating the registration error, the system could ask the user to check the corrected registration. For example:

Are you there? Please tap the green circle.

I haven’t done any testing of this idea, nor have I given this much thought, so I’m certain there are many more and better ways to auto-correct a registration problem on a touch screen. I merely wanted to identify one possible solution in order to get to the next point: the need to consider the business drivers when deciding to address (or deciding not to address) a usability problem.

Everything costs money

Fixing this problem—it’s a real problem, you’ve seen the video—would cost money. If the following can be quantified and evaluated within a framework of passenger-experience goals, there may be a convincing business case:

• Not every passenger can work around a registration problem. Those who cannot would be unable to use the entertainment system. When everyone else gets a movie, how does the passenger with a failing system feel?
• If a failed entertainment system is perceived as a negative experience, will passengers blame the touch-screen/software manufacturer or blame the airline? I’m sure you can imagine the complaint: “I sat there for hours without a movie! It’s the airline’s fault.” What’s the likelihood that this will cause churn (passenger switches to another brand next time)?
• Based on the screens I’ve seen, some frustrated passengers must use hard objects that scratch and even gouge the touch screen. Are they trying to force the screen to understand what they want? Are they vandalising the screen? What’s the cost of replacing a damaged or vandalised screen?
• A scratched screen is like graffiti. It affects every subsequent passenger in that seat. Do vandalised screens affect the airline’s goal of attaining a particular passenger rating for perceived quality or aesthetic experience?
• The in-flight entertainment system was implicated in a catastrophic Swiss Air crash near Peggy’s Cove about a decade ago. Would a fix to the touch-screen registration problem incur prohibitive safety-testing costs?

My first exposure to agile was in Desiree Sy’s 2005 presentation, Strategy and Tactics for Agile Design: A design case study, to the Usability Professionals Association (UPA) annual conference in Montreal, Canada. It was a popular presentation then, and UPA-conference attendees continue to be interested in agile methods now. This year, at the UPA conference in Portland, USA, a roomful of usability analysts and user-experience practitioners discussed the challenges that agile methods present to their practice. One of the panellists told the room: “Agile is a response to the classic development problem: delivering the wrong product, too late.” There was lots of uncomfortable laugher at this. Then came the second, thought-provoking sentence: “Agile shines a light on the rest of us, since we are now on the critical path.” Wow! So it’s no longer developers, but designers, usability analysts, etc, who are holding up the schedule?

During this week’s training, I’m learning lots while looking for one thing in particular: how to ensure agile methods accommodate non-developer activities, from market-facing product management activities, to generative product design, to early prototype testing, to usability testing, and so on.

I’m starting to suspect that when agile methods “don’t work” for non-developers, it’s because the process is wagging the dog (or that its “rules” are being applied dogmatically). I think I’m hearing that agile isn’t a set of fixed rules—so not a religion—but a sensible and flexible method that team members can adapt to their specific project and product.

Environmentally defensible. It is made primarily of a renewable resource—wood—and is so durable that, after decades, it still withstands daily use.

Functional. Originally, at BC Tel, this chair fit a small space, swivelled so the operator could get in and out of a small workspace, and provided a place for the operator’s personal items. After it was decommissioned, this compact and strong chair continued to be functional in other settings.

Aesthetically appealing. I’m thinking of the wood, the form, and the chair’s history. This chair has only marginally been repurposed, because it still seats people as they connect to a telco service—formerly a telephone, now Internet access.

Can we still design objects that last as long as this chair has?

Get the latest Flash Player to see this player.