The Story’s the Thing

This is an excerpt from “UX Storytellers”:http://uxstorytellers.blogspot.com. If you enjoy it, consider getting the kindle edition of UX Storytellers – Connecting the Dots with all the stories!

Here’s something I believe in: stories are what make us human. Opposable thumbs? Other animals have those. Ability to use tools? Ditto. Even language is not exclusive to human beings.

From my amateur reading of science, the story behind our stories goes something like this: the human brain evolved with an uncanny knack to recognize and create patterns; and through some strange twist of natural selection, gradually over millions of years, our brains started turning the incredible power of that pattern-making machinery on ourselves, until we became self-aware.

Aware of ourselves—our own faces, bodies, journeys, homes, children, tools, and everything else around us. Over eons, we went from being creatures that lived in each moment as it came and went, to protagonists in our own myths. Everything in our midst became the material for making stories, strands of moments woven into tapestries that we call things like “nation”, “family,” “love” or “discovery.”

And “design.” Because design is, ultimately, a story we make. And designing is an act of weaving a new story into an existing fabric in such a way that it makes it stronger, better, or at least more interesting, and hopefully more delightful.

 

An Origin Story

My identity as an information architect happened accidentally, and gradually. I just kept doing things I liked, that people were willing to pay me for, until I woke up one day and realized I had a career. And the things I liked doing were invariably surrounded by people’s stories.

One of the earliest jobs I had out of college (after trying my hand at carpet cleaning, waiting tables and telemarketing) was as an office manager in a medical office. It was 1990, and this office of five or six providers was running entirely on a phone, a copier and an electric typewriter. No computer in sight. Every bill, insurance claim, or patient report had to be typed anew … as if the 80s had never happened. I talked the owner into getting a computer and a database management package—a sort of Erector set for database application design that I’d seen at a Mac user group a year before—so I could make the office more efficient.

It would’ve been pretty easy to create a quick application with a minimal user interface, if I were the only one using it. But the owner also had a couple of people helping in the office part-time who needed to use the system too—people who had never even used a computer before. Did I mention this was 1990?

So I had a challenge: how to make it work so that total computer newbies could use it? It was frustrating, fascinating, and probably the single most important experience of my career, because it was a crucible for acknowledging the importance of understanding the user.

To understand the people who were to use the application, I had to talk to them, get a sense of what they’d done before and what sort of forms they had used in the past. What sorts of technology? What terminology was going to make sense for them? How do they tend to learn—by written instruction or hands-on activity, by rote or through improvisation? I learned these things by watching and conversing. Eventually I had enough of a sense of those “users” that I had a full story in my head about how they came to the experience of this particular application, in this particular place.

I wasn’t conscious of this at the time; and I was working completely by intuition. I would’ve done a better job if I’d had the experience, methods and tools I’ve picked up since. But looking back, the experience itself has become a story I tell myself when I need a rudder to remind me of my direction as a designer so that, even when I have nothing else to go on, if I just watch, listen and absorb the stories of the people for whom I’m designing, my design will generally head in the right direction.

 

An Architecture Story

Much later, about ten years ago, I was working at a web design agency, and our client was an organization that acted as a sort of confederation of research scientists, universities and technology corporations. The organization funneled research money from “investor” companies to the scientists and their students in the universities, and in return the companies received “pre-competitive” research and dibs on some of the brightest graduates.

Their website had evolved like so many in those days—having started from a few linked documents, it had grown by the addition of ad-hoc sections and content created in response to member requests and complaints, until it had become a horribly unwieldy mass of links and text. We had been called in to clean it up and organize it. That sounded straightforward enough. But when we started interviewing its users, we found people who were unhappy with the organization and its community in general—scientists who had become more entrenched in their own sub-disciplines, and divisions between those managing the community and those merely dwelling there. Not to mention the natural enmity between academics and business leaders.

We realized that the web site had become a visible instantiation of that discord: a messy tangle of priorities in tension. A new information architecture would mean more than just making things more “findable.” It meant trying to make a digital place that structurally encouraged mutual understanding. In essence, a more hospitable online home for people with different backgrounds, priorities and personalities. It was a chance to create a system of linked contexts—an information architecture—that could help to heal a professional community, and in turn strengthen the organization founded to support it.

That project provided an insight that has forever shaped how I understand the practice of information architecture: the web isn’t just a collection of linked content, it’s a habitat. And the structures of habitable digital places have to be informed by the stories of their inhabitants.

 

A Survival Story

