ChangeOrder

Thinking Outside the Elephant: Part 2

This is the second part of a recap that was written over 51 hours at the HOW Interactive Design Conference, then delivered to attendees as a 45-minute closing talk. Read the first part here.

Now, for those of you that know me, I have a penchant for pushing analogies to their breaking point, until they become so absurd that they start to resemble reality. So I'm going to start visualizing for you what kind of world our elephant lives in, and what might be stressing her at this very moment.

Thinking Outside the Elephant: Part 1

This is the first part of a recap that was written over 51 hours at the HOW Interactive Design Conference, then delivered to attendees as a 45-minute closing talk. The second part will appear on Tuesday.

During the first day of the HOW Interactive Design Conference, I was having a conversation with Richard Hassen of To the Point Design Studio about the challenges that designers with deep expertise in print are having adapting their skills to interactive design. He said: "How am I going to bite into the elephant? It's just too big."

I loved his analogy—that acquiring the necessary interactive skills to be successful in our careers was equivalent to chowing down on a elephant, spoonful by spoonful.

What's inside this elephant? Us, of course. Then tools, clients, technologies, frameworks, methods, you name it. And this is a baby elephant, not a full-grown elephant, since interactive design is much younger than the disciplines of industrial and graphic design. (Baby elephants are still heavy, mind you.)

Based on Richard's analogy, I felt obligated to thinking about just what we were trying to eat. What follows are the four top themes from the conference that describe our proverbial elephant, and further thoughts about what forces are being exerted on our baby elephant, out there in the world.

Slides from "Information Architecture: Making Information Accessible and Useful"

The above slides are from a talk I just gave at the HOW Interactive Conference in San Francisco on November 2nd, entitled "Information Architecture: Making Information More Accessible and Useful." The talk was about how designers can help people make use of information—both find and act upon it.

The core metaphor of the talk was centered on a recent trip that I took to the SFMOMA to see a career retrospective of Dieter Rams's work, whose ethos of "Less, but better" is a challenge to any designer seeking to create better websites and applications. (Go see this exhibit!)

I re-explore this trip multiple times over the course of the talk, considering the overlap of information in physical and digital systems—and how conceptually we merge them.

From there, I provide best practices and principles for how to approach information architecture and user experience design in a more iterative, agile fashion through in-line prototyping.

Slides from "The Language of Interaction"

I was recently invited to deliver a talk at Emily Carr University of Art and Design about what interaction designers do and how interaction design factors into the worlds of design and art.

My talk "The Language of Interaction" (slides above) was my attempt to summarize the critical role that language plays in our efforts as designers and artists. In doing so, I touched upon the three challenges that all designers and artists face in trying to craft interactions:

• Establishing a vocabulary, which allows you to articulate what discrete points of a systemic problem you may influence
• Considering what metaphors may aid you in the modelling of an interactive product or service
• Understanding how we weave together what we've experienced from our interaction with lateral disciplines to become better at practicing interaction design

To illustrate the last point, I created a timeline of my lifelong explorations as a designer and artist, and discussed how I couldn't have been an effective interaction designer without traveling through a range of related (and seemingly unrelated) disciplines. Over time, all of them were threaded together.

Many thanks to Haig Armen and Laura Kozak of Emily Carr, who invited me up to Vancouver, BC for this talk.

Why I am a UX Designer

This was a long time coming, especially after:

Why I am a Designer
Why I am a Print Designer
Why I am a Photographer

Can You Vote for My 2011 SxSWi Panel Idea?

The Panel Picker has gone up for next year's SxSWi conference, and I'd appreciate it if you could stroll on over and vote on my proposal for this year, which is a new talk with a different take on how interactive designers, developers, and UX professionals can come up with better ideas faster—specifically in the design of interactive products, services, and systems. Here's the abstract:

 

Better Ideas Faster: Effective Brainstorming for Interactive Design

