Field Notes Inside an Integrated Communications Agency

I constantly hear sentences like "users want such-and-such." I cringe every time. This might sound strange coming from a user experience designer.

Users are not vague outsiders. To misquote Charlton Heston, users are made of people. They're specific types of people, with names and lives. And consciously or not, these folks have to decide whether your product helps them accomplish their goals.

So, you need to know them intimately.

 

Let's role play.

Pretend you have a recipe Web site. Think your "users" are people who want recipes? Nope. They're people like Mary.

 

Mary is an unmarried mother of two. She works double-shifts when she can and is studying for her GED. She needs to feed her kids a cheap, nutritious dinner in under one hour because she has to study from 9pm to 12am.

 

You can picture her right? She might sound like someone you know. You can empathize with her deeply. And since you now know her, you can make informed decisions on her behalf.

 

Building for Mary.

So back to the recipe site. Assuming people like Mary are your priority, you might decide to:

- Build your database around easy-to-prepare meals.

- Show ingredient substitutions, in case she doesn't have something on hand. Help her minimize trips to the grocery store.

- Add a "Find recipes that use..." search tool, so she can find recipes that use ingredients in her pantry.

- Allow recipes to be filtered by total prep and cook time.

- Write a series of articles called "One Pan Dinners."

- List nutritional data with comparisons to daily allowances.

- Let her scale ingredients by the number of servings.

- Create a tool that scrapes Kroger's sale items and emails her a customized weekly menu, replete with shopping list and coupons.

 

Furthermore, this newfound focus helps you decide what not to invest in. Knowing Mary, you might not:

- Spend time adding recipes that use squid ink and other Iron Chef-caliber ingredients.

- Court advertisers like Viking ranges, Le Creuset or Whole Foods.

- Build a MySommelier app for recommending wine pairings.

Here's the point.

Real people use your product, not users. If you can't describe them like they are your next-door neighbor, then you can't design for them. Get to know them intimately and banish the word user from design discussions.

 

Need more convincing?

Sam Farber saw his arthritic wife struggling to control a carrot peeler. With this person and her situation in mind, he started prototyping kitchen utensils that were singularly focused on ergonomics. After testing and refining with real people, his work became the OXO Good Grips line. By considering real people deeply, his kitchen utensils redefined a household commodity and created a new market.

Now go read OXO's story.

At SXSW 09 , I listened to a panel* of UX game designers talk about the unique challenges around building games. Much of their discussion, however, applied to usability testing in other software. Four big takeaways that I heard:

Let testers bail

Usability tests--especially structured task tests--often put the participant in an artificial situation. While the task may be representative, the user may spend more time on the task than normal. In fact they might keep banging away at the task even if, in reality, they would have bailed a long time ago. At the onset of a usability test, give the participant a "stop word" so that they can clue you in to where they would have abandoned your site.

 

Let go of the formality.

Some clients are forever looking for formalized tests. These include a "magic" number of users, tested during a specific set of time, and using very structured and repeatable tasks. While there are merits to this approach, it's important to recognize that conducting tests is not the end game. Making the product better is.

So grab your neighbor, your friends and family, and evaluate the design without a whole lot of hullabaloo. Its better to get some data often than a lot late. Remember that, despite usability testing having roots in science--it is most often not scientific. That's a good thing because it gives you more flexibility in test execution.

 

Test in person

There are definite kinesthetic and verbal reactions that users have to products, which can't be observed remotely. Erica Firment noted one that she sees often is the "eye flash," or the point at which the user's eyes widen in enjoyment. Jason Schklar noted hearing the repeated smack of the joystick against a controller as evidence that the gamers were playing in a way less subtle than expected.

 

Go into the wild

Usability is as much about analyzing reactions to your products in the wild. So, set up Google Alerts, Twitter searches, etc. to automatically scan and report on problem phrases you anticipate your users saying. This can help you get a leg up on those people who aren't submitting trouble tickets, but are being vocal about problems your product has.

* Funologists Live & In Person: Guerrilla Game Research

At the Funologists panel  at SXSW , the speakers lightly touched on digital ethnography. One of the points they that came up was the "lying user" phenomenon. While they didn't go into it too far, it sparked an idea I've been meaning to write about.

One of the hardest parts about user research and analysis is controlling for lying users. It's not that users try to be deceitful. But there are many reasons why they may not be telling you the truth. Here are four:

Need to represent themselves.
Users may lie about choices they have made in the past because the truth reflects negatively on their self image. For example, a user may state they purchased an iPod because of it's ease-of-use, when the real reason was that they felt buying a SanDisk MP3 player would mark them as less hip. 

For this phenomenon, a best practice is to probe further until you can get specific information about what influenced the decision.

Inability to forecast future actions.
People are notoriously bad predictors of how they will behave in the future. They expect their future behavior to be markedly different than what past behavior suggests. Similarly, their ability to recall previous actions degrades over time. For example, a user may say that they really want a customization feature. If you ask them to recall customizing a similar feature in the past 6 months, the answer is often very different. In both cases, the further you get away from the present, the rosier the glasses become.

A tip for handling this situation is to follow questions that speculate about behavior with "grounding" questions that ask them to recall behaving like this in the past. 

Fear of insulting the moderator.
Simply to avoid being critical or confrontational, users will often not truly confess dissatisfaction with a product. Not wanting to hurt the feelings of the researcher is a common unspoken issue.

At the onset of research, the researcher should explicitly distance himself from the design, saying something like "Be candid. I'm not the designer, so nothing you can say will hurt my feelings." 

Fear of looking uncreative.
This happens often in sessions where you simply ask the user to rattle off features they would like. Often, users base their responses on those they already know exist--rather than suggesting features that solve real problems they face. For example, you may hear "I'd like the page to be customizable like iGoogle" when they have no precedent of customizing pages.

For this situation, it's ok to solicit features but make this a low-priority research tactic. Instead, focus on the actual challenges they face, agnostic of a solution.

 

These are just four of the many reasons users lie to researchers. The message is this: when doing research, consider the answers they give but be cautious and critical. Don't take any self-reported information too seriously, since they are easily tainted. Where you expect there to be lying bias, probe for detail and past history to validate their responses.

In user experience, it seems common that the terms "goal" and "task" get confused quite a bit.  Tasks get cast as goals, when they really aren't. It's easy enough to do: goals can seem amorphous and hard to design for. Tasks are more observable and tactic-oriented. But that does not mean consideration of goals is unnecessary in the design process. In fact, this focus is critical.

We identify goals through research. User research is designed to ferret these out and inform the design and architecture that will support them. This research is not about focus groups, preference, or even opinion. It's about getting to the heart of what challenges people, their contexts of use, and their shared mindsets. It's about building a solution to meet those needs.

Now, don't get me wrong. Tasks are important. They are, usually, the manifestation of how people are trying to achieve a goal. But designing just for tasks is myopic at best. Let me break it down for you.

Take Jill. jill is an an online banker, age 28, fiscally conservative and single. She manages her own investment portfolio. Her overall goal is to retire comfortably at 50. The tasks that support this, however, are much different. They range from her:

• tracking her budget against her actual expenses
• establishing and contributing to a 401k, Roth IRA, and other securities
• taking cost-effective vacations
• ferreting out discounts and sales

Her goal of early retirement is an umbrella that covers a variety of supporting tasks.

Now, if we focused solely on her tasks, we would be short-sighted. We would focus on those transactions that she conducts with the company today. It woud be: checking an account balance, transferring money, ordering checks. Optimizing these are great, sure. 

Where they miss out is the larger context. They focus on just a small piece of the pie. There might be huge opportunities to improve the entire event of retirement planning. Or there might just be great places to sync up with these other tasks, if they're outside of our control. Using the example, this might range from providing lifecycle funds,  financial planning, to discounts on Quicken and Turbotax.

If you only focused on "getting things done" -- i.e. making existing tasks only faster and more intuitive -- well, you would have missed the boat. As Steven Keith said to us presciently the other day, you left equity on the table.

Look at the big button on Soundcloud.com. This variable width beauty scales in at 920px wide on my 1280px monitor. Someone call the Dept of Game and Inland Fisheries--I think this might qualify as a new record.

 

 

One thing I continue to struggle with is how relevant sitemaps are--and to whom?¹

Below is an example sitemap, which indicates the basic hierarchy of pages or categories within a site.

What's wrong with this picture?

Sitemaps don't represent pages...

Implicitly, they communicate pages of content. This is not necessarily the case. They are a quasi-system model that blurs the lines between content and page. This leads to misinterpretation.

Extending this, they are rooted in a page-centric approach that assumes pages have one state. Ajax-y interactions that reload different content into the same page aren't communicated. 

...and they don't really represent content.