Much more recently, I had the opportunity to work with a non-profit organization whose mission was to educate people about breast cancer, as well as provide an online forum for them to share and learn from one another. When interviewing the site’s users, it soon became clear how important these people’s stories were to them. They would tell the tale of their cancer, or the cancer of a loved one, and in each case the story was one of interrupted expectation—a major change of direction in what they assumed to be the storyline of their lives.
I learned that this website was merely one thread in a great swath of fabric that the site would never, ultimately, touch. But the site was most valuable to these people when it supported the other threads, buttressed them, added texture where it was needed, especially when it helped fill in the gaps of their stories: How did I get cancer? What do my test results mean? What treatment should I choose? What can I eat when getting chemo? How do I tell my children?

They wanted information, certainly. Articles full of facts and helpful explanations. And the site did that very well by translating medical research and jargon into information people could use. But even more than the packaged articles of information, so many people wanted—needed—to share their stories with others, and find other stories that mirrored their own. The most valuable learning these people discovered tended to be what they found in the forum conversations, because it wasn’t merely clinical, sterile fact, but knowledge emerging organically from the personal stories, rich in context, written by other people like them.

One woman in particular lived on an island in the Caribbean, and had to fly to the mainland for treatment. There were no support groups around her home, and few friends or family. But she found a community on this website; one that would cheer her on when she was going to be away for tests, console her or help her research alternatives if the news was bad, and celebrate when news was good. She made a couple of very close friends through the site, and carried on relationships with them even after her cancer had been beaten into submission.

Here were stories that had taken hard detours, but had found each other in the wilderness and had become intertwined, strengthening one another on the new, unexpected journey.

This work, more than any other I’d done before, taught me that stories aren’t merely an extra layer we add to binary logic and raw data. In fact, it’s reversed—the stories are the foundations of our lives, and the data, the information, is the artificial abstraction. Information is just the dusty mirror we use to reflect upon ourselves, merely a tool for self-awareness.

It was through listening to the whole stories as they were told by these digital inhabitants that I learned about their needs, behaviors and goals. A survey might have given me hard data I could’ve turned into pie charts and histograms, but it would’ve been out of context, no matter how authoritative in a board room.

And it was in hearing their stories that I recognized, no matter how great my work or the work of our design team might be, we would only be bit players in these people’s lives. Each of them happens to be the protagonist in their own drama, with its own soundtrack, scenery, rising and falling action, rhyme and rhythm. What we made had to fit the contours of their lives, their emotional states, and their conversations with doctors and loved ones.

 

The Moral of the Story

Design has to be humble and respectful to the presence of the user’s story, because it’s the only one that person has. Stories can’t be broken down into logical parts and reconstituted without losing precious context and background. Even though breaking the story down into parts is often necessary for technological design, the story lives only if we serve as witness to the whole person, with a memory of his or her story as it came from that person’s mouth, in that person’s actions.

Keeping the story alive keeps the whole idea of the person alive. Whether we use “personas” or “scenarios” or task analysis or systems thinking, the ultimate aim should be to listen to, understand and remember the stories, precisely because the stories are the beating heart of why we’re designing anything at all.

So, now, when I’m working on more mundane projects that don’t touch people in quite the same way as some of the others I’ve done, I still try to remember that even for the most everyday task, something I design still has to take into account the experience of the whole person using the product of my work. That, after all, is what we should mean when we say “user experience”—that we seek first to listen to, observe and understand the experience of the people for whom we design. We honor them in what we make, when we honor their stories.

Personas and the Role of Design Documentation

I’d seen hard work on personas delivered in documentation to others downstream, where they were discussed for a little while during a kick-off meeting, and then hardly ever heard from again.

In User Experience Design circles, personas have become part of our established orthodoxy. And, as with anything orthodox, some people disagree on what personas are and the value they bring to design, and some reject the doctrine entirely.

I have to admit, for a long time I wasn’t much of a believer. Of course I believed in understanding users as well as possible through rigorous observation and analysis; I just felt that going to the trouble of "creating a persona" was often wasted effort. Why? Because most of the personas I’d seen didn’t seem like real people as much as caricatured wishful thinking.

Even the personas that really tried to convey the richness of a real user were often assimilated into market-segment profiles — smiling, airbrushed customers that just happened to align with business goals. I’d see meeting-room walls and PowerPoint decks decorated with these fictive apparitions. I’m ashamed to say, even I often gave in to the illusion that these people — like the doe-eyed "live callers" on adult phone-chat commercials — just couldn’t wait for whatever we had to offer.

More often than not, though, I’d seen hard work on personas delivered in documentation to others downstream, where they were discussed for a little while during a kick-off meeting, and then hardly ever heard from again.

Whenever orthodoxy seems to be going awry, you can either reject it, or try to understand it in a new light. And one way to do the latter is to look into its history and understand where it came from to begin with — as is the case with so much dogma, there is often a great original idea that, over time, became codified into ritual, losing much of the original context.

