Field Notes Inside an Integrated Communications Agency

Experience design is a primary component in creating successful, high-performance Web sites.  We've come to learn this over the last few years mainly because of the plethora of Web sites available that are not optimized for the user.  But is this a new problem?  I don't believe so.  Since the beginning of design, there's been bad design and in many ways we need bad design to appreciate good design.  The lack of well-crafted experiences on the Web seems like a new problem because bad designs of the past didn't make it to the consumer.  Organizations were motivated by the high cost of producing stores, workspaces, brochures, reports and advertisements to make sure that they produced something of value to their audience.

I recently took a trip to IKEA, a worldwide home furnishings store, and instead of carrying a shopping bag I put on my UXD binoculars and made a few observations. 

Consistency

The first thing I noticed was a line of shopping carts and bags at the entrance.  The sign read something like "borrow one now if you like, but we'll have them right where you need them when you do."  This reminded me of providing a consistent set of controls on each page allowing users to search or contact a real person whenever they need to.

Call to action

In the showroom the aisles were marked with large blue arrows to remind you of which way you were heading.  This funnels shoppers through a guided tour of different household rooms showcasing IKEA products.  This is like having a clear call to action on each page.  It lets the user know exactly what to do next. 

A clearly labeled alternative

This semi-guided tour was long and prohibitive to running in and looking at only one part of the show room.  The folks at IKEA addressed this problem by providing shortcuts to other sections of the store, but not without proper warning.  Signs stated exactly what parts of the showroom you would miss seeing if you took the shortcut.  This is much like providing users with more than one choice on a page enabling them to explore and experience information instead of pushing it upon them. 

On the other hand, IKEA wants you to experience the entire showroom, so these shortcuts were a bit difficult to find.  Nevertheless it illustrates the need for good labeling and sufficient explanations to help users realize the results of selecting an option before they decide to click.

Contextual grouping

Pricing in the showroom was also clear; anything which was displayed in a group had an accompanying sign that told the total price of all items in the display.  This keeps users from having to figure things out on their own, because the information is readily available and contextually placed.

The right tool, right when you need it

There wasn't a lack of tools to help you make decisions.  Several racks were placed throughout the store with measuring tapes, pencils and notepads.  This touch resonated with me quite well.  It reminded me of configuration tools and wish lists in an online shopping site.  They're readily available and easy to use should you need them. 

Navigation just the way I like it

I must admit that this was my first IKEA trip, and I was feeling a little disappointed that the store was set up as a showroom.  I prefer to look at products by type instead of context.  I was hoping to see racks full of categorized products that I could choose from.  This was when they surprised me.  At the end of the showroom tour the helpful blue arrows pointed me to the "self-service area" full of categorized products, but not without a prominent warning on the floor that I might need a cart going forward.  This is not to say that everyone prefers items a type-based organization, but that it's helpful to see the products both contextually and categorically, and allow the visitor to choose one or both.

 

The dedication to a shopping experience is one of the things that makes an IKEA store unique and I think they have the right to call it "a major retail experience" as stated on their Web site.  So the next time you have a shopping experience, put on your UX binoculars and take note of the carefully crafted design, or lack thereof.

Thanks to Geoff our UXD Intern for making the trip with me on foot after a long day of traveling.  Expect to hear more of out insights this week as we attend Adaptive Path's UXIntensive in Minneapolis.

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.

It was announced today that troubled movie renter Blockbuster offered to buy troubled gadget seller Circuit City.

Never mind that analysts are scratching their heads on the economics, I’m intrigued that this signals a rapidly approaching new era of on-demand cocooning. This is just another sign of change that Blockbuster started twenty years ago.

I grew up in Raleigh with only a handful of big movie houses. One was The Cardinal Theatre. With two huge screens, great concessions and midnight showings every weekend, it was always packed. Sometime around the early 1990s, The Cardinal Theatre was replaced with…wait for it…a Blockbuster. It’s sadly ironic isn’t it? After all Faith Popcorn told us cocooning was the new wave back in the 90s.

My, how things progress. “The deal is a sign that Blockbuster doesn't have confidence in the retail video rental business anymore, says Shahid Khan, a partner at IBB Consulting. The movie rental store business is officially dead.”

The Blockbuster that replaced The Cardinal was closed a few years ago when the chain began facing online competition.

If designed correctly, the merger could result in a new customer experience for both companies. The new “CityBlock” or “CircuitBuster” has a chance to reinvent itself in a way that satisfies the entertainment buff in everyone. I just hope they understand that today’s retail environment HAS to be about the experience. Customers have easy online alternatives.

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?

While wandering up 5th Avenue, we were shocked by the lines outside Lord and Taylor as people waited to catch a glimpse of animated store windows not so subtlety pimping this year's holiday wares. Further up the street, we saw lines by a similar display for Bank of America. With both my husband and I former and current bank marketers, we stopped to check it out (besides a crowd always garners attention). Much like the store windows at Lord and Taylor, Bank of America's "gift box" touted storefront financial vignettes. Touch the window with your hand and the scene animates, coming to life to expand on a holiday inspired financial story captured in both the audio played and text easily readable on the window. Still not intrigued to enter "the box", maybe one of the ladies in holiday sweaters (just like the ones your grandma gives), inviting you in and luring you with hot cocoa is just the enticing you need.

The whole concept, reminiscent of the type of interaction experienced at a children's museum, was not only intriguing and appealed to all five senses it was also contextually appropriate. 

• The timing, Black Friday: one of the biggest shopping days of the year.
• The weather, freezing: cocoa indeed!
• The placement, 5th Avenue: window shopping heaven.
• The emotion, nostalgia: Christmastime, wooly sweaters, gift boxes....

Seeing a bank break into experience design was truly refreshing - the hot cocoa wasn't bad either.

In the Web 2.0 world users are acustomed to defining their own Web experiences.  This has left many of the more risk adverse organizations and companies scratching their heads looking for new ways to position and target their content to specific groups of users while not relinquishing too much control (e.g. allowing un-moderating commenting).

For a recent Web client with small sales force embedded on the streets in local markets throughout the country, we proposed positioning unique and specific sales messages to potential customers based on geographic identifiers associated with their IP address. Our client was up for the content management challenge and the functionality was delivered. The feature included the ability for user’s to change their location, in the case that the IP derived location was inaccurate.

Is this a foolproof solution? Are the objections outweighed by the benefits?

Think about how must time could be save and experiences improved if you didn't have to go through one of those "gateway" pages asking you for your country and language preference everytime you wanted to visit a large transnational company or organization's site!