dsp· by gregor hochmuth

Yes, No, Maybe so: Designing for Fuzzy

In Designing on 16 August 2008

Human language is inherently ambiguous. Luckily in most cases, we manage to make sense of it because of context, cues and other signals. But since language is ambiguous, our interactions are too — just wait for your next invitation to “lunch next week.”

Computers on the other hand are not ambiguous, never. Instead, they’re painfully exact. When building software, it’s tempting to carry their low-order strictness all the way to the top-level design — databases and schemas make that especially easy (and often quite enjoyable for logic-loving engineers).

But what happens when people interact with each other using such software? Their intended ambiguity needs to go somewhere but finds no binary equivalent; as a result, it’s often cast in stodgy facts and statements that don’t quite fit. That’s analogous to an image compression — once you saved the photo of a flower with a low quality setting, other people can still recognize the flower but it will communicate fewer subtleties and your impressions won’t match.

How can interfaces do a better job of accepting and preserving ambiguity? Consider the following examples that were designed with this need for fuzziness in mind:

Facebook: Poke or Send a Message? Poking may not be your preferred mode of communication but the fact that Facebook offers this non-verbal, fuzzy way of reaching out to someone shows that the site wants to support interactions that are closer to real life and not based on the formal metaphors of messages and inboxes.

Germany’s StudiVZ underscored the appeal of such alternative interactions when it included Poke as part of its cloned Facebook design from day 1 — the company even trademarked their translation, an “original creation” dubbed Gruscheln.

I’m Going, I’m Watching. Do you really want to commit to an event two weeks in advance? The team behind Upcoming.org knew that most people would prefer not to make such firm decisions, so they introduced the ingenious option of “watching” an event.

It signaled interest without making a statement about attendance and it also served to spread the word among friends by letting them track each other’s watch list. Together, these two aspects made “watching” much more meaningful than the dreaded “maybe”, which is used by Outlook (”tentative”), Facebook or Evite today.

Unfortunately, the wording of “I’m Watching” must have been too clever and Upcoming decided to rename this option to “I’m interested” in a recent redesign. It’s sad when interfaces lose their voice.

I’m Away. Poke was an example of an ambiguous action, Upcoming showed an ambiguous decision, and in this third example, the user can express an ambiguous state. Like other instant messaging clients, Skype lets users choose their current online status — most importantly, they can say to be away from their computer (”idle”) or even offline (”invisible”) when they aren’t.

The most notable counter-example I know is Google Talk, which only has two states that the user can actively choose from: Online or Busy. The limited choice makes the interaction more precise and dependable, but does it make users feel uncomfortable sometimes? Look no further than a tool like gAlwaysIdle for an answer to that question.

Why the Fuzz/y

Ambiguity is comfortable. It lets users avoid choice and commitment, saves them from picking the most appropriate option, and allows them to refine and override it later. Interfaces with these properties will always feel more comfortable, too… when they offer more than two choices, let us defer, refine and revert without a difference, speak our ambiguous language and treat errors as misunderstandings and not failures.

What other aspects in design support human ambiguity?

photo credit: Jeff Kubina