The Origin of Personas

When we say "persona", designers generally mean some methodological descendant of the work of Alan Cooper. I remember when I first encountered the idea on web-design mailing lists in 1999. People were arguing over what personas were about, and what was the right or wrong way to do them. All most people had to go on was a slim chapter in Cooper’s "The Inmates are Running the Asylum" and some rudimentary experience with the method. You could see the messy work of a community hammering out their consensus. It was as frustrating as it was interesting.

Eventually, practitioners started writing articles about the method. So, whenever I was asked to create personas for a project, I’d go back and read some of the excellent guides on the Cooper website and elsewhere that described examples and approaches. As a busy designer, I was essentially looking for a template, a how-to guide with an example that I could just fill in with my own content. And that’s natural, after all, since I was "creating a persona" to fulfill the request for a kind of deliverable.

It wasn’t until later that Alan Cooper himself finally posted a short essay on "The Origin of Personas." For me it was a revelation. A few paragraphs of it are so important that I think they require quoting in full:

I was writing a critical-path project management program that I called “PlanIt.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of PlanIt to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

If we slow down enough to really listen to what Cooper is saying here, and unpack some of the implications, we’re left with a number of insights that help us reconsider how personas work in design.

1. Cooper based his persona on a real person he’d actually met, talked with, and observed.
This was essential. He didn’t read about "Kathy" from a market survey, or from a persona document that a previous designer (or a separate "researcher" on a team) had written. He worked from primary experience, rather than re-using a some kind of user description from a different project.

2. Cooper didn’t start with a "method" — or especially not a "methodology"!
His approach was an intuitive act of design. It wasn’t a scientific gathering of requirements and coolly transposing them into a grid of capabilities. It came from the passionate need of a designer to really understand the user — putting on the skin of another person.

3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play.
Cooper was telling himself a story, and embodying that story as he told it. The persona was in the designer, not on paper. If Cooper created a document, it would’ve been a description of the persona, not the persona itself. Most of us, however, tend to think of the document — the paper or slide with the smiling picture and smattering of personal detail — as the persona, as if creating the document is the whole point.

4. Cooper was doing this in his "spare time," away from the system, away from the cubicle.
His slow computer was serendipitous — it unwittingly gave him the excuse to wander, breathe and ruminate. Hardly the model of corporate efficiency. Getting away from the office and the computer screen were essential to arriving at his design insights. Yet, how often do you see design methods that tell you to get away from the office, walk around outside and talk to yourself?

5. His persona gained clarity by focusing on a particular person — "Kathy".
I wonder how much more effective our personas would be if we started with a single, actual person as the model, and were rigorous about adding other characteristics — sticking only to things we’d really observed from our users. Starting with a composite, it’s too easy to cherry-pick bits and pieces from them to make a Frankenstein Persona that better fits our preconceptions.

Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

The biggest insight I get from this story? Personas are not documents, and they are not the result of a step-by-step method that automagically pops out convenient facsimiles of your users. Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

It’s not about the documents

Often when people talk about “personas” they’re really talking about deliverables: documents that describe particular individuals who act as stand-ins or ‘archetypes’ of users. But in his vignette, Cooper isn’t using personas for deliverables — he’s using them for design.

Modern business runs on deliverables. We know we have to make them. However, understanding the purposes our deliverables serve can help us better focus our efforts.

Documentation serves three major purposes when designing in the modern business:

1. Documentation as a container of knowledge, to pour into the brains of others.

By now, hopefully everyone reading this knows that passing stages of design work from one silo to the next simply doesn’t work. We all still try to do it, mainly because of the way our clients and employers are organized. As designers, though, we often have to route around the silo walls. Otherwise, we risk playing a very expensive version of "whisper down the lane," the game you play as kids where the first kid whispers something like "Bubble gum is delicious" into another’s ear, and by the end of the line it becomes "Double dump the malicious."

Of course there are some kinds of information you can share effectively this way, but it’s limited to explicit data — things like world capitals or the periodic table of elements. Yet there are vast reservoirs of tacit knowledge that can be conveyed only through shared experience.

If you’ve ever seen the Grand Canyon and tried to explain it to friends back home, you know what I mean. You’d never succeed with a few slides and bullet points. You’d have to sit down with them and — relying on voice, gesture and facial expression — somehow convey the canyon’s unreal scale and beauty. You’d have to essentially act out what the experience felt like to you.

And even if you did the most amazing job of describing it ever, and had your friends nearly mirroring your breathless wonderment, their experience still wouldn’t come close to seeing the real thing.

I’m not saying that a persona description can’t be a useful, even powerful, tool for explaining users to stakeholders. It can certainly be highly valuable in that role. I’m only saying that if you’re doing personas only for that benefit, you’re missing the point.