You're under the gun. Again. Only a few days to come up with a revolutionary new feature for your Web app. Or you've been tasked by your boss to give the company's new mobile experience a little more oomph. Or you're floating in the space of a nebulous client problem that you just can't seem to pin down.

In these situations, it can be hard to focus on coming up with breakthrough ideas. But don't worry—help is to the rescue. David Sherwin from frog design, a global innovation firm, will share tools and methods that any interactive professional can use to more consistently brainstorm quality ideas for interactive products and services. This presentation will be illustrated with examples from frog's interactive work and David's new book Creative Workshop: 80 Challenges to Sharpen Your Design Skills (HOW Design Press).

Questions Answered

1. How can I best structure my brainstorming time for success?
2. What lightweight brainstorming techniques can I use that will inspire new, more innovative design ideas more quickly?
3. How can I be more effective in moving from project discovery to generating targeted design ideas?
4. How can our team collaborate best across disciplines to rapidly iterate any type of interactive experience?
5. How can our team best synthesize a wide range of ideas into a set of compelling client recommendations?

You can vote on the panel here. Thanks for checking it out!

Slides from "Designing the Design Problem"

Thanks for everyone who came out (virtually) to see my presentation yesterday at Creativity Oklahoma's online conference on applied creativity in art and design. Scott Belsky did a great job of describing the philosophies behind Behance and the research about how people make ideas happen that became the foundation of his bestselling new book.

While Scott was talking about fulfilling creative projects, I took a different tack and provided methods that frog uses to marry our innate skills in creative problem solving with the evolving practice of "problem making" to better serve both clients and users in crafting compelling products, services, and experiences. As a case study, I shared research data and insights that had been part of frog's initiative to encourage HIV testing in South Africa, Project Masiluleke.

This 20-minute presentation was carved out of a longer work I'm putting together regarding the specific kinds of activities that make up what's called "multi-vector research," which is the secret weapon for any design team that is trying to tackle a complex and systemic business problem or world problem and discern what exactly should be designed to influence it for the better.

Patient User Interface

Sitting down in the naughahyde dentist's chair, I was confronted by the following screen:

In this blurry iPhone photo, you probably can't see the details of the UI, so I'll briefly describe them.

