The Object-Verb Problem in Augmented Reality

I can see into the immediate future. It will consist of millions of people standing around looking at their phones. On their phone screens will be information regarding what they're looking at, and based on what verbs are provided to them, they will either be smiling in delight and pressing the appropriate button overlaid on reality, or cursing in great frustration, wishing doom upon the designers who tried to cram too much functionality into the next great augmented reality application.

While reading a recent article by Luke Wroblewski about the benefits of creating first-person interfaces, I had a realization that one of the most intriguing challenges we're going to have as interactive designers is dealing with verbs when designing first-person interfaces.

Use Cases, Not Useless Cases

What's the use of use cases? Oh, I can think of a few.

Say that you're creating a website for a client that sells pony dolls made from corn plastic. On the site, there are games for kids to play, and if the kids log in, they'll be able to save their high scores, post messages regarding their favorite dolls, create a public user profile, and other features that have yet to be dreamed up by your team. You've been tasked with designing the screens required for registering users for accounts on the site.

Sounds pretty simple, right? This is where designers usually can't restrain themselves from diving right into sketching and ideation and Photoshop and luxurious comps. Next thing you know, the client approves the designs, the project moves into development—and lo and behold, there are a few corner cases you hadn't acknowledged. A few whiteboard sessions later, a long discussion or two with the client, and those corner cases are starting to loom large over the entire design that is now been un-approved and is in the midst of rapid redo.

Even worse, the client is on the hook for making some major changes to their company's business process because those details weren't thought through in the design phase and implemented in a usable fashion.

Oops. Looks like you should have run some use cases, and right from the start.

Critical information always lies buried within the details of use cases. If that information isn't triaged and surfaced properly to the client and your developer, you can totally bollix a big project.

Redesigning Wikipedia

This weekend, I found myself—through the execution of what seemed like an easy challenge for my book—thrust into redesigning a Wikipedia page. In the process, I was dumbfounded by how many usability and visual consistency issues there are in the Wikipedia interface.

We spend a ton of time querying the Internet for details about everything from where President Obama was born to who directed the third episode of the fourth season of Buffy the Vampire Slayer. And more often than not, we're interested in the facts we're uncovering, not how the facts are presented to us. This is a shame, because there are major improvements that can be made by designers to how we present factual content that's meant to be consumed through the Internet.

Other sites, such as Usability Post, have done a thorough job of documenting a number of the major issues with the old interface, so I spent an hour correcting some of them in a visually pleasing fashion to show how, with a minimum of effort, a coalition of designers could rethink some of the key interactions on Wikipedia.

Hello, frog design

 

This July, I'll be making the leap to the Seattle office of frog design—as a senior interaction designer.

I'm very excited to be joining a firm whose work and legacy I've followed through my career. Their recent establishment of the publication Design Mind—as well as their devotion to engaging high-impact pro bono work alongside their always-stunning client projects—are borne out of a sustained commitment to design's pivotal role in industry and culture.

It's been quite a journey to arrive at this destination.

Thinking about Intangible User Interfaces

Apple's announcement on Monday regarding the iPhone 3G S, with voice control, represents more than just a way to manage your iPod state and dial phone calls in a hands-free manner. It's an important step in growing new flavors of user interface that are contingent on the intangible into the mainstream.

I'm not talking solely about Voice User Interfaces (VUIs), or the profession of Voice Interaction Design (VIxD), or the many small fiefdoms and associations currently blossoming around human-computer interaction governed by conversational speech systems. These are useful and important niches, but let's think big in our increasingly fractured and over-specialized profession of design.

Let me propose a somewhat radical alternative: roll Voice User Interfaces into a category that I'd like to dub the Intangible User Interface.

We have Graphical User Interfaces, which we know quite well from decades of struggling with operating systems. Our new friends, the Touch and Natural User Interfaces, rely on our physical bodies for operation beyond things like mice and keyboards. Intangible User Interfaces, however, would be a branch of interface that relies on everything but using your physical body in motion as an input mechanism. There's some wobbly semantics around the word "intangible," as it's often used to describe the attributes of a designed system that can't be visibly measured or quantified when observing users. However, it's that specific quality that I want to focus on: input and output contingent on what cannot be seen.

That Was Perfect. Can You Do It Again?

Web sites don't behave like nature on the back end, but the experiences we find most pleasing on the Web conform to a natural order: in the grids we use to constrain information; in the "weather" of how content flows into and out of a visual presentation; through each tiny interaction we initiate with the system and the expected reaction. As designers, we attempt to control as many of these variables as possible in order to ensure a consistent, desired effect on the user.

But sometimes it's just as valuable to let users follow a more chaotic, yet finite path. Elegant Web experiences walk a fine line separating simplicity (yawn) from chaos (huh?). And the rules that govern the quality of the attempt are derived from considerations of natural organization. This can still be elegant -- as long as the chaos is modulated within a stable container, constrained by a well-designed illusion of natural order.