2. Documentation as a substitute for physical production.

Most businesses still run on an old industrial model based on production. In that model, there’s no way to know if value is being created unless there are physical widgets coming off of a conveyor belt — widgets you can track, count, analyze and hold in your hand.

In contrast, knowledge work – and especially design – has very little actual widget-production. There is lots of conversation, iteration, learning, trying and failing, and hopefully eventual success. Design is all about problem solving, and problems are stubbornly unmeasurable — a problem that seems trivial at the outset turns out to be a wicked tangle that takes months to unravel, and another that seemed insurmountable can collapse with a bit of innovative insight.

Design is messy, intuitive, and organic. So if an industrial-age management structure is to make any sense of it (especially if it’s juicing a super-hero efficiency approach like Six-Sigma), there has to be something it can track. Documents are trackable, stackable, and measurable. In fact, the old "grade by weight" approach is often the norm — hence the use of PowerPoint for delivering paper documents attenuated over two hundred bulleted slides, when the same content could’ve fit in a dozen pages using a word processor. The rule seems to be that if the research and analysis fill a binder that’s big enough to prop your monitor to eye level, then you must’ve done some excellent work.

In the pressure to create documents for the production machine, we sap energy and focus away from designing the user experience. Before you know it, everything you do — from the interviews and observations, to the way you take notes and record things, the way you meet and discuss them after, and the way you write your documentation — all ends up being shaped by the need to produce a document for the process. If your design work seems to revolve mainly around document deadlines, formatting, revision and delivery, stop a moment and make sure you haven’t started designing documents for stake-holders at the expense of designing experiences for users.

Of course, real-world design work means we have to meet the requirements of our clients’ processes. I would never suggest that we all stop delivering such documentation.

Part of the challenge of being a designer in such a context is keeping the industrial beast happy by feeding it just enough of what it expects, yet somehow keeping that activity separate from the real, dirty work of experiencing your users, getting them under your skin, and digging through design ideas until you get it right.

3. Documentation as an artifact of collaborative work and memory.

While the first two uses are often necessary, and even somewhat valuable, this third use of documentation is the most effective for design — essentially a sandbox for collaboration.

These days, because systems tend to be more interlinked, pervasive and complex, we use cross-disciplinary teams for design work. What happened in Cooper’s head on the golf course now has to somehow happen in the collective mind of a group of practitioners; and that requires a medium for communication. Hence, we use artifacts — anything from whiteboard sketches to clickable prototypes.

The artifacts become the shorthand language collaborators use to "speak design" with one another, and they become valuable intuitive reminders of the tacit understanding that emerges in collaborative design.

Personas, as documents, should work for designers the way scent works for memories of your childhood.

Because we have to collaborate, the documentation of personas can be helpful, but only as reminders. Personas, as documents, should work for designers the way scent works for memories of your childhood. Just a whiff of something that smells like your old school, or a dish your grandmother used to make, can bring a flood of memory. Such a tool can be much more efficient than having to re-read interview transcript and analysis documents months down the road.

A persona document can be very useful for design — and for some teams even essential. But it’s only an explicit, surface record of a shared understanding based on primary experience. It’s not the persona itself, and doesn’t come close to taking the place of the original experience that spawned it.

Without that understanding, the deliverables are just documents, empty husks. Taken alone, they may fulfill a deadline, but they don’t feed the imagination.

Playing the role

About six months ago, my thoughts about this topic were prompted by a blog post from my colleague Antonella Pavese. In her post, she mentions the point Jason Fried of 37 Signals makes in +Getting Real+ that, at the end of the day, we can only design for ourselves. This seems to fly in the face of user-centered design orthodoxy – and yet, if we’re honest, we have to realize the simple scientific fact that we can’t be our users, we can only pretend to be. So what do we do, if we’re designing something that doesn’t have people just like us as its intended user?

Antonella mentions how another practitioner, Casey Malcolm, says to approach the problem:

To teach [designers] how to design usable products for an older population, for example, don’t tell designers to take in account seniors’ lower visual acuity and decreased motor control. Let young designers wear glasses that impair their visual acuity. Tie two of their fingers together, to mimic what it means to have arthritis or lower motor control."

Antonella goes on:

So, perhaps Jason Fried is completely on target. We can only design for ourselves. Being aware of it, making it explicit can make us find creative ways of designing for people who are different from us… perhaps we need to create experience labs, so that for a while we can live the life of the people we are designing for."