They suggest content, but a through the lens of a page. This, I believe, is an artifact left over from the days where sitemaps were closely tied to the physical implementation. As we've evolved the idea of a sitemap away from actual pages, we didn't rethink how it is actually interpreted or used by either developers or clients. 

...and they don't reflect true navigation or interaction paths.

In fact, they indicate a hierarchical flow between pages. Sitemaps suggest that users typically access the site through the home page. Users who arrive via a search or a link from a friend are likely to be entering at a deeper level than the home page. Luke Wroblewski has a great podcast and set of slides on this.

And sitemaps don't account for related items--hyperlinks that bring together similar content that exist in different categories of the site. Similar information may be "nearer" than sitemaps suggest. The perceived distance is content too and associate navigation can be as important as the categorical navigation. 

So, what do they do well?

For me, they are good as a sketch -- not a final product -- for how content may be organized and how navigation may occur. They work well for initial scoping. But having to caveat what sitemaps are feels like a cop out. There's gotta be a better way.

 Any thoughts? Do sitemaps help you or confuse you?

¹I'm talking about the information architecture kind, but many of the points also extend to those junk drawer sitemap pages that many sites have. That's entirely another issue to address.

Figuring out who your users are can be challenging. Many times stakeholders can have varying and conflicting opinions about what users deserve focus. Personas help manage this, but they're products of user research. Prior to research, it's important to provide some direction on who will be studied and in what capacity.

As I was preparing for a brainstorming session, I started thinking about how to start discussion about a business' users without explicitly asking "who do you think your users are?" That approach seemed rife with canned answers; I was looking for something different.

"Hire Your Users" is technique that would be applied in early discovery to start defining these boundaries. Using the metaphor of a hiring process, it helps design strategists and stakeholders collaborate on who the users are, in what order they should be considered, what they need to accomplish, and how they might do so.

In use, a facilitator would guide discussion around the following points:

What's the need?
This first question is used to start translating the business strategy and mission into tactical needs. Like hiring for a position, it uses the business objectives as input and defines how these can be accomplished. Often, this information is known and socialized; hopefully, the facilitator will not need to dwell too long here.

Who do we hire?
This question is starts to map those business needs to user segments and define their characteristics. To do this, we would use a job description to organize and divide the users. Doing so places rigor around each segment to reduce misinterpretation. Within each description are the following:

• Job title - a succinct phrase that defines the user type
• Position summary - this focuses on the core mission and goals of the user
• Responsibilities - the tasks they must perform to support the goals
• Experience - their background, knowledge, traits and capabilities

How will they accomplish this?
This question starts to elicit the features and content that may be needed to support the user's responsibilities. Demonstrating this relationship is important since it helps ensure technology is driven by business need and not the other way around. It should also help ensure that features are justifiable and not simply faddish.

What can we offer?
This question is about trade-offs. For this task, the participants are given a personnel budget of $100,000. Using a divide-the-dollar approach, they apportion that sum among all of the job descriptions. The result is a rough indication of the order and degree of priority of the segments.

 

---

I've just hacked together this idea, so I'm hoping to hear your thoughts. Take this further? Abandon it immediately? 

When people asked me what a “user experience” designer does, I usually gave them the following answer: “I try to make software easier to use.” Simple and approachable, and without the arm-waving, chest-puffing that we UXDs sometimes use to justify what we do.

After reevaluating that canned response, I realize I was wrong.

As a UX designer, what I’m really after is trying to make software more pleasurable, which is not the same as easier. Pleasure is larger than that, and includes wonder, exploration and serendipity. Sometimes, easier isn’t always better.

Case in point, I like espresso. Scratch that–I have a real problem with it, in the way that addictions can creep into and start to change a person’s life. I’ve invested in $200+ coffee grinders. I go out of my way to buy beans in small batches from people who roast it that day. I adapt my grind for humidity and time my doppios to hit the 25-27 second mark. I’ve measured my tamp pressure to 30lbs using a bathroom scale. I’ll probably start roasting at home unless someone stops this sordid affair.

For god’s sake, I’ve watched YouTube videos showing shots pulled through naked, bottomless portafilters.

Making espresso is not for the impatient or half-hearted. If you want to make it yourself, you’ve got to fully commit. No espresso-head, I argue, would consider pulling a good shot an easy task. All the elements have to be in place. Anything awry–old beans, bad water, weak tamping, too fine or too coarse grind–can lead to swill. I know because I’ve choked it down, and still do so frequently.

But I’m learning.