Great Web sites have feel -- what Leonard Koren had called "heartfelt intelligence." And there’s a certain logic to how they manifest. When I was in high school, one of my fellow students devised a computer program that could write symphonies. The program followed "the rules" of how a symphony should be composed, and it turned out somewhat turgid music. That is, until the student devised a scheme in which the program randomly broke those rules. It turned out that there was a point of natural order between too few rules broken (rigidity) and too many rules broken (cacophony). When his program was dialed in, it composed an infinite number of superlative symphonies.

I have fond memories of playing drums for the first time with a top-flight band and record producer. The engineer would cue up the metronome and the entire band would play through the song again and again, attempting to finish a clean take. When we'd thought we perfected every single note on the Nth run-through, a curious thing happened. The producer said into the talk-back mic: "That was perfect. Now, could you do it again?"

Several more attempts at the material followed. Soon, we began to relax into the song again. Musical flubs and jokes passed between the performers. The song began to gain new life. After the session, I went into the control booth and asked the producer what he was aiming for -- and his answer was bold. While we'd performed the song exactly how we'd envisioned it, the arrangement had suffered because it was lacking feel. Feel only comes about when you tear away the illusion of perfection.

Intentionally Incomplete IA

This morning, I was re-reading the following paragraph in Clay Shirky's fantastic Here Comes Everybody while preparing for a user experience presentation:

In 1991 Richard Gabriel, a software engineer at Sun Microsystems, wrote an essay that included a section called "Worse is Better"... He contrasted two programming languages, one elegant but complex versus another that was awkward but simple. The belief at the time was that the elegant solution would eventually triumph; Gabriel instead predicted, correctly, that the language that was simpler would spread faster, and as a result, more people would come to care about improving the simple language than improving the complex one. The early success of a simple model created exactly the incentives (attention, the desire to see your work spread) needed to create serious improvements.

While Richard Gabriel’s argument is focused firmly on how users behave in developing programming languages, I think there are some great reasons to take a similar tack with our clients when we’re documenting and presenting information architecture for a large-scale website. By starting more simply at a high level, you’re assuring the right foundation is laid and creating opportunities to peel the excess away as you add complexity.

Withholding detail is a strategy. For consensus-building. For understanding how things hold together at a 100,000-foot view. For really sussing out what’s critical past stakeholder interviews in a real-time conversation with your key clients. As a way of gauging the temperature, there is sometimes value in iterating your information architecture in tandem with client input and data you’ve collected from your user studies. This way, after you’ve built high-level consensus around the core website structure -- when the client is nodding in agreement that you’ve got the big picture mapped out and that it reflects the needs of your users -- you can start to layer in the details, page by page, until everything finds its rightful place.

I used to be a total complete freak when it came to documenting information architecture, but over time, I’ve seen how this presentation strategy is one of the few ways to intelligently pare back the mega-long “features lists” that clients invariably bring into large-scale website projects. If you’ve got the time in your project schedule and can be agile about evolving your user experience recommendation, this can be a great way to collaborate through the front end of your information architecture. My preference is to start with a content map instead of a hierarchical site map, which helps things feel looser and more malleable on the page.

Otherwise, you may be choosing what flowers are going in the vase on the coffee table while you haven’t even figured out where to put the living room.

Doing Less with More: The Elegance of Denovation

Are you looking to create the next killer Web site or app? Perhaps you should start by denovating.

Elegant Web experiences mingle utility with a spirit of "denovation" -- a word from Jeremy Alexis, who defines the term as "the attempt to simplify or reduce the number of products without reducing the service performed. Denovation provides a clear path to elegance."

Successful Web sites and applications, well-tended by humans, naturally lend themselves to a denovative approach. You can shed unnecessary or cumbersome features and pages to create a firmer focus on a user's greatest needs. Much like pruning a tree in order to preserve its health, a site whose growth is managed in this way can maintain its systemic and formal elegance over time.

Web sites and apps need to evolve as user behaviors change. In this fashion, the Internet conforms to the same natural rules as humans because these billions of pages are created by humans and fed by humans. So if we view elegant Web sites as being organic in nature, then we can read "denovation" as a form of natural selection. Features whose level of use fall at the very far end of the long tail should be pruned.

Reducing features also has an added benefit: you gain more space in which to evoke positive feeling, not cognitive friction. Can you imagine if they did such a thing with, say, Microsoft Word? I think the overall level of anger in today's society would drop substantially...

"The Elegance of Imperfection" in A List Apart

The following essay is from a series of writings describing the intersection between Buddhist philosophy and design.

Many thanks to the expert editorial staff at A List Apart for their guidance, including Krista Stevens, Erin Kissane, and Carolyn Wood. Ric Ewing and Mary Paynter Sherwin contributed critical ideas and insights to the final piece.

 