At UX Week in Washington, DC this summer, Adaptive Path unveiled a side project they’d been working on — the Charmr, a new design concept for insulin pumps and continuous monitors that diabetics have to constantly wear on their bodies. In order to understand what it was like to be in the user’s skin, they interviewed people who had to use these devices, observed their lives, and ruminated together over the experience. Some of the designers even did physical things to role-play, such as wearing objects of similar size and weight for days at a time. The result? They gained a much deeper feel for what it means to manage such an apparatus through the daily activities the rest of us take for granted — bathing, sleeping, playing sports, working out, dancing, everything.

Personas aren’t ornaments that make us more comfortable about our design decisions. They should do just the opposite.

One thing a couple of the presenters said really struck me — they said they found themselves having nightmares that they’d been diagnosed with diabetes, and had to manage these medical devices for the rest of their lives. Just think — immersing yourself in your user’s experience to the point that you start having their dreams.

The team’s persona descriptions weren’t the source of the designers’ empathy — that kind of immersion doesn’t happen from reading a document. Although the team used various documentation media throughout their work – whiteboards and stickies, diagrams and renderings – these media furthered the design only as ephemeral artifacts of deeper understanding.

And that statement is especially true of personas. They’re not the same as market segmentation, customer profiling or workflow analysis, which are tools for solving other kinds of problems. Neither do personas fit neat preconceptions, use-cases or demographic models, because reality is always thornier and more difficult. Personas aren’t ornaments that make us more comfortable about our design decisions. They should do just the opposite — they may even confound and bedevil us. But they can keep us honest. Imagine that.

References:

  • Alan Cooper, “The Origin of Personas”:http://www.cooper.com/insights/journal_of_design/articles/the_origin_of_personas_1.html
  • Jason Fried, “Ask 37 Signals: Personas?”:http://www.37signals.com/svn/posts/690-ask-37signals-personas
  • Antonella Pavese, “Get real: How to design for the life of others?”:http://www.antonellapavese.com/archive/2007/04/249/
  • Dan Saffer, “Charmr: How we got involved”:http://www.adaptivepath.com/blog/2007/08/14/charmr-how-we-got-involved/

_*Author’s Note:* In the months since the first draft of this article, spirited debate has flared among user-experience practitioners over the use of personas. We’ve added a few links to some of those posts below, along with links to the references mentioned in the piece. I’d also like to thank Alan Cooper for his editorial feedback on my interpretation of his Origins article._

  • Peter Merholz, “Personas 99% bad?”:http://www.peterme.com/?p=624
  • Joshua Porter, “Personas and the advantage of designing for yourself”:http://bokardo.com/archives/personas-and-the-advantage-of-designing-for-yourself/ and “Personas as tools”:http://bokardo.com/archives/personas-as-tools/
  • Jared Spool, “Crappy personas vs. robust personas”:http://www.uie.com/brainsparks/2007/11/14/crappy-personas-vs-robust-personas/ and “Personas are NOT a document”:http://www.uie.com/brainsparks/2008/01/24/personas-are-not-a-document/
  • Steve Portigal, “Persona Non Grata”:http://interactions.acm.org/content/?p=262, interactions, January/February 2008

Observing the User Experience: A Practitioner’s Guide to User Research

“How do we go about learning who our users are and what they really need? And how do we do this in a way that helps us make a strong case for our design decisions to the people in charge?”

Design is disorienting. Especially when you are designing something in a collaborative environment, with multiple stakeholders, pressured deadlines, business objectives and budgetary constraints. We all go into design with the firm belief that the user is our pole star, but so often we lose that focus because of tossing waves, buffeting winds, and the crew screaming in our ears–never mind the dense cloud cover that always seems to obscure that trusty star just when a committee forms to gather requirements.

With all the attention to usability over the last five years or so and the wonderful swelling of information-architecture-related books just since 2001, you would think we would have enough methods and advice to keep our projects in perfect tack. But so many of these resources, excellent though they are, tend to be more about how to pilot the ship than how to find that all-important star and keep it in sight.

I promise not to drive this metaphor hard into the rocky shore, but think of the projects that could have been saved from being lost at sea if every team had a better grasp of user requirements through direct experience of users and their needs. Think also of how many projects could have stayed the course if only there had been an expert way to sell the findings from that experience to the stakeholders, who so easily forget the users for whom their project was intended.

For precisely these reasons Mike Kuniavsky’s Observing the User Experience: A Practitioner’s Guide to User Research is a welcome addition to the half dozen essential books on my cubicle shelf. This book provides lucid, personable, experienced advice that could only come from a seasoned consultant who has seen the good, bad, and ugly of web and application design. Its purpose is to give a solid foundation to any design team in the crucial beginning stages of a project by answering the questions: How do we go about learning who our users are and what they really need? And how do we do this in a way that helps us make a strong case for our design decisions to the people in charge?