I love the process simply because it is not easy. Actually, it’s the opposite. It’s a wonderful challenge, with a delicious reward. The learning curve is part of the fun, in a way that mastery of an art should be. If easy was what I was after, I’d head down to the local indie coffeehouse and plunk down my 2 bucks.* Further, if I was conducting a usability test on the process, I’d have to conclude that it completely fails. But that disregards the other intangibles, such as the thrill of mastery.

So, to say that “user experience” is always about making things easier isn’t the whole story. User efficiency is definitely a factor, but not singularly so. Delight and engagement–often the byproducts of ease of use–are higher objectives to work toward. It all depends upon the context; ease of use is simply one factor to consider.

* This is hypothetical. I haven’t found a place nearby that does a decent job of espresso. I won’t name names, but let’s just say that I’m underwhelmed with what I’ve received at the ITB Raleigh coffeehouses.

It's Friday, which means I'm debating the usefulness of wireframes again. Wireframes, for the new and uninitiated, are like "stick-figures" of a website. They indicate importance, organization and functionality of a UI but do so in a way that tries not to be too descriptive of the design. There's a certain amount of layout and organization that is implied, but we try to make sure that we don't tie designers' hands too much.

And it doesn't always work.

At capstrat , our designers and developers do some really powerful work. What's more, they get user experience and usability. So as a UX designer here, I'm in a position where steely control over the design isn't always necessary. In many cases, it's not appropriate since it impinges on designers' and developers' abilities to better deliver a product. Wireframes, unfortunately, can be seen as very prescriptive. Using them can minimize the contributions and expertise of people whose experience is essential to the design.

So, where does that leave us? Well, there are alternatives - page description diagrams being one. I won't go into them too deep here (you can read for yourself here), but suffice it to say that I'm underwhelmed with them. Mostly, they seem to be too vague. They're too prone to error and misinterpretation and are uneven on detail. What's more, they lack the basic information to communicate page-level organization and choreography. As a UX designer, I feel that page description diagrams simply abdicate way too much of what is my responsibility.

But wireframes are also good. They set boundaries of expectations to clients and are concrete in a way that prosaic descriptions can't match.

So, is there a middle ground? I think so, and here's an idea I've been banging around. I call it Pidgin.

Pidgineering

Pidgin dialects arise as a common ground between speakers of different languages. They mix terms from both and create a hybrid. I'm extending the analogy to UX deliverables. In this case, I'm interested in finding a common ground between designers, UXDers and developers. The goal is to create a vocabulary that conveys capability and choreography but is less prescriptive of the design. For the impatient, here's what it looks like:

Essentially, Pidgin is based upon three concepts: blocks, relationships and views. Here's the legend:

Blocks

The idea is to identify meaningful blocks of content and function, and show how they relate to one another. What's a block? Well, that's up to you, but essentially it's a distinct piece of function or content that can be usefully separated. A block is somewhere in the middle. So, a textfield probably wouldn't be a block, but a collection of fields and the submission button would be.

Relationships

Blocks relate to each other through relationships, which are...wait for it...lines. With arrows! Arrows describe the relationship; the pointy end shows what the block belongs to. By default, a single arrow means that the block will only occur one time for the other block.

There can be double arrows too. These indicate multiplicity: that a block can occur many times within another. In an article listing, for example, an article block might appear many times.

The lines themselves are either solid or dashed, indicating the block is required or optional respectively. If you want to get all crazy with it, you can use an open ended arrow to indicate multiple states of an object. Personally, I would discourage this except for trivial states of change. You're better off showing the default state and creating a storyboard for the block that shows how it acts in other situations.

Views

Remember when I said that content blocks related to one another? You might be thinking: but to what do they eventually relate? Views. A view is your page. It can inherit from more basic pages if you want, but that's not necessary. For example, you might abstract the global navigation and relate it to a more generic view. This is shown in the diagram above. Overall, though, a view aligns to an entry on your sitemap.

Is there a catch? There's gotta be a catch.

Yes, Virginia and it's something I'm wrestling with. Pidgins aren't testable-at least, not testable in a conventional sense. You could place this in front of a user and ask them to complete a task, but the results wouldn't be valid in the final design. You could get an idea of gaps and missing functionality, but not a whole lot more. You might be able to test each block, but that's really not useful either since it doesn't test the choreography, which is critical. As a tool to engage both development and design, however, pidgins seem useful in the early stages of the design lifecycle.

Thoughts?