Everything I know about the elegance of imperfection, I learned from the white porcelain plate I bought in Kyoto.

What’s so special about this plate? Before it was fired, it was perfectly round, but the artist intentionally roughed up the edges. It’s elegant, enhanced by anything that touches its surface: a bright green pear, roughly chopped chocolate, a pile of toasted almonds. Today, this plate sits on the desk in my home office. It symbolizes a crucial lesson about craft: utility is not contingent on perfection of form. In fact, the lessons I’ve learned about crafting elegant experiences—from the creative brief to user interface design—involve abandoning the desire for perfection entirely.

There is an anecdote, told and retold through translated Japanese literature, of a Zen master who is staying with a priest at a temple close to Kyoto. The priest is having guests over that evening, and he has spent much of the day in the garden—shaping the moss, plucking weeds, and gathering up the leaves in tidy arrangements, all in order to achieve the state of perfection the temple builders had originally designed...

Continue reading "The Elegance of Imperfection" on A List Apart

"'Experience Design' is a Bunch of Horse-s*$#" by Jon Kolko

This morning, I tripped over the following presentation by Jon Kolko (PDF) while reading through some of the blog coverage from Interaction'09.

Jon's presentation is one of the best articulations I've seen regarding why we should resist talking about how we design "experiences" for our clients, as opposed to interactions.

I know that many years ago, I would have been guilty as charged. Thankfully, I have now fully drunk of the IxD Flavor-Aid and can now be found browbeating my colleagues at work about how we can only reach so far into our audience's brains through our design deliverables...

"Carpe Diem: Attention, Awareness, & Interaction Design" by Dan Saffer

Here are the slides from the kickass keynote given by Dan Saffer of Kicker Studios at Interaction'09. This is the video that Dan references at the start of the presentation:

Interaction'09 | Day 2: How Should We Show Awareness?

This second day of the IxDA's annual conference was stellar. And I have few words to share, as I'm still processing the massive number of sessions that were crammed into the day. However, through the day, I copied down the following quotes from the presenters. If you've got your own favorites based on the sessions that you saw, add them!

Robert Fabricant, Frog Design

"Interaction design is not about computing technology. Technology is not our medium. Behavior is our medium.... Sustainability is a problem of behavior. Sustainability = our problem."

Nathan Moody, Stimulant

"Virtual keyboards suck."

Jon Kolko, Frog Design

"I saw this + I know this = Insight + design pattern = Design idea."

Michael Salamon

Instead of a quote, download his simple presentation about Gestalt at http://www.michaelsalamon.com/ixd09.

Camille Moussette

Speaking about how to put together haptic and multimodal interactions: "Use the world to control the world." Don't think you have to go digital to sketch out an interaction idea.

Dan Saffer, Kicker Studios

The real shining star of today's presentations, just because it was such a needed kick in the ass for our profession. Dan had a long, long list of the things that we can do to show more awareness as interaction designers. I hope that video of this keynote is made available. Some of my favorite quotes:

Stop looking for the magic bullet.
Instead of "design thinking," let's think and make.
Stop fetishizing simplicity.
Don't forget that for most, the interface is the system.
Stop waiting for permission.
You already know everything you need to know to design the future.

Interaction'09 | Day 1: Please Confirm or Deny Your Involvement

Do we deny the overall state of the world in order to create things that fit people's immediate lives -- thereby confirming their behavior and point of view -- or do we urge those people to change their behavior so they don't need those things at all?

This is one of the major themes I've seen boil up from my first full day of the Interaction'09 Conference: this consideration (or denial) of fit.

Spotted in Seattle: DC Web Stencil Kit

My friends over at Design Commission sent me one of these Web stencil kits for the holidays this year, and I'm totally hooked. You can now buy one of your own through their Web site for $19.95 + tax/shipping, which gets you a stencil, a pad of grid paper, and a mechanical pencil.

I'm looking forward to seeing what these guys are going to make for next Christmas. Perhaps an IA stencil?

Avoid the Architect's Fallacy

When we talk about the processes necessary to create a very large Web system, it will get technical. And when you're selling a Web system to a client that doesn't understand all things technical, it's tempting to make things simple. Just think of it in real-world terminology, like you're designing and building a house. Draw up the blueprints, hire the builder, pick up the wood from the Home Depot, and hammer it together with some contractors. Sign on the dotted line and we'll get cracking.

Well, that kind of analogy isn't quite appropriate for building complex Web systems, and makes things harder in the long run with a less sophisticated client. Sure, we have our information architecture and our wireframes, our technical briefs and database designs, our UI comps and our testing plans. But if we've done our job well, we haven't made a house. A Web system is an organism. A brochureware site that won't be touched for years is a tract home in Denver.

Please avoid this metaphor in your proposals. It makes it sound like you're just selling them a product. And you aren't.