Kuniavsky begins Observing with a cautionary tale about a failed corporate web project, a situation he experienced firsthand (changing identifying information to protect the innocent, of course). This situation involved misguided good intentions from corporate management and developers, where something they thought would be just what their users wanted turned out to be a huge waste of time and money. This is just one of many real-life lessons used as background throughout the book.

Kuniavsky introduces us to web user research methodologies by showing us how they fit into an overall process and by defining various roles within a design team. These descriptions are clear and sensible, and they are more descriptive than prescriptive: he is not trying to tell us these are the roles you have to use and this is what you have to call them in guru-speak, but describing with conventional labels what tends to happen in a successful project.

The chapters are well-organized and consistent, and content is cross-referenced from chapter to chapter where appropriate. Unlike many design-related books, this one is actually fairly heavy on text and light on visuals. Where visuals are used, they are very helpful and serve to explicate the content. A good example is his spiral model of Iterative User Research,which cycles from Examination to Definition to Creation and, as it deepens, gets more granular through Contextual Inquiry, Focus Groups, Usability Tests, and so on. Kuniavsky wisely points out that many companies already have marketing research results that may be expected to yield the results necessary for web design, but explains how the tools used by conventional marketing approaches are only part of the solution for user-centered design. Focus groups and surveys can supply valuable information, but focusing on direct experience of user behavior using a combination of appropriate methods offers a stronger core for design.

Kuniavsky goes on to provide an excellent mixture of step-by-step direction and experienced advice on the practicalities of user research. Beginning with how to put together a research plan (invaluable instruction, since planning seems to be the Achilles heel of so many projects), he explains how to make sure business goals are being considered along with user goals. He admits these instructions present a somewhat idealized situation that starts as a blank slate as far as user experience product goals are concerned. However, Kuniavsky manages to keep his advice from being so lofty that no real-world team could actually follow it.

The chapter on recruiting and interviewing is especially thorough. It provides a sample phone screening script and boilerplate recruiting communication, as well as advice on how to handle no-shows, heavily biased users, and people who do not end up fitting your model. In fact, it may be the coverage of so many aberrations and anomalies that make this book so unusually valuable. This is advice one would normally only gain on the job or working side by side with a highly experienced researcher.

Kuniavsky devotes the bulk of the book to describing a series of proven techniques for researching user needs and behaviors, including user profiles, contextual inquiry (plus task analysis and card sorting), focus groups, usability tests, and surveys, as well as more secondary-research approaches such as diaries, log files, customer support, and competitive research. He presents each method in a separate chapter, describing when each one is most appropriate and various methods of execution. Throughout, Kuniavsky glosses his text with marginal notes, giving a reality check or bit of wisdom in each one, such as the reminder that Focus groups uncover people’s /perceptions/ about their needs and their values. This does not mean that they uncover what people /actually/ need or what really /is/ valuable to them-however-knowing perceptions of needs is as important as knowing the needs themselves.

In his descriptions of various methods, there is surprisingly little dogma. In an industry that has spawned a thousand do’s and don’ts lists for design, it is refreshing to find so many techniques described with equal value and rationale. I personally have long held a bias against focus groups, surveys, and marketing research as being especially valuable for fully understanding users, but this book has helped me see these resources in a more positive light.

It is also a relief to read this book’s conversational and low-jargon voice. There are a number of books I find essential in my work that I still have trouble actually comprehending during a busy workday. Somehow this one cuts through the fog of design-speak to present some very sophisticated concepts and methods in a way so that a relative novice could read it and hit the ground running. Take, for example, his lucid description of the role of information architect: It’s the information architect’s job to make the implicit architecture explicit so that it matches what the users need, expect, and understand. The architect makes it possible for the users to navigate through the information and comprehend what they see. I have never seen my job explained with such clarity anywhere else.

Another strength is Kuniavsky’s business-savvy approach to design. In the very first chapters he does an excellent job explaining the various tensions between different groups with their own agendas encountered in any collaborative design effort. He shows how having solid and documented user research can help to defuse these tensions and keep the user as the central focus of the work. In fact, Kuniavsky even has a chapter on Creating a User-Centered Corporate Culture, an ambitious but necessary topic for any corporation finding its business model being warped into a whole new shape by the powerful gravitational pull of the web.

So much of design involves a kind of tea-leaf reading voodoo that is hard to justify or describe to managers and stakeholders. When we do the typical routine–look at some users, have some conversations, and then come back with all these ideas on how to design an expensive project–aren’t the people paying for it fully justified in asking Why do you think you really know how we should build this thing? And how can one blame them for thinking their own ideas are just as valid as ours? Observing the User Experience provides solid techniques for knowing our users from a 360-degree perspective in a way that we can document, communicate, and even sell to other team members and project owners. Think of it as a combination navigational chart, captain’s log, and sextant for web endeavors–a one-stop shop for tools that help your team stay the user-centered course.

About the book:

  • Observing the User Experience: A Practitioner’s Guide to User Research

  • Mike Kuniavsky
  • Morgan Kaufmann, 2003
  • ISBN 1-55860-923-7
  • List Price: $44.95
  • Chapters:
    • Part I: Why Research is Good and How It Fits Into Product Development
      1. Typhoon: A Fable
      2. Do A Usability Test Now!
      3. Balancing Needs Through Iterative Development
      4. The User Experience
    • Part II: User Experience Research Techniques
      1. The Research Plan
      2. Universal Tools: Recruiting and Interviewing
      3. User Profiles
      4. Contextual Inquiry, Task Analysis, Card Sorting
      5. Focus Groups
      6. Usability Tests
      7. Surveys
      8. Ongoing Relationship
      9. Log Files and Customer Support
      10. Competitive Research
      11. Others’ Hard Work: Published Information and Consultants
      12. Emerging Techniques
    • Part III: Communicating Results
      1. Reports and Presentations
      2. Creating a User-Centered Corporate Culture


Andrew Hinton is a Senior Information Architect at The Vanguard Group in Valley Forge, PA. His personal website is www.memekitchen.com.

Small Pieces, Big Thoughts

Dave Weinberger brings new focus to how we see the Internet in “Small Pieces Loosely Joined”

Small Pieces Loosely Joined” is touted on the cover as “A Unified Theory of the Web.”“The Web couldn’t have been built if everyone had to ask permission first.”
—David Weinberger
But its author, David Weinberger, knows better. And he says as much in the book. It’s a unified theory, but not the kind you sum up in a tidy little equation. It’s unified in its single-mindedness to see the Internet with a certain lens, and to understand how the paradigms are shifting under our feet like tectonic plates, imperceptibly perhaps, but enough to change the fabric of the world we live in.

Dave Weinberger gets around. His earlier careers have included being a philosophy professor, a consultant, and a marketing executive. He has a regular commentary broadcast on NPR; he co-wrote the hugely popular book The Cluetrain Manifesto, and he has articles and speaking engagements all over the place. His surreptitiously published ‘zine known as JOHO (the Journal of the Hyperlinked Organization) is widely read and quoted by loads of neterati. And he recently joined the denizens of Blogistan with his own weblog at JOHO the Blog. (For the nitty gritty on DW’s life and times, check his Bio page.)

If you’ve read Cluetrain (and if you haven’t, shame on you!), you’re familiar with Weinberger’s sardonic wit and talent for boiling challenging ideas down into pithy metaphors. There’s plenty of that on display here. But as a departure from Cluetrain, the book is less focused on the practicalities of business, and is more a treatise on how the Internet and all massively shared internetworked environments (for the book, conflated to the common term “the Web”) are changing us as social beings.

As for whether or not to read Small Pieces, I’ll cut to the chase: if you think you’re an architect of anything vaguely Internet-related, you should read this book.

There are a number of reasons why “Small Pieces Loosely Joined” is significant for information architects and experience designers of all stripes: it helps us understand how the Web is about more than just information retrieval and ecommerce. It reminds us why most of us got excited about the Web in the first place and tries to renew hope about its value in our lives.

Along the way, the book draws from influences as diverse as Heidegger, theology, and quantum physics to make convincing arguments about the nature of reality on the Web, as well as the nature of knowledge, time, and community. Of course, nobody could expect an encyclopedic treatment of these issues in just under 200 pages. And although Small Pieces makes a valiant effort, its purpose isn’t to bring all these ideas full circle. It’s a spark to reignite a long dormant conversation about what’s really important about the Web.

+ + +

Weinberger starts out by acknowledging the current malaise we seem to feel about the Internet, but he assures us that “the hype about the Web hasn’t been unwarranted, only misdirected.” (p. xii) He wants us to reposition ourselves, clear our heads of preconceptions, and take a new look at the Web, saying “Suppose—just suppose—that the Web is a new world that we’re just beginning to inhabit.” (p. 8)

But trying to describe the Web in accurate language turns out to be quite a challenge. For one thing, it throws all our metaphors out of whack. For another, it is chock full of paradoxes that confuse everything we’ve learned about the world since we emerged as a species.

For example, the Web is perceived as having space, yet it doesn’t have any. It allows people to interact as massive groups, yet each participant retains a fine degree of control over their individuality. It is perhaps the greatest engineering marvel on a massive scale the world has seen, but it has happened with no centralized management or control.

Weinberger explains how the metaphors of “document” and “building” become conflated (or even mutated) into a single concept on the Web, saying “with normal documents, we read them, file them, throw them out, or send them to someone else. We do not go to them. We don’t visit them. Web documents are different. They’re places on the Web. … They’re there. With this phrase, space—or something like it—has entered the picture.” (p. 39) But this space isn’t measured by inches or miles. “On the Web, nearness is created by interest.” (p. 49) In this place, the closest distance between two points is measured by relevance.

Weinberger promotes the idea that the Web’s value doesn’t come so much from being a huge database of facts and figures as from being an unprecedented environment of collective human experience. The distinction is between conversation and reference: what compels us to really sink ourselves into the Web isn’t the data but the “sound of voices.” (p. 143)

In a very fundamental way, “the Web is a social place” (p. 166) where we can be “part of the largest public ever assembled and still maintain our individual faces.” (p. 177) This environment has written language as its DNA, and its pages are “social acts, written with others in mind.” (p. 165)

The words we find on the Web are the fabric of a new kind of world. While language has always been the stuff of world-making, from Gilgamesh to Tolkien, what’s different this time is that the Web is so massively and simultaneously experienced—by 300 million people and climbing.

And it is the peculiar, flawed, rough-hewn authenticity of human voices that make this new place so palpable. Weinberger has a whole chapter on Perfection for this reason. “Imperfection is our shibboleth on the Web, the sign by which we know we’re talking with another human being.” (p. 94) It is organized out of chaos, and splendidly unmanaged. Weinberger cheekily points out, “The Web couldn’t have been built if everyone had to ask permission first.” (p. 53) The imperfection of the Web is its great merit, a symptom of its authenticity and humanity.

Another paradox arises from the kind of humanity we experience on the Web. It is both massively public and highly individualized. It teaches what it might mean to “replace the faceless masses with face-ful masses.” (p. 100) The Web has begun to change how we think of being public and having fame.

Being public has changed in part because of the new way people experience one another online, and because that experience is tied so closely with words and conversations. “Although elements of real-world conversations appear in threaded discussions, there is nothing quite like threaded discussions in the real world.” (p. 110) Because the Web allows for the persistence of conversation threads beyond the moment of their utterance, and because it allows for people to transcend the limitations of their physical social surroundings, one person can have a loyal following as an expert or particularly brilliant and witty commentator on a remote, esoteric topic. Forever twisting Warhol’s quip beyond all recognition, Weinberger says, “On the Web, everyone will be famous to fifteen people.” (p. 104)

For that matter, someone with a rare disease can have meaningful community with others who share their ailment, no matter how geographically distant. Ethnic minorities in distant countries (who are lucky enough to have Web access) can commiserate and communicate about their lives. Families can feel more immediately connected than the occasional paper letter allows. These are all things that didn’t exist before this global network arrived, and they have become so taken for granted that we miss the phenomenal changes that have resulted. One change, Weinberger argues, is that the Web has actually returned us to a more community-based way of relating to one another.

Weinberger isn’t much on rugged individualism. His point: It is in its ability to connect us to and with others (both connections between people and hyperlinks between information, one being essentially an outward manifestation of the other) that the Web is valuable to us. Individuals are of course necessary for this to happen, but “Groups are the heart of the Web.” (p. 105) Weinberger blames everyone from Descartes to Sartre for getting us into our solipsistic funk (“To a solipsist, the Web is the most irrelevant contraption ever invented.” (p. 182)), and credits the Web with being a source of hope for getting us out again. He believes we are “at our best when we acknowledge our deep attachment to the others of our world.” (p. 182)

In our jobs as designers of shared information environments, should we keep in mind that the Web has a moral dimension? After all, what we are designing and creating are places for people to live, work, and play together. Even the most mundane standalone business application can have resounding implications for how an organization’s employees interact with one another and their customers. Think of how much more powerful its effects can be when it’s a networked application that connects those people’s ideas, decisions, and daily work so profoundly.

True, some of Weinberger’s statements of sweeping optimism seem, at first glance, naïve. But Weinberger grounds his sentiment in some fairly rigorous rationale. To be honest, the book isn’t a hard-core philosophical dissertation, but that’s a good thing. Small Pieces isn’t for tweed-encrusted academics—it’s for the somewhat educated masses. This book is like its subject, the Web. It’s an amalgam of ideas and obsessions, observations and perceptions that the author is releasing upon the public, hoping others will take these ideas and run with them. Whether Weinberger is right or wrong is beside the point (and I’d guess he would agree). The point is that these ideas not be ignored, and that we consider them in our lives and work; that we continue the conversation.

About the book:

For more information:

Andrew Hinton an Internet obsessive since 1989, is a senior information architect at The Vanguard Group in Valley Forge, Pennsylvania.