Surfing the Delta Wave

As somebody said, one of the biggest effects of mobile phones is that people do less planning ahead -- rather than "let's meet at 7:30 on the south side of Union Square near the bench", it's "I'll call you after I'm done and we'll figure something out."

That's a change in social interaction. It's vast, ubiquitous, and subtle. You probably do it yourself, and I'll bet you never really noticed the change. It just happened.

That's one of the things that makes mobile UX design work fun; you're working on things that really change the world. At the same time, you're part of the change, too. Surfing the delta wave is a job requirement.


I think it might have been Clay Shirky, but I wasn't able to find the original.

What usability testing doesn't tell you

Most people in UX have a pretty good grasp on what usability testing can tell us. But it's important to maintain an equally good grasp on what it can't tell us.

Let's say you have an idea for a new mobile application that lets you work with email in some new way, and you're thinking about how users might organize their email. Maybe you arrive at two options: organizing by sorting, and organizing by applying tags. You're not sure which to implement as the primary approach, so you do some usability testing.

The problem is that even if you're able to mock up a test application that presents your tagging idea, any population you find with email experience will almost certainly already have experience with using sorting to organize email. At the very least, the email systems they've used have employed sorting as the primary organizational method.

Now, I don't know (or at the moment, particularly care) whether sorting or tagging works better for organizing emails. The point is that the two things represent different underlying concepts of "how to organize". Usability testing is not good at testing underlying concepts. Established concepts are familiar, and although a new concept may have great advantages, it's often hard to understand them right away, particularly in the very abbreviated time usually alloted to a participant in a usability test. So the established concept is very likely to appear more usable in the test.

Usability testing doesn't inevitably reinforce the status quo, but it's something to watch out for.

When finished isn't done

The product of some processes of creation can be called "finished". A book, a painting, an automobile, for example, generally at some point reach the stage where they're done. The book goes to press, the painting goes to the gallery, the automobile goes to the dealer. There are many kinds of designs for a piece of software, from data to architecture to user interface, and most of them can be aimed at this kind of result. The specification is finished, and ready to be handed over to the developers, who implement it.

I think we should rethink this. Software developed in an agile approach is not really done as much as done for now. You reach a point at which you step back and take a look, or do some testing, or get some more experience with the product, and then you jump right back in and iterate it again. I think this works better for design too. It's the way design really works, but the corporate superstructure suppresses that in the interest of schedules, deadlines, time to market, promotions, testing plans, and the like.

The truth is that later iterations of the same design will almost always be better because there are things you just can't think of in the first iteration -- or even the first few iterations -- because you need the previous ideas in order to derive the later ones. Any piece of software or hardware product that's gone through a few generations of versioning is a good example of this. The new iPod shuffle takes all the controls off the player itself and locates them on the headphone wires. This was just as technically possible in the first iPod shuffle as it is today. Why didn't they do it? I think it's because it just wasn't possible to think of it before having experience with previous iPod shuffles.

Iteration is pretty central to design, and a pretty natural way for designers to think and work. It's really corporate processes we need to fight. A big ally is Agile; it produces results in software development and it seems to be leading to more iterative thinking at the corporate level. Designers should pay attention, and get on board.