At the very top of the screen, the dental technician could select from a series of options, such as activities, lists, orders, and utilities as a set of dropdown menus. (You can also tell from the "chrome" that it's running in Windows XP.)

Below that, you can see that the entire user interface consists of a reflection of the room that I was currently sitting within. By clicking on the various areas, around the room, you could access my chart (by clicking "CHART") or the screen in the bottom right ("Patient Information"). And the buttons running along the top of the screen are repeat links to those same verbs that are woven through the room.

"I have to ask you," I said to the dental technician before she settled into the cleaning, pointing up at the screen. "Do you enjoy using this?"

Making Design Research Less of a Mystery

There are a few eerie similarities between the plotting of mystery novels and how designers should document design research findings.

Design, Disruption, and Drunk Usability Testing

I held the drunk man's hand like a dance partner at a debutante ball, sashaying our way towards the front door of the Collins Pub.

We had both been at the Seattle Matsuri, a two-hour "all you can taste" exhibition of sakes that would be hitting the American market soon. At the event, most of us directed the delicious sakes from each brewer's bottle from our mouths into the handily-provided metal spittoons, thereby avoiding imbibing dozens of ounces of these potent wines and the fallout possible therein.

Then there were fellows like this man—whom we shall call Jeff, to protect his identity—who chose to swallow from each glass a bit too liberally. Upon running into him on the street after the event, he seemed quite lucid. But as our party sat down at the pub, desperate for a late dinner of burgers, fish, and chips to counter the onslaught of wine, you could see the power light draining right out of his eyes, his speech slurring from complete sentences to fragments. When he announced that he needed to get outside to wake up a bit, his attempt to stand up caused him to flip another table and fall to the ground in a mixture of both bewilderment and humiliation.

Sitting outside with Jeff for a little fresh air, we chatted haltingly about where he lived and what he did for a living, all the while demurring the advances of the usual Pioneer Square drug dealers offering cut-rate deals on stimulants and muscle relaxants. (Seriously, does this guy look like he needs a muscle relaxant?) But our real adventure began when he said the following: "Let's call my wife. She can pick me up."

First, we had to find the phone.

Interaction 10: A Take-Home Quiz

 

Identify the following statements as True or False. Show your work.

1. All design is the process of making experiences.
2. The next economy is not a utopia. It is here today, growing in the framework of the old economy.
3. We can optimize the stories that users tell themselves as they use a product.
4. Interactive products that take on human qualities fail when the qualities sentience, intimacy, and personality fall into the uncanny valley.
5. The future is tomorrow, not just an ideal outcome or fantasy world we should design for.
6. No two individuals will have an identical experience.
7. Search is a wicked problem.
8. Interaction design can also be art.
9. Physical spaces carry cognitive loads. (i.e. Ask, "What is the cognitive load of a street?")
10. A customer experience can be defined and designed by mapping both the tangible and intangible portions of a provided service.
11. We can add meaning to physical objects beyond what is tangible to users.
12. We don't need to define user experience in order to measure it.
13. Designers manipulate the audiences they are intended to influence.
14. Designers have a responsibility for how they manipulate users.
15. An experience cannot be built for someone… one has an experience, and that is experience is always unique.
16. Almost all design disciplines are a facet of the discipline of interaction design.
17. Polite interfaces garner praise.
18. Consumerism isn't dead. But it needs to be.
19. If [a designed artifact] is not ethical, it cannot be beautiful.
20. Act like a design thinker, but think like a design activist.
21. Usability metrics can't function as key performance indicators for your clients.
22. All design is the process of evoking meaning.
23. Do not consider people as passive users or consumers.
24. Approach your designs from an impressionistic perspective.
25. Always have a systems perspective when designing products or services.
26. Instead of being a design leader, consider the importance of design influence—promoting design throughout your organization.
27. Understanding emotion improves the experience of emotion.
28. The future of our profession is the design of enabling systems.
29. To be an interaction designer, you need to be: A. Born to hippie parents; B. Have (or verge upon) OCD tendencies; C. Possess a compulsive urge to fix broken things (not the same as OCD); D. Possess a sense of humility bordering on the pathological; E. Be shy or geeky, but methodically so; F. All of the above.
30. Website copy is a monologue. It requires an authentic tone of voice to be effective.
31. Clients don't see the invisible. It's hard for clients to acknowledge, prize, and value the intangible.

32. Creating explorative, playful spaces moves users from passive to active engagement.
33. Don't overthink what you design.
34. Every crisis also provides an opportunity for meaningful change.

 

All quotes and paraphrased content from my notes and live tweets of speakers at the Interaction 10 Conference in Savannah, Georgia. Bonus points if you can identify whom said which statement.

Reducing the Variables

It's eleven in the evening, and the energy rush provided by the soda and pizza has begun to wane. The whiteboard is full of sketches detailing dozens of solutions to a particularly thorny piece of website functionality… but none of them seem to fit the client's need perfectly. The whole team is exhausted, but there are still at least twenty yards to sprint until the ideas in our minds make sense in some sort of material form.

When you're trying to solve really big UX problems—ones that hundreds of other designers have probably expended thousands of hours considering—you'll spend a good deal of time retreading similar ground to those of your peers. It's tempting to choose what seems like the most appropriate large-scale solution based on what you've seen out in the market, then fill in the details as you go. In some projects, that's the right approach to take.

But in these kinds of situations, it's very important to ask yourself: Am I trying to uncover some capital-S "Solution" to a big problem when actually I should be taking a series of small steps towards a subtle, more constrained approach? Am I pursuing the holy grail blindly instead of determining my path, each step forward, as I move towards that same big solution?

Often, you need to take each of those short steps, or iterations, before your smaller solutions add up into one that feels big (and appropriate). So if the task before you seems insurmountable, and you're totally stumped, change the problem's constraints. Throw out larger concerns, at least in the short term. You need a smaller box, and fewer variables to solve for (at first).

The Blind Man and the Cheeseburger: Form and Interconnection in User Experience Design

Have you ever watched a blind man eat a cheeseburger?

Before I skipped town for the holidays, my wife and I tried out a new sandwich shop down in the Ballard Blocks. After ordering and sipping at our iced teas, I noticed that the man next to me, distractedly chatting away with his family, had a folded white cane by his side. The waitress set down his gourmet burger, including sweet potato fries with aioli on the side. Out of the corner of my eye, I couldn't help but watch as he ate.

First, he patted with his left hand to find the top of the burger. He used his right hand to enclose the bun and patty. Slowly, he brought it to his mouth for a bite. Freeing up his right hand, he patted the plate for fries and ate three. Resting the sandwich, he then fumbled a bit before acquiring his beer and taking a healthy sip. The worried expression that had consumed most of his face during those first moments of eating had turned into a smile of deep satisfaction.

Between the beer, the burger, and the fries, he was continually reacquiring the position of each object in relation to his hands and his mouth. As he grew comfortable with the position and taste of each thing, he started to become more adventurous. Those first savored bites turned into a messy ballet. He began dipping the burger into the aioli for the fries, which required holding the stainless-steel ramekin. He also couldn't control how much of the sauce ended up on the burger (which ended up daubing his chin). As he finished the fries, he moved his hand around the plate in a clockwise motion to locate those last stray, delicious tubers. And he carefully managed how much was left in his pint of beer, so he could chase the last bite of the burger with a healthy swig.

As our waitress left our burgers in front of us, I couldn't help but reflect on how I would eat my impending meal, and what elements truly composed it.

We could talk here about the latent usability of the cheeseburger, but that's an easy argument to wager. If you suffer from a visual disability, of course it will cost you more time to fulfill the same interactions over the course of a meal. We've felt the very same feeling in using a poorly architected website, where we fumble about for minutes for what seems, in our minds, to be a very simple goal: match the idea in your head to what's on the screen. You need the food in your hand before you can put it in your mouth.

Since I could see all of the ingredients on the plate before me—and understood how they all fit together into a set of graspable objects—I could plan out at some level of detail how I would eat them, from first to last bite. It took about twelve minutes for the blind man to eat his burger, while I could make mine vanish more quickly.

Those are nice things, if I care about being more efficient, not getting ketchup on my sleeve, or admiring how the dark diagonal burn marks demonstrating how our veggie-burgers had been char-grilled.

Since I can see the cheeseburger, there must be some added meaning to the food that changes my perception of how it tastes. There's also the notion that slowing down the eating process, whether through self-will or eating in pitch darkness a la Dans le Noir, causes us to appreciate the nuances of what we taste. That environment may force you to acknowledge taste without the influence of sight, but how I understand the notion of "cheeseburger" or "fries" in that environment, as I consume them, is no better or worse than the blind man as he reaches for what comprises his lunchtime meal. Even if he and I are splitting the same cheeseburger, it will never be the same cheeseburger.

Separating the Why from the How

When deep in discussions with a client over wireframes for highly complex systems, I've developed a simple way of defusing discussions regarding aesthetics:

Wireframes are the why. Visual design is the how.

If a client disagrees with why a specific bit of functionality is on the page, or has concerns regarding the types of content described in your documentation, then you're having a productive discussion that will contribute to the quality of the end product.

However, if you expending a substantial amount of energy describing how that functionality will be expressed, you have an option to recommend the following:

"In this meeting, we are looking to confirm that we've included the appropriate functionality, and determined its use for your customers/users in the right contexts and task flows. Upon approval of these wireframes, we will show you how that functionality will manifest to the user in a UI design on [deadline/date]."

Separating these two activities can help you move your functional ideas more swiftly into back-end development, and afford your visual designer a bit more freedom in expressing the how of the final result.

Now, if there are details you're presenting that the client keeps questioning—meaning that they are concerned about behavior, animation, and other attributes that contribute to the usability of a documented feature—a quick "grey box" motion study or disposable prototype built in a tool such as Flash, Photoshop, AfterEffects, Expression Blend, etc. can help move your discussion along. At the lowest fidelities, it's even appropriate to demonstrate an interaction using a few pieces of paper with pencil sketches. Whatever can help you show the proper attributes of how as part of your why will help you and your client agree on what's being built.

And if your design goal doesn't warrant wireframes? Answer for the why and the how with simple, annotated visual comps.

Data, Delight, and User Experience Design

Many thanks to my friend Ric Ewing, who was a co-author of this piece.

Pick a card from the deck that I've fanned out before you. Memorize the card, then place it on top of the deck. I'll let you cut it a few times, before I reveal that it's… the Six of Spades!

What's the secret behind this magic trick? If I told you, then it wouldn't be a trick anymore—and you wouldn't have been delighted in the process.

As a magician, I can't reveal my methods. But as a UX designer, I have an obligation to point out that the trick isn't really magic. "Not even the best magician in the world can produce a rabbit out of a hat if there is not already a rabbit in the hat," says a character in the movie The Red Shoes. UX designers are ever seeking to identify, define, refine, and otherwise clarify what people expect to see and do when they visit a website or use a web application. The best sites fulfill these core user expectations, but the very best sites deliver an extra layer of "magic" that transcends those expectations through how data is surfaced through their site experience.

So how do you make sites that provide this extra bit of magic? Here's a few common-sense notions on the subject.

"Can You Say That in English? Explaining UX Research to Clients" in A List Apart Magazine

The new business meeting was going swimmingly—that is, until the client started asking questions about our design process. Then we unleashed our lexicon of specialized user experience (UX) research terminology.

Why should we do that thing you called...what was it, task analysis? We’d like some of those personas. They’re important, right? What the heck is contextual inquiry?!

As mental models flew about the room, I realized how hard it is for clients to understand the true value of UX research. As much as I’d like to tell my clients to go read The Elements of User Experience and call me back when they’re done, that won’t cut it in a professional services environment. The whole team needs a common language and a philosophy that’s easy to grok.

I created a cheat sheet to help you pitch UX research using plain, client-friendly language that focuses on the business value of each exercise. But, before we get to the cheat sheet, let’s talk about how we can communicate the value of UX research at a much higher level.

Continue reading at AListApart.com

Phone Knows Best

Can a phone be your trusted best friend? Your personal trainer? Your confidante? Can it cheer you up when you're stressed? Can it know what you're feeling, and why you're feeling it? Can it go away when you just want to sit in the corner and cry?

If we're serious about pushing the utility of mobile devices to their absolute limit, then we will have to create software so sophisticated that it can discern the difference between the perceived intent of user actions and the actual intent contained in our brains and bodies. Computers will need to make us feel like they're reading our minds—not just our words, where our eyeballs are pointing, and where our body is positioned in physical space. And when we behave in a irrational manner (meaning like human beings) these same computers will need to withhold judgment on what does not compute.

We will call these design challenges "HAL 9000 problems," because this leap in technological evolution brings up some very gnarly dilemmas for designers and developers—though not because an AI in a spaceship is preparing to kill us. (Yet.)

YOUser Experience

What DNA does conceptual art share with interaction design? More than any technical profession would care to admit.

"The idea in conceptual art is that the artist causes experiences to happen to himself, and then ruminates on the interaction between the self and the experience; an audience may be permitted to observe, but is not essential," says Roger Ebert, in his recent (and fantastic) blog post "The agony of the body artist."

So if I was to apply Ebert's thinking about conceptual art to the discipline of interaction design, then it would read as follows:

The idea in interaction design is that the designer causes experiences that happen to others, then ruminates on the interaction between the other and his or her experience; a designer may be permitted to observe, but s/he is not essential.

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.