Boxes and Arrows » Interactivity Boxes and Arrows is devoted to the practice, innovation, and discussion of design; including graphic design, interaction design, information architecture and the design of business. Tue, 26 Aug 2014 17:41:54 +0000 en-US hourly 1 User Experience Go Away Tue, 13 Nov 2012 18:20:05 +0000 There is no UX for us

That’s right! I said it. For us (designers, information architects, interaction designers, usability professionals, HCI researchers, visual designers, architects, content strategists, writers, industrial designers, interactive designers, etc.) the term user experience design (UX) is useless. It is such an over generalized term that you can never tell if someone is using it to mean something specific, as in UX = IxD/IA/UI#, or to mean something overarching all design efforts. In current usage, unfortunately, it’s used both ways. Which means when we think we’re communicating, we aren’t.

Of course there is UX for us

If I was going to define my expertise, I couldn’t give a short answer. Even when UX is narrowly defined, it includes interaction design (my area of deep expertise), information architecture (a past life occupation), and some interface design. To do it well, one needs to know about research, programming, business, and traditional design such as graphic design as well. Once, to do web design you had to be a T-shaped person. This is defined as a person who knows a little bit about many things and a lot about one thing. Imagine a programmer who also understands a bit about business models and some interface design. But as our product complexity grows, we need P and M shaped people–people with multiple deep specialties. To design great user expereinces, you need to specialize in a combination of brand management, interaction design, human-computer factors and business model design. Or you could be part of a team. The term UX was welcomed because we finally had an umbrella of related practices.

Of course, we don’t all belong to the same version of that umbrella. We all bring different focuses under the umbrella, different experiences, mindsets, and practices. While we can all learn from each other, we can’t always be each other.

But trouble started when our clients didn’t realize it was an umbrella, and thought it was a person. And they tried to hire them.

It isn’t about us

If there is any group for whom UX exists now more than ever it is non-UXers. Until 2007, the concept of UX had been hard to explain. We didn’t have a poster child we could point to and say, “Here! That’s what I mean when I say UX.” But in June 2007, Steve Jobs gave us that poster child in the form of the first generation iPhone. And the conversation was forever changed. No matter whether you loved, hated, or could care less about Apple, if you were a designer interested in designing solutions that meet the needs of human beings, you couldn’t help but be delighted when the client held up his iPhone and said, “Make my X like an iPhone.”

It was an example of “getting user experience right.” We as designers were then able to demonstrate to our clients why the iPhone was great and, if we were good, apply those principles in a way that let our clients understand what it took to make such a product and its services happen. You had to admit that the iPhone was one of the first complete packages of UX we have ever had. And it was everywhere.

Now five years later, our customers aren’t saying they want an iPhone any more. They are saying that they want a great “experience” or “user experience.” They don’t know how to describe it, or who they need to achieve it. They have no clue what it takes to get a great one, but they want it. And they’ll know it when they see it, feel it, touch it, smell it.

And they think there must be a person called a “user experience designer” who does what other designers “who we’ve tried before and who failed” can’t do. The title “user experience designer” is the target they are sniffing for when they hire. They follow the trail of user experience sprinkled in our past titles and previous degrees. They sniff us out, and “user experience” is the primary scent that flares their metaphorical nostrils.

It is only when they enter our world that the scent goes from beautiful to rank. They see and smell our dirty laundry: the DTDT (Defining The Damn Thing) debates, the lack of continuity of positions across job contexts, the various job titles, the non-existent and simultaneously pervasive education credentials, etc. There is actually no credential out there that says “UX.” Non! Nada! Anywhere. There are courses for IxD, IA, LIS, HCI, etc. But in my research of design programs in the US and abroad, no one stands behind the term UX. It is amorphous, phase-changing, and too intangible to put a credential around. There are too many different job descriptions all with the same title but each with different requirements (visual design, coding, research being added or removed at will). Arguably it is also a phrase that an academic can’t get behind. There aren’t any academic associations for User Experience, so it’s not possible to be published under that title.

Without a shared definition and without credentialed benchmarks, user experience is snakeoil. What’s made things even worse is the creation of credentialed/accredited programs in “service design” which take all the same micro-disciplines of user experience and add to it the very well academically formed “service management” which gives it academic legitimacy. This well defined term is the final nail in the coffin, and shows UX to be an embattled, tarnished, shifty, and confusing term that serves no master in its attempt to serve all.

“User experience design” has to go

Given this experience our collaborators, managers, clients and other stakeholders have had with UX; how can we not empathize with their confused feelings about us and the phrase we use to describe our work.

And for this reason UX has to go. It just can’t handle the complexity of the reality we are both designing for and of who is doing the designing. Perhaps the term “good user experience” can remain to describe our outcomes, but user experience designer can’t exist to describe the people who do the job of achieving it.

Abby Covert said recently that the term UX is muddy and confusing. Well, I don’t think the term “user experience” is confusing so much as it’s a term used to describe something that is very broad, but is used as if it were very narrow. There is a classic design mistake of oversimplifying something complex instead of expressing the complexity clearly. UX was our linguistic oversimplification mistake. We tried to make what we do easy to understand. We made it seem too simple. And now our clients don’t want to put up with the complexity required to achieve it.

Now that the term has been ruined (for a few generations anyway), we need to hone our vocabulary. It means we can’t be afraid of acknowledging the tremendous complexity in what we do, how we do it, and how we organize ourselves. It means that we focus on skill sets instead of focusing on people. It means understanding our complex interrelationships with all the disciplines formerly in the term UX. And we must understand that they are equally entwined with traditional design, engineering and business disciplines, communities, and practices as they are to each other.

So I would offer that instead of holding up that iPhone and declaring it great UX, you can still use it as an example of great design, but take the simple but longer path of patiently deconstructing why it is great.

When I used to give tours at the Industrial Design department at the Savannah College of Art and Design (SCAD) I would take out my iPhone and use it to explain why it was important that we taught industrial design, interaction design, and service design (among other things). I’d point to it off and explain how the lines materials, and colors all combined to create a form designed to fit in my hand, look beautiful on my restaurant table, and be recognizable anywhere. Then I would show the various ways to “turn it on” and how the placement of the buttons and the gesture of the swipe to unlock were just the beginning of how it was designed to map the customer’s perception and cognition, social behaviors, and the personal narrative against how the device signalled its state, what it was processing, and what was possible with the device. And I explained that this was interaction design. Finally, I’d explain how all of this presentation and interaction were wonderful, but the phone also needed to attach a service to it that allows you to make calls, where you can buy music and applications and that the relationships between content creators, license owners, and customers.

At no time do I use the term “user experience.” By the time I’m done I have taught a class on user experience design and never uttered the term. The people have a genuine respect for all 3 disciplines explored in this example and see them as collaborative unique practices that have to work intimately together.There is no hope left in them for a false unicorn who can singularly make it all happen.

]]> 8





Trouble with the definition, not the word



Grandiose UXD




The web gave us UXD




Interaction design






Disciplinary distinctions



“User experience design” creates an uneasy truce





Interactive systems, not just the web




More than just interaction design







]]> 0
Novices Orienteer, Experts Teleport Wed, 20 Apr 2011 07:22:28 +0000 Would you rather take a photo using your phone, a point-and-shoot camera, or a digital SLR? How you answer this question is probably a good indicator of your photographic expertise. If you snap casual shots, your phone or a point-and-shoot camera will probably suffice. If you’re a professional photographer, on the other hand, you probably prefer using an SLR that gives you control over the focus, aperture, and exposure.

Expertise significantly impacts how we seek information online. Just as novice and expert photographers prefer different tools, so novices and experts behave differently when searching for information. Understanding these differences will help us design better search interfaces for both groups of users.

There are experts, and then there are experts

User expertise exists on two levels. If you’re an avid photographer, your domain expertise in photography will be quite high: that is, you’ll be familiar with the terms and techniques of the trade. Each of us is likely a domain expert in a few areas, and a complete novice in others. A second aspect is technical expertise. Familiarity with how computers, the internet, and search engines work significantly impacts how users seek information. Consider these personifications of each quadrant of expertise:

Image 1 - Quadrant comparing domain versus technical expertise

* *Angela Baer*, since completing her MFA at Pratt 5 years ago, is quickly building a reputation as one of New York’s up-and-coming fashion photographers. In the office connected to her studio, Angela edits her photographs on two large monitors and top-end computer. She delivers the edited shoots electronically to her clients, and regularly updates her online portfolio and blog. Angela is highly proficient using her computer, and when it comes to photography, she’s a domain expert.

* Though officially retiring over 10 years ago after a successful career in banking, *William Hayes* still sits on the board of a number of financial institutions. From his Elizabethan cottage on the Kent coast, he uses a 5-year old computer to exchange emails and access financial reports, though he prefers doing business on the phone and keeping up with the world though The Financial Times. While William is a domain expert when it comes to finance, his technical expertise is lacking.

* 18-year-old *Fane Tomescu* helps run an internet cafe in Braşov, Romania. Having saved for over a year, Fane recently came across a car that he’s considering purchasing. But when the time came to arrange car insurance, Fane had no clue how things worked. He asked his parents and friends for advice, and then spent several hours comparing providers online. Fane is a technical expert, but when it comes to insurance, he’s a domain novice.

* *Claire Jones* is a 9-year-old from Colorado Springs. Her school is holding a science fair and Claire has decided to build a model of the solar system using styrofoam balls suspended with string. Having left her science textbook in her locker over the weekend she was meant to start building the model, Claire used the internet to lookup information on the order, size, and appearance of each planet. Though she did eventually find what she was looking for (with her parents help), Claire would be considered both a technical and a domain novice.

While either dimension of expertise is valuable, users are most likely to succeed when both are present. There are, however, a number of design guidelines which can help both novices and experts succeed in their pursuit of knowledge.

Novices Orienteer

Image 2: An orienteer at the 2010 World Orienteering Championships in Trondheim, Norway. Photo by Torben Utzon.


Wayfinding is a challenge as old as humankind, but the discipline of orienteering originated in the Swedish military in the 1800s and is now a sport practiced throughout Scandinavia. Equipped with a map and compass, participants navigate between control points spread across many miles, making tradeoffs between distance and difficult terrain as they strive to complete the course in the shortest amount of time.

The strategies employed by novice users seeking information resemble the sport of orienteering. [1] Users with low levels of domain and technical expertise, typified by Claire Jones, share three main characteristics.

Short queries

Novices tend to enter queries that use about half as many words as experts.[2] Domain novices (like both Claire and Fane Tomescu), feel particularly unsure of which terms to use.

Many queries

Novices perform more queries than experts, but look at fewer documents. Although they frequently reformulate their query, technical novices often suffer from an anchoring bias [3] and make only small, inconsequential changes.

Going back

Novices are much more likely than experts to hit dead ends and seek to get back to a previous state.

These behaviours result in an orienteering-like strategy where novices “test the waters” with a short, general query, quickly skim the top results returned, and immediately reformulate the query based on their improved knowledge of the subject. [4]

Design considerations for Novices

There are a number of design considerations which can help novice users succeed at orienteering. In particular, novices need help formulating their query, refining their query, and backing out of trouble.


As-you-type suggestions can help users get off on the right foot when they’re uncertain what to search for. Research has shown [3] that users are more capable of choosing a viable option from a list than they are of composing a question out of thin air. Autosuggest provides an opportunity to help users express specific terms (such as airports or stocks), and to suggest queries that other users have performed in the past.

Image 3: Autosuggest on
Image 3: Autosuggest on

Related searches

After users have performed an initial search, they may still need help refining the query. A list of related searches can help the user break out of their anchoring bias and help them arrive at the optimal set of results.

Image 4: place related searches on the same line as breadcrumbs.
Image 4: place related searches on the same line as breadcrumbs

Avoid zero results

If the user is presented with no search results, he may be disheartened enough to give up his quest. Avoid zero-result screens if possible. Tools such as automatic spelling corrections and query expansion (using synonyms and lemmatisation,[5] for instance) can help.

Image 5:'s handling of zero results
Image 5:’s handling of zero results


Because novices tend to take wrong turns, they often need help navigating back to a previous state. Breadcrumbs are an ideal solution because they communicate both the user’s current location, as well as how to go back.

Image 6: Breadcrumbs on
Image 6: Breadcrumbs on

Experts Teleport

Image 7: In Star Trek, crew members of the USS Enterprise stand on transporter platforms to be beamed down to a nearby planet.


While novices orienteer, experts teleport. Akin to being teleported to a precise but distant location, users with high domain and technical expertise like Angela Baer tend to jump directly to their final destination.

Longer queries

Experts enter longer, more specific queries than novices. Domain experts like William Hayes often rely on their vocabulary of specific terminology, while technical experts such as Fane Tomescu are more likely than novices to use formatting techniques such as quotation marks in their queries (87% of experts compared with 47% of novices according to a 2000 study [1]).

Fewer queries

Experts usually amend their queries less often than novices and move forward with a higher degree of confidence.

More Documents Examined

Experts tend to review more documents and follow a greater number of links within those documents. Domain experts are especially adept at quickly determining whether or not a given document is useful.

In essence, experts often construct queries using numerous highly specific words which act to teleport [6] them directly to a destination, cutting out the query reformulation often practiced by novices. After having arrived at a destination, experts are then likely to explore the surrounding territory.

Design considerations for Experts

Designing for experts involves facilitating their teleporting behaviour, helping them get to their destination as quickly as possible.

Advanced syntax

Technical experts like Fane are often willing to learn special commands in exchange for having greater control. Commonly supported operators include AND, OR, and quotes for searching for exact phrases.

Image 8: Wolfram Alpha is designed to understand domain-specific terminology and return computed answers.

Keyboard shortcuts

Keyboard shortcuts can also increase the speed of interaction. Google, for instance, allows users to press the up/down arrow keys on the keyboard to traverse results, and press return to go to the URL of the selected result.

Image 9: Google places a caret beside the currently-selected result.

Filtering & sorting

Experts are more likely to engage with advanced sort and filtering controls than novices, including operations such as selecting ranges, filtering by format, or excluding certain terms (e.g. everything that includes “apples” but does not mention “oranges”).

Image 10: Getty Image's Moodstream lets users search for stock photos using sliders.
Image 10: Getty Image’s Moodstream lets users search for stock photos using sliders.

As-you-type results

As-you-type completion interfaces most often display query suggestions to users. However, another use case is to present actual results in the autocompletion interface, enabling users to skip the search results screen altogether and go directly to a specific document.

Image 11: Rather than suggesting terms to search for, Nutshell returns search results directly without needing to go to a separate page.

Result table of contents

Providing links to the top destinations within a result can reduce the number of steps required for the expert to reach his destination.

Image 12: Google sometimes provides links to the top-level pages within a given site.

Yin and Yang

While novices and experts practice two very different approaches to information seeking, it’s important not to overemphasis one at the expense of the other. As illustrated by the ancient Chinese symbol, understanding the behaviour of both novices and experts can help us design more informed, balanced search experiences.

The author would like to thank Cennydd Bowles for organising the UK writer’s retreat during which this article was written, as well as for the editorial guidance that he provided.


[1] Vicki L. O’Day and Robin Jeffries; “Orienteering in an Information Landscape”:

[2] Christoph Hölscher & Gerhard Strube; “Web Search Behavior of Internet Experts and Newbies”:

[3] Marti A Hearst; “Search User Interfaces”:

[4] Morten Hertzum and Erik Frokjaer; “Browsing and Querying in Online Documentation”:

[5] Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, “Introduction to Information Retrieval”: , Cambridge University Press. 2008.

[6] Jaime Teevan, Christine Alvarado, Mark S. Ackerman and David R. Karger; “The Perfect Search Engine is Not Enough”:

]]> 4
Storyboarding iPad Transitions Wed, 05 Jan 2011 09:05:23 +0000 If your clients are not yet asking you to design transitions, they will likely do that on your next project. Transitions are hot, and not just because they entertain the eye. In confined mobile computing interfaces, on tablet devices or in complex virtual environments, transitions are an authentic, minimalist way of enabling way-finding, displaying system state and exposing crucial functionality – in short, they are key in creating a superior user experience.

Transitions as design elements

Since the 1980s, designers have been drawing wireframes to represent web pages and device interfaces.1 In the beginning, wireframes were static schematics that showed a single state of the page. With the emergence of dHTML in the 1990s, it became necessary to draw different states of specific dynamic page elements, so the designers adapted the wireframe methodology to document the beginning and end states of the dynamic elements. Still, designers and engineers had little or no control over what happened in between the beginning and end states — the browser or the operating system handled all transitions.

More recently, sophisticated mobile touch frameworks like iPhone, Android, Palm and Windows Mobile allowed unprecedented control over the speed and structure of the transitions, giving designers more tools with which to create a better experience in a confined mobile space.2 Simultaneously, on the web, dynamic platforms like Flash and Flex gained tremendous ground, making it possible for designers to think about and document transitions because those were now part of the customer experience.

With the release of the Apple iPad, the Age of Transition has come to its full potential. On the iPad, Apple takes full advantage of some of the principles and ideas the company previously explored and perfected using the iPhone. On the bigger iPad screen, transitions achieve a new level of detail and sophistication, making the device come alive, and become a powerful, integral part of the experience.

Transitions Require Thinking Differently

As Jonathan Follett writes in his article “Interfaces That Flow: Transitions as Design Elements”:, 3 many UX designers approach projects from a combination of information architecture and interaction design. These disciplines involve thinking that is quite different from constructing the continuous linear narratives required to design and document transitions. Nevertheless, by borrowing freely from the lessons of early animators, it is quite possible to adopt the existing wireframes methodology to convey the structure and rhythm of a user interface transition.

The task consists of wireframing each of the important changes (or “key frames”) that occur during the transition and stringing a bunch of wireframes together in a storyboard. By documenting the key aspects of the transition, it is possible to share them with the larger team and try out different transitions designs. Documenting the transitions also allows us to step back and consider them in a larger context of a specific use case or overall goal of progressive engagement and immersion.

Understanding iPad Transitions

In order to be able to design and document transitions using storyboards, we have to first understand design principles that designers of transitions use to convey the desired meaning. Let’s take a look at the Apple, Inc. video in Figure 1 showing selected transitions from what is arguably the most popular iPad application today: iTunes. Although many different transitions are shown in the video, we will be specifically looking at the two of them: “opening the iTunes application” (0:17-0:20 min) and “opening album details” (0:30 -0:36 min).

Figure 1: Video of iTunes transitions on the iPad ["View larger version on YouTube":]

Borrowing from Chet and Guy’s excellent Devoxx presentation “Animation Rules!”:,4 we can identify seven key principles that specifically apply to the animated transitions on the iPad:
# Component Relationship (background-foreground)
# Illusion (motion perception and perceptual constancy)
# Exaggeration (highlighting states, actions, and changes in state)
# Staging (camera view, lighting, focus)
# Acceleration and Deceleration (slow in and out)
# Metaphors (using real-world analogies to convey complex digital events)
# Simplicity (avoiding noise)

To understand how the seven principles above apply combine to make the transition work its magic, let’s do a step-by-step breakdown of the “opening the iTunes application” transition, shown in Figure 2.

Figure 2: Step-by-step breakdown of the “opening the iTunes application” transition.

Figure 2: Opening iTunes Application Step-by-Step

Using our seven key principles:
Component Relationship (background-foreground)
 This transition is essentially the process by which the iTunes application comes into the foreground, while the rest of the apps recede into the background. In the first row, the transition starts out with the home screen and apps icons firmly in the foreground. By the end of the row, we can see that the home screen recedes and darkens, while the iTunes app (represented by a white square) slowly comes into the foreground. By the second row, the background-foreground transition is essentially complete – we can see only the loading iTunes app against the black background.

Illusion (motion perception and perceptual constancy) 
This transition creates its magic via an illusion of “flying into” the device, and eventually meeting the white square that represents the iTunes app. To accomplish this, the animation shows us “flying” through the layer of the apps icons on the home screen. The other app icons begin to “fly” to the sides of the screen in a circular pattern, as shown in row 1. The most interesting part of the illusion is the kind of “bait-and-switch”. If you look carefully, you’ll see that the app icons never make it off screen. Just before we “pass through the icons layer” and “witness” the icons “flying off screen”, the background goes completely black, and our attention is focused on the white rectangle. The illusion is complete.

Exaggeration (highlighting states, actions, and changes in state)
In this transition, the lighting effects are used to exaggerate the switch between the background and foreground. In the second row, the background goes completely black, to highlight the change in state. Exaggeration can also be used to warp the shape of an object to emphasize movement, as in is used more in the “genie” effects and transitions.

Staging (camera view, lighting, focus) 
Subtle but powerful lighting is used throughout the transition as the primary means for focusing our attention on the foreground of the opening window of the iTunes app through subtle darkening of the background (principle 1). Lighting is also used to accomplish the bait-and-switch in the Illusion principle.

Acceleration and Deceleration (slow in and out)
 Our brains know from experience that objects do not start running at top speed or “stop on the dime”. To make the movement more life-like, the animation accelerates into the movement very slowly, picking up pace in later screenshots, as evidenced by the increasing “smudginess” of the icons in the first row. Not surprisingly, the bait-and-switch happens in the fastest moment of the transition to pull of the illusion that the homepage icons actually “fly off screen”. The transition then slows down again in the last row to smoothly fade in the iTunes content elements, deliberately giving the auxiliary page elements and pictures time to “catch up” and making the page load appear smoother.

 The most effective transitions use real-life elements to provide a frame of reference which makes the animation more realistic. In this case, the icons on the home screen are moving to the sides, creating an overall illusion of moving through space, or deeper “into” the device itself to convey a digital event of opening an application inside the device.

Simplicity (avoiding noise)
The overriding theme of this transition is its apparent simplicity. During the transition, iTunes is not doing anything particularly complicated or earth-shattering. The magic comes not from one particular element, but through carefully blending and combining the lighting and movement to create a smooth cohesive digital dance, perfectly orchestrated from beginning to the end.

Storyboarding iPad Transitions

The key to successfully designing and storyboarding the transitions is understanding and applying the seven animation principles we discussed above. To demonstrate how this can be done, let’s use a slightly more complex transition: the iTunes “opening album details”, shown in Figure 3.

Figure 3: Opening iTunes Album Details Step-by-Step

Figure 3: Opening iTunes Album Details Step-by-Step

Here again, we see the seven principles at work:
Component Relationship (background-foreground)
 This entire transition can be viewed as bringing the selected album cover into the foreground, while the rest of the iTunes application recedes slightly into the background.

Illusion (motion perception and perceptual constancy) 
The animation shows us the illusion of the album flying forward on the screen while flipping 180 degrees. The most interesting part of the illusion is the switch from darker gray “back” of the album to a while loading screen (midway through the second row). This sleigh of hand changes the focus to the white cover to make the transition believable.

Exaggeration (highlighting states, actions, and changes in state)
 In this transition again, the lighting effects are used to exaggerate the switch between the background and foreground. Midway through the second row the album turns completely white against the slightly darker background.

Staging (camera view, lighting, focus) 
In the beginning the iTunes application darkens gradually, and reaches its full saturation about half-way through the second row to create the background against which the album will be staged. The album, on the other hand, switches first from color to darker gray, then to solid white to jump to the foreground.

Acceleration and Deceleration (slow in and out)
 The animation starts slowly, and achieves top speed half-way through the second row to quickly switch from the dark gray flipping rectangle to a solid white loading page. Just as in the previously discussed “opening iTunes” transition, this transition also slows down in the last row to smoothly fade in the iTunes album cover content elements.

This transition invokes the magical feeling of opening picking the old LP album off the shelf and flipping it over to see the back cover by creating the illusion of the album jumping off the page and flipping 180 degrees horizontally around the middle.

Simplicity (avoiding noise) 
While a bit more complex than the “opening iTunes application”, this transition can nevertheless be adequately described by looking at only 12 screenshots.

Once the transition design principles are understood, the process of drawing the storyboard becomes fairly straightforward. I use the same method that Galileo Galilei used four centuries ago when he first diagrammed the step-by-step movement of the sun spots in 1613.5 The basic transition storyboard for the “Opening iTunes Details” transition is shown in Figure 4.

Figure 4: Storyboarding iPad Transitions Using Post-it Notes

Figure 4: Storyboarding iPad Transitions Using Post-it Notes ["See larger version":/files/banda/storyboarding-ipad/figure4_ipadtransitions_postitnotes_large.png]

Now Start Making Your Own Transitions

As you try your own hand in transition storyboarding, here are a few points to keep in mind:

Use appropriate materials 

To diagram transitions, I prefer to use medium-size post-it notes that measure 3-inch square. I draw each of the steps in the transition using a soft retractable pencil with a good eraser. This allows me to quickly diagram portrait and landscape transitions, and everything in between. Because the iPad is a rectangle, not a square, I leave the extra space left on the right of the post-it note (on the bottom for landscape) to write the additional explanation for each step or simply leave it blank.

Simplify shading 

As I said above, on the iPad the lighting is foundation to expressing Component Relationship, Exaggeration, and Staging principles, so it makes sense to take a disciplined approach to drawing various shades of light and dark in your storyboard. I find that the easiest approach is to draw shading on top of the picture as light lines at a 45 degree angle. As you can see in the last three post-its, I use tighter line spacing to indicate progressively darker shading.

Get the basics down first 

When I first approach the transition design, I make only the post-its necessary to convey the overall movement of the various elements and basic component relationship. I sketch quickly using very rough strokes, and use a ruler and templates whenever possible to make my job easier.

Stick to 6-8 post-its

 As you can see in Figure 4, it is not necessary to draw all 12 original key frames we saw in figure 3. To convey the basic structure of a transition, I typically try to use only 6-8 post-it notes. Using fewer steps keeps me focused on the principle of simplicity: if it takes me more than 8 post-it notes to describe the transition, it is probably too complex and I immediately look for unnecessary elements or animation that needs to be eliminated or scaled back.

Ignore Acceleration and Deceleration 

Above we spoke at length about the Acceleration and Deceleration principle. This idea is essential to creating effective, believable transitions. However, when drawing a rough storyboard of 6-8 post-its, this is the one principle that I found can be safely ignored. Once people understand this principle, most folks can extrapolate from your rough drawings to imagine the complete smooth transition “in their mind’s eye”. As long as you make it clear to your team that this is only a rough storyboard that the end result will in fact follow the principle, you can safely ignore the subject and concentrate on the relationship, movement and shading of screen elements.

Draw the complete story

 Transitions do not happen in isolation – they are an integral part of the overall customer experience. Thus, when I storyboard transitions, I typically do it in the context of the entire use case. This helps me make sure that the particular transition makes sense in the complete context and in combination with other transitions. For example, when I use the “flip” transition to show the search results on the map, and then use the “slide back” transition to go back to the list of search results, the storyboard will quickly reveal the inconsistency in the mental model of the interface I am trying to create and the problem transition will feel awkward when walking through the use entire storyboard.

Sketch a few different transition designs 

When I approach a given transition, I usually try out 3-4 different design approaches to see which transition creates the effect I am seeking. Sometimes I find that I need to create 10 or more sets of ideas for more complex and critical interactions. The point of this initial sketching is not to create the complete and final blueprint, but to help you visualize how a given transition design option would feel with the rest of the app interactions. Doing the transition with post-it notes allows me to quickly add a new transition or re-position the existing post-its to create and try out several different scenarios, often while engaging in the active team discussion. I recommend you make copies or take photos of your boards periodically to preserve promising design directions before repositioning the post-it notes and changing the transition layout again.

Obtain Initial Stakeholder Approval

 In addition to helping you find the best design approach, a rough storyboard is also a fantastic tool for conveying various design options to your team for joint discussion and brainstorming as well as for obtaining initial stakeholder buy-in. It’s a lot easier to discuss the merits of a particular transition movement and information architecture when everyone is quite literally on the same page looking at your complete use case storyboard.

Creating the Final Transition Blueprint

When you obtain the initial stakeholder approval using your rough storyboard drawing, you will need to document the final storyboard design that the engineers to actually create. Here you have a couple of options.

One approach is to use Flash to create the transition with the final high-fidelity look and feel. This is certainly a valid option. However, I found Flash to be more useful for higher-fidelity usability testing and final stakeholder approval than for describing transitions to engineers. Here is why: most developers do not read Flash code and most transitions are simply too fast for the eye to understand in detail the subtleties of acceleration and shading simply by looking at a running a Flash file. I have had several instances of getting not exactly what I specified or else getting something completely different, only to have the engineers claim that “this is exactly what the Flash looked like”. This is especially a big problem with distributed multi-lingual teams where communication is an issue.

The method that I found to work well is to specify (e.g. create a wireframe for) each of the frames at regular intervals of every 50-100 milliseconds for the entire duration of the transition. Most transitions are between 0.5 – 1.2 seconds, so you will need to create anywhere between 5-24 wireframes in your favorite wireframing tool such as Fireworks, OmniGraffle or Visio. Stringing these frames together in document pages will create a short movie that will comprise the complete blueprint that will describe the position, shading, and movement of each element that will communicate clearly and exactly so the engineers can create the exact transition you envisioned.

While this seems at first like a lot of work, after a bit of practice the wireframing goes fairly quickly, as the difference between the each new page and the one before it is only a slight change in position and shading. As long as we firmly keep in mind the principles by which iPad transitions work, we can easily diagram relevant steps for rich, expressive transitions.

To continue this conversation, add a comment below or reach out to Greg at “@designcaffeine”: or through his website, “”:

Interested in more UX sketching techniques? Join us Saturday, May 28th, 2011 at UX SketchCamp ["": or "@sketchcamp": on Twitter] in San Francisco for a chance to learn from the experts, practice UX sketching and share what you know with others.


1. “Wireframing Marathon Starts”:; CIO Happy Hour, September 2010

2. See my article “Designing Mobile Search: Turning Limitations into Opportunities”:; UX Matters, March 2010.

3. Jonathan Follett; “Interfaces That Flow: Transitions as Design Elements”:; UX Matters, July 2007

4. Chet Haase and Romain Guy; “Animation Rules!”:; Devoxx ’09

5. Galileo documented the movement of the sun spots in his triumphant “Istoria e Dimostrazioni Intorno Alle Macchie Solari e Loro Accidenti Rome”: (History and Demonstrations Concerning Sunspots and their Properties); 1613.

]]> 15
Designing for Social Interaction Fri, 09 Apr 2010 07:48:50 +0000 It took both the telephone and the mobile phone 15 years to amass 100 million users, but Facebook did it in 9 months. We see more and more people becoming connected on online social networks, and it seems our networks are growing exponentially. But the reality is, social networks rarely add to our number of connections. We’ve already met almost all the people we’re connected to on social networks. We’re already connected to these people offline. Social networks simply make the connections visible. For example, we often connect with old school friends, and catch up over a couple of wall posts. But rarely do we continue the conversation once we’ve connected, and over time we forget that the connections exist. In fact, Facebook users often have no interactions with up to 50% of their connections.1 When we study how people are interacting on social networks, we see that most interactions are with a very small subset of the people we’re connected to.

The average number of friends on Facebook is 130, and many users have many more.2 Yet despite having hundreds of friends, most people on Facebook only interact regularly with 4 to 7 people,3 and for 90% of Facebook users, 20% of their friends account for 70% of all interactions.4 We also see this with phone usage. We have hundreds of people in our phone contacts, yet 80% of phone calls are made to the same 4 people. We know dozens of people who use Skype, yet 80% of Skype calls are made to 2 people.5 Even when people play computer games online, they mostly play with people they know offline.6

We also have varied interactions with the people we’re not as close to. We find out about new jobs, not through our friends, but through friends of friends. When our friends’ friends’ friends lose weight, we lose weight.7 We go onto eBay and buy things for hundreds and thousands of dollars from people we’ve never met, and will probably never interact with again.

We have many diverse relationships with the people in our lives, yet the web doesn’t support this very well.

the web doesn't support different layers of relationships very well

On Facebook (left), all my “friends” are treated equally. I’m presented with a long alphabetical list. Some of these people I would trust with my deepest secrets, and there are others that I’ve met less than five times. Yet they are grouped together in a big bucket of “friends”. Of the people who are “friends” with me on Facebook, there are many that I wouldn’t call a “friend”. I may call them an acquaintance, or a colleague, or even a family member, but they’re not in the same category as my closest friends.

In my phone (right), all my contacts are treated equally. I’m presented with a long alphabetical list. My best friend is given the same number of pixels as someone I haven’t spoken to in 5 years. I may be able to access my most frequently contacted people via a ‘Favorites’ tab, but these people are still presented in the same way as the people I’ve lost touch with. On LinkedIn (right), all my connections are treated equally. Yet I have worked with some of them every day for years, and there are others that I met once at a conference.

Our social web tools must start to understand the strength of ties, that we have stronger relationships with some people than with others. And with this knowledge they need to adapt.

There are three kinds of relationship ties:

  • Strong ties: People we care deeply about.
  • Weak ties: People we are loosely connected to, like friends of friends.
  • Temporary ties: People we don’t know, and interact with temporarily.

Let’s look at each type of tie, and how we might design for them.

Most people have less than 10 strong ties

For decades, people have talked about social networks being made up of strong and weak ties. Think of the people in your life. Think about your closest friends, the people you are closest to in your family. These are examples of your strong ties. Strong ties are the people you care about most. People often refer to strong ties as people in their “circle of trust”. Strong ties often wield the most influence over people’s decisions.

Most people have very few strong ties, usually less than ten. A study of 3000 randomly chosen Americans showed that the average American has just four close social contacts (four strong ties). Most Americans have between two and six strong ties. People’s strong ties come from a variety of places. About half of the strong ties are said to be friends. The other half includes spouses, partners, parents, siblings, children, co-workers, fellow members of clubs, neighbors, and professional advisors and consultants.8 In both 2002 and 2007, a study of 1,178 adults found that on average, people had about 10 friends they meet or speak with at least weekly (10 strong ties).9 So, when we’re designing for strong ties, we’re designing for small groups of people.

Some people believe that this is changing, that the web is making us closer to more people.10 On the contrary, research studies have shown that the vast majority of usage on social networks is between strong ties. As we saw earlier, on Facebook it’s with 4 to 6 people, with phone calls its with 4 people, and with Skype it’s 2 people. When people play online computer games with others, they are mostly interacting and playing with people they know, often with people who live less than a few miles away. This pattern of technology being used for strong tie communication is not new. When the telephone was invented, it did more to expand and strengthen strong ties than to weaken them. A study in the 1970s showed that the majority of phone calls were to people who live within five miles of the caller’s home.11

When designing for strong ties:

  • Think about their existing means of communication. Phone calls, text messages, email. Strong ties already have established ways to interact, we should support them, and not try and replace them with our own messaging systems.
  • Showing more information about the ten closest people is likely to be much more valuable than showing less information about many more people.
  • Avoid generic terms such as “Friends”. This will likely lead to over-populating groups and reducing their relevance.
  • Suggest connections to people, but communicate the effects of adding new connections.

People have about 150 weak ties that they stay up-to-date with

Moving away from your strongest ties, think about some of your friends’ friends. People you don’t know so well. These are examples of your weak ties. Weak ties are people you know, but care less about. These are the people that are loosely connected to you. Weak ties are people you wouldn’t feel uncomfortable stuck in a elevator with, yet don’t feel much emotional closeness to.

In the 1970s, the sociologist Marc Granovetter wrote a seminal paper about the strength of weak ties. He concluded that weak ties are often a much better source of information than strong ties. As our strong ties are a very small circle, weak ties can be a more powerful source of information and advice. Studies show that most people can only stay up-to-date with 150 weak ties in real life. This pattern has been true for thousands of years. Neolithic villages tended to separate into two once they reached 150 inhabitants, the Roman army was split into groups of 150, so that everyone knew each other.12 It is still true today, online and offline. We are connected to many more than 150 weak ties, but don’t stay in touch with them. We may be connected to hundreds of people on Facebook, but we would struggle to tell anyone what is going on in all of their lives.

In social networks, weak ties can sometimes be very useful, for example, connections on LinkedIn can help you find a new job, a friend of a friend can give you advice on a specific topic. Yet sometimes, weak ties on social networks can lead to awkward social situations, for example, receiving unwanted Facebook invites from people you don’t know very well.

When designing for weak ties:

  • Consider the trade-off between communication and trust. Weak ties may be more knowledgeable about something we’re interested in, but we may trust them less. It may be important to show our other shared ties, or expose their sources of knowledge, so that we can increase the trust between people.
  • Make it easy for people to expose their networks to people they trust with that data. This will open up links between weak ties, without compromising user privacy.
  • Enable appropriate communication channels between weak ties. It may be better to go through, or highlight, a shared strong tie.

The web is increasing our interactions with temporary ties

Strong and weak ties are not enough when we think of relationships online. We need a new category of tie – the temporary tie.

Temporary ties have always existed, but the web is bringing them to the fore. Think about some people you’ve only interacted with once. You don’t actually know who they are. A store assistant, a call center employee, the person you bought from on eBay. These are examples of your temporary ties. Temporary ties are much more common online than offline. They are people that you have no recognized relationship with, but temporarily interact with for a specific reason. Once the task has been completed, temporary ties are unlikely to interact again. You don’t know these people beyond the words they typed, and whatever online profile they have. With the rise of online user generated content, temporary ties are becoming more important.

Following are four common types of temporary ties:

  1. People sometimes interact with temporary ties around an information need. People needing information seek people with knowledge of the answer. Once the request for information has been fulfilled, interaction with these ties usually ceases. You may ask a person in the street for directions, or online you may seek information from people on Yahoo! Answers. This type of temporary tie is increasingly important for the future of web search. People are looking to other people, rather than businesses, to answer certain queries.
  2. Temporary ties also exist when people need to temporarily interact to complete a task. Once the task is completed, interaction ceases. For example, interacting with a sales assistant in a shop, or having a plumber in your house to fix a leaking pipe. Many of these tasks are now online, for example interacting with a call center representative to arrange cable installation, or buying something from a temporary tie on eBay.
  3. Temporary ties can form around a shared ongoing interest such as a sports team or hobby. Interaction can often happen on a community website, for example a sports team forum. The true identity of these ties can remain unknown. One some of these sites, frequent posters start to recognise each other and each other’s behaviour. Although they likely have never met, their relationship can move from temporary tie to weak tie. There are an increasing number of examples where temporary ties interact online, and meet offline.
  4. People often form temporary ties with people sharing the same physical space. These ties can be as simple as a 1 minute conversation on the street, or as complex as an intermittent 3 day conversation at a music festival. Technology now allows us to communicate with temporary ties who shared the same physical space with us, albeit not at the same time. We can use our phones to see who has previously been to the restaurant we’re considering, what they ordered, and whether they thought it was any good.

Because we have no relationship history with our temporary ties (unlike with our strong and weak ties), representing identity and reputation are critical for successful interactions. We need to know that the eBay seller is trustworthy. We need to know that the medical advice we’re reading is from an actual doctor, and not someone pretending that they are a doctor. We need to know that the restaurant review is from someone who knows about food, and that the Amazon review wasn’t written by a company employee.

reputation building

On Yahoo Answers, people can build their reputation in different ways. On the left, “Messykat” is building her reputation by trying to provide the best answers to questions. She may be helpful in 20% of cases, but we still don’t know much about her credentials as an expert in any of her 3 specialty areas (Cats, Dogs, Weddings). On the right, “RuthAnn” is trying to build her reputation by stating that she “has been training dogs for 40 years”. This only adds a superficial layer of credibility, as we can’t verify if it is true.

building trust by positive feedback from temporary ties

On eBay (left), “jmjenkins” is building trust by getting positive feedback from temporary ties who have dealt with him in the past. Some of these people have also left positive comments on his profile, e.g. “Item just as described, arrived safe and sound. Thanks! A++”.

On Amazon (right), “W.Todd Dominey” is building his reputation by providing helpful reviews in 665 of 711 cases. He is also building trust by using his real name, and sharing where he is from. However, as with “RuthAnn” on Yahoo Answers, we don’t know how much “W.Todd Dominey” knows about the topic being reviewed. We can’t verify his credentials.

The motivation for most people who help their temporary ties is not monetary. You can’t create a great temporary tie community with financial reward. Yelp tried to do this by paying people $1 per review, and later they tried to build communities by paying people $15 an hour to comment on existing reviews and write new ones. Yelp ended up with a lot of poor quality reviews 13 14, and a lot of bad press. Some of the actual motivations for temporary ties include recognition of being an expert, altruism, and feeling that they belong to a community. All of these behaviors need to be understood and accounted for in our social web designs.

Supporting temporary ties is good for business. One study showed evidence that “an increase in positive comments about a mobile handset typically appeared a month or two before an increase in market share for that handset.”15 Another study over 7 months showed that when the online promoter activity (an estimate of the online chatter likely to lead to a recommendation) went up, sales went up the following month. When activity went down, sales went down. 16

When designing for temporary ties:

  • Prioritize a great system for building reputation. Allow people to give feedback to one another.
  • Encourage people to expose content that will increase trust in their identity. This could be their real name, a real photo rather than an avatar, or proof of their qualifications.
  • Prioritize a great system for building trust between people. This may be highlighting shared connections, shared groups, or shared interests.
  • Don’t incentivize people with money, incentivize them to build their reputation.


Social web design will become an important part of every interaction designer’s skillset. To do it well, we’ll need to understand some basics about human relationships. If your users’ needs center around strong ties, you’ll design something very different than if they center around temporary ties. Understanding the difference between strong, weak, and temporary ties will help us build better online social experiences.


1, 4 User Interactions in Social Networks and their Implications, Wilson et al. 2009


3 The Economist article quoting stats from Cameron Marlow, sociologist at Facebook

5 Data from a TED talk by researcher Stefana Broadbent

6 PBS article by Henry Jenkins, MIT Professor

7, 8 Nichola Christakis + James Fowler “Connected: The surprising power of our social networks and how they shape our lives” Little, Brown and Company 2009

9 Reports from the Center for the Digital Future, University of Southern California

10 Brave New World of Digital Intimacy

11 I. de Sola Pool, The Social Impact of the Telephone, MIT Press, 1977

12 Quoted from studies by Robin Dunbar

13 Paying People to Yelp

14 Yelping for Dollars

15, 16 Charlene Li + Josh Bernoff, Groundswell, Harvard Business Press, 2008

]]> 20
Faceted Finding with Super-Powered Breadcrumbs Fri, 09 Apr 2010 07:48:47 +0000 Most of the today’s finding interfaces do not support integrated finding effectively, often creating disparate search and browse user interfaces that confound people with a jumble of controls competing for their attention.

In this article, I propose the Integrated Faceted Breadcrumb (IFB) design that integrates the power of faceted refinement with the intuitive query expansion afforded by browse. Although other breadcrumb-based finding interfaces currently exist, they fall short of expectations by ignoring design best practices. At best, the breadcrumb is stuck in a role of a side-kick, forced to eke out meager screen real estate along-side more powerful finding controls.

In contrast, breadcrumb is the superhero of the IFB design, dealing a decisive blow to many usability issues that plague today’s finding interfaces. To prove this point, I did what we do best – I tested my hypothesis. Twelve evaluators found IFB to be easy to use, intuitive and resourceful for solving complex finding tasks which would be difficult to accomplish using more conventional faceted search interfaces.

The Challenge of Integrated Finding

In his recent UIE webinar, Peter Morville lauded the advantages of integrated finding: “Browse and Search work best in tandem… the best finding interfaces achieve a balance, letting users move fluidly between browsing and searching.”1

Unfortunately, most sites today do not integrate faceted search and browse effectively. For example, approaches browse and search using two different interfaces creating a jumble of duplicate controls that overwhelm the customer, making the site more difficult to use, as shown in Figure 1.


Figure 1. Disjointed finding mechanisms for faceted search and browse on

A veritable cornucopia of filters, links and options on make it unlikely that the customers will be able to duplicate the search successfully or efficiently discover related items and content. Duplicate finding methods also create a problem for natural search, because each finding page exists only within the context of the specific session.

Achieving “flexible navigation, seamless integration of browsing with directed (keyword) search, fluid alternation between refining and expanding, avoidance of empty results sets, and at all times allowing the user to retain a feeling of control and understanding” are “overarching design goals” of faceted finding, says Marti Hearst in Chapter 8 of her Search User Interfaces book.2

Integrated Faceted Breadcrumb (IFB) Design

To meet the search and browse integration challenges, I propose the Integrated Faceted Breadcrumb (IFB) design solution. A wireframe of the recommended UI redesign that uses the Integrated Faceted Breadcrumb is shown in Figure 2.

Wireframe of redesigned using Integrated Faceted Breadcrumb (IFB)

Figure 2. Wireframe of redesigned using Integrated Faceted Breadcrumb (IFB)

Breadcrumbs are simple, intuitive, flexible and resourceful. As Jacob Nielsen, states in his 2007 Alertbox, Breadcrumb Navigation Increasingly Useful: “Breadcrumbs show people their current location relative to higher-level concepts, helping them understand where they are in relation to the rest of the site. Breadcrumbs afford one-click access to higher site levels and thus rescue users who parachute into very specific but inappropriate destinations through search or deep links. Breadcrumbs never cause problems in user testing… people… never misinterpret breadcrumb trails or have trouble operating them.”3

Preliminary Usability Evaluation of the Integrated Faceted Breadcrumb

Findings from the early usability testing of the Integrated Faceted Breadcrumb design using a linked HTML prototype are very promising. Using a simple, 8-page HTML prototype, I tested several variations of this design with 12 current users of popular e-commerce interfaces, people of various genders, ages and backgrounds.

Evaluators were able to quickly grasp the range of possible interactions and use the interface effectively to solve complex finding tasks which would be difficult to accomplish with the existing faceted search interface. Most evaluators found IFB design intuitive because it makes liberal use of the existing mental models for breadcrumbs and faceted search. 

The participants’ confidence and ability to accurately predict system behavior was also observed to be very high after just 1-2 simple tasks; this indicates a fairly short learning curve for IFB design. Although no formal studies comparing the performance of someone using IFB vs. existing faceted finding solutions have yet been conducted, IFB design was strongly preferred by the participants when compared with the existing faceted search design for certain kinds of finding tasks.

Early usability tests show that Integrated Faceted Breadcrumb (IFB) design provides many benefits over most conventional faceted search designs:

  1. Short learning curve: familiar links and drop-downs make this control fairly intuitive. People who previously used a breadcrumb can operate IFB effectively.
  2. Efficiency: combining breadcrumb and facets into one control makes very efficient use of limited screen real estate and greatly reduces clutter caused by duplication of controls.
  3. Unlimited Access: Combined search and browse allow unrestricted access to any page that pertains to the current query.
  4. Integration: fully integrates landing pages, brand catalogs and category pages into the faceted search hierarchy. There is one prominent place on the screen to see where you are and access all the navigation tools right where they are needed.
  5. Flexibility: customers can switch from search to browse and back again as best fits their needs at each stage of the finding process.
  6. Resourcefulness: provides opportunities to widen the search and access complimentary products and services related to the current query.

What makes Integrated Faceted Breadcrumb (IFB) different

In his 2009 UIE webinar, Faceted Search: Designing Your Content, Navigation, and User Interface 4, Daniel Tunkelang stated that most breadcrumb-based finding interfaces are not intuitive, nor easy to use. What makes Integrated Faceted Breadcrumb (IFB) design different? I believe Integrated Finding Breadcrumb design is more intuitive and resourceful than other faceted breadcrumb solutions due to the following key design recommendations made based on several years of designing and researching finding interfaces:

  1. Combine hierarchical Location & Attribute breadcrumbs
  2. Use Change instead of Set-Remove-Set
  3. Automatically retain relevant query information
  4. Label breadcrumb aspects
  5. Make it clear how to start a new search
  6. Allow direct keyword manipulation.

In the following sections, I discuss these design recommendations and explain how Integrated Faceted Breadcrumb compares with some existing faceted breadcrumb solutions. Whether or not the reader decides to adopt all or some part of IFB in their own finding interface designs, I hope the following sections will prove to be a good resource for discussion and further exploration of integrated finding UI designs.

1. Combine Hierarchical Location & Attribute breadcrumbs

In 2002, information architect Keith Instone cataloged the three types of breadcrumbs in his 3rd Annual IA Summit poster with a revealing title: Location, Path & Attribute breadcrumbs.5 In faceted search interfaces, Attribute breadcrumbs commonly convey applied facet values such as price, category, style and brand. Most commonly, Attribute breadcrumbs are Path breadcrumbs, displaying facet values in the order they were applied by the customer to reach the current set of search results. Attribute-Path breadcrumb UI on the Ariba Discovery Network is shown in Figure 3.

Attribute-Path breadcrumb in the Ariba Discovery Network UI

Figure 3. Attribute-Path breadcrumb in the Ariba Discovery Network UI

Unfortunately, Attribute-Path breadcrumb is not resourceful from the standpoint of integrating search and browse and helping people find related content:

  1. Temporal breadcrumb cannot be used to effectively link and anchor categories, landing pages, brand catalogs and other browse pages, precisely because it is carrying all of the attribute history instead.
  2. Temporal breadcrumb cannot be used to effectively show the customer where they can go because instead it is busy showing them where they’ve been.
  3. Pages with Temporal breadcrumbs cannot be effectively linked by natural search, because people creating different URLs each time the content is accessed.
  4. When the query changes, attributes appear to “randomly” jump around on the breadcrumb.

In contrast, Location breadcrumbs are hierarchical: they do not deal with where the person has been, only with where within the site’s organization they are right now. Hierarchies are very helpful in a wide range of finding and navigating tasks and provide an intuitive way to manage complexity and access resources.

How do we determine the hierarchy of Attributes? My research led me to believe that most people find it intuitive when the Attribute-Location breadcrumb simply replicates the order in which un-selected facets are presented (most typically in the left nav bar). Replicating the order in which un-selected facets appear also provides an effective way to integrate search and browse by treating the Category as just another Attribute in the breadcrumb. In vast majority of finding interfaces, Category appears first in the left nav bar, which places any applied “browse” Category Attributes in front of the applied faceted search values.

Un-selected facets in the left nav bar on

Figure 4. Un-selected facets in the left nav bar on

Most of the people found the Integrated Faceted Breadcrumb hierarchy straightforward and intuitive and were able to confidently and accurately predict the expected system behavior for complex filtering tasks that involved applying, removing and changing filter values, after spending only a few minutes working with the system.

2. Use Change instead of Set-Remove-Set

Overstock set-remove-set implemented via checkboxes

Figure 5. Overstock set-remove-set implemented via checkboxes

Applied aspects are removed from the breadcrumb by un-checking the checkbox next to the applied aspect in the breadcrumb. For most people, set-remove-set interaction conflicts with their mental model. As one of my evaluators stated: “This feels like having to turn off the radio every time I want to change the station.”

Instead of removing Canon in order to select Nikon, most people think in terms of simply changing Canon to Nikon, which can be accomplished most readily with a drop-down control. The drop-down is more intuitive than a typical remove mechanism, as it allows the user to discover all of the navigation options available from the parent facet or category. This idea was first introduced by Luke Wroblewski in his excellent book Site Seeing: a Visual Approach to Web Usability.6 One of the sites that implement drop down in the breadcrumb is, shown in Figure 6.

Edmunds breadcrumb with drop down options

Figure 6. Edmunds breadcrumb with drop down options

In my testing, vast majority of people preferred this design to a more common set-remove-set paradigm and found it very intuitive and effective.

3. Automatically retain relevant query information

In my research, I found that people seldom want to start the query over completely from scratch, unless they specifically indicated this action. Instead, they wanted to retain as much of the query as possible with every change of the facet values, and expect the system to help them construct a query that “makes sense”, gracefully dropping facet selections that no longer apply to their new query.

Unfortunately, few sites today implement this function well. For example, changing the model from Mustang to Fusion does not retain the year selection of 2005, as most people would expect. Instead, as shown in Figure 7, resets the model year to the current year, 2010, which simply disappears from the breadcrumb.

Changing aspect values drops useful query information on
Figure 7. Changing aspect values drops useful query information on

I found that a more resourceful system behavior is to retain any relevant attribute values that apply to the new query, preferably in way that always produces some search results.

Figure 8 shows how Integrated Faceted Breadcrumb design handles the change in the Product Type from Digital Cameras to Lenses, retaining the Brand and Keywords aspect, while dropping the Camera Resolution aspect (as it does not apply to Lenses).

Integrated Faceted Breadcrumb retains relevant query information

Figure 8. Integrated Faceted Breadcrumb retains relevant query information

Retaining aspects that apply to the updated query allows the customer to concentrate on their finding goals, while the system takes care of the details.

What if the person really wanted to browse just the Lenses Product Type? My testing showed that most people found it very intuitive to click the Lenses link in order to navigate to the Lenses Product Type landing page. The result of combining drop-down control functionality with the existing breadcrumb link interaction gives us a powerful, intuitive, flexible finding control.

What if instead of browsing, someone wanted to remove a single applied aspect from a breadcrumb, leaving the rest of the query intact? My research showed that most people found it easy and intuitive to navigate to the drop down and select “See All” option Integrated Faceted Breadcrumb design provides at the #1 position in the drop-down, as shown in Figure 9.

Integrated Faceted Breadcrumb makes aspect removal intuitive

Figure 9. Integrated Faceted Breadcrumb makes aspect removal intuitive

4. Label Breadcrumb Aspects

In Design Cop-out #2: Breadcrumbs7, Jared Spool mentions that the biggest problem with breadcrumbs is “the lack of scent” and that “the wording of the individual trail elements becomes very important.”

While most applications simply display the applied aspects in the breadcrumb, my research shows that labeling each of the applied aspects with the aspects name adds a great deal of information scent. The resulting IFB “breadcrumb tiles” (shown in Figure 9) display relevant aspect labels which help customers make sense of their queries and orient themselves quickly if they find the page through natural search.

5. Make it clear how to start a new search

Ariba interface in Figure 3 has a single search box which retains the original keywords, in a manner similar to Google. Unfortunately, any keyword change drops all of the applied aspects and filters launching a new keyword-only search. This is obviously not very resourceful, as we are trying to retain as much of the query as possible for reasons explained above.

In contrast, Integrated Faceted Breadcrumb (IFB) provides a dedicated “New Search” button on the Home breadcrumb tile. As shown in Figure 10, clicking the “New Search” button removes all aspects and keywords, resetting the breadcrumb to the full-screen text box, reminding many evaluators of the simplicity of the Google search.

“New Search” in the Integrated Faceted Breadcrumb (IFB) interface

Figure 10. “New Search” in the Integrated Faceted Breadcrumb (IFB) interface

Resetting is accomplished via an HTML layer or similar device so that the rest of the content on the page does not change. This way, the search box can reset almost instantaneously, perhaps even with an elegant animated transition.

6. Allow Direct Keyword Manipulation

Many faceted search interfaces like pictured in Figure 11, have two search boxes: one to “search within” the existing query, and one to start over with a new keyword-only search. Having two search boxes takes up precious screen real estate and increases the potential for confusion. Worse yet, the customer can not directly modify their keyword query after the search is executed, because the system converts all the keywords into an aspect which cannot be modified, only removed in its entirety. does not allow direct manipulation of the keyword query
Figure 11. does not allow direct manipulation of the keyword query

In his seminal book, Designing the user interface: Strategies for effective human-computer interaction8, Ben Shneiderman describes direct manipulation is one of the key HCI design principles. Integrated Faceted Breadcrumb (IFB) provides direct keyword query manipulation with the dynamic editable Keywords Aspect shown in Figure 12.

Direct query keyword manipulation in IFB

Figure 12. Direct query keyword manipulation in IFB

At the start of a finding session, the search box starts out fully expanded across the entire width of the page. When the customer types in some keywords, they are retained in the search box for easy editing or keyword addition, as shown in Figure 12-A. If the customer selects one or more facets, they are always added according to their respective hierarchy in front of the search box. As more aspects are added, the keyword box gets progressively smaller, until it reaches some reasonable minimum size as shown in Figure 12-B.

If sill more facets are applied at this point, a scroll arrow appears immediately after the Home facet, allowing customers to scroll only the applied aspects in the manner of a carousel control, without ever hiding the Home facet or the search box, as shown in Figure 12-C. IFB dynamic editable Keywords Aspect design proved to be very successful with our evaluators who found it intuitive, resourceful and easy to use.


Bruce Sterling, in his brilliant and entertaining book Shaping Things9, mentions Raymond Lowey and his very useful acronym MAYA. Faceted breadcrumb designs have only recently began to move out of being Most Advanced (the domain of academics and computer geeks) and toward becoming Acceptable to the general internet public.

Faceted breadcrumb holds in my opinion the promise to become the key component in the next generation of intuitive finding interfaces that fully integrate the best of faceted search and browse capabilities. I hope this article will assist anyone designing a faceted finding interface and helps move faceted breadcrumb designs, like the Integrated Faceted Breadcrumb, one step closer to the edge of MAYA, helping make resourceful integrated finding a commonplace reality. I look forward to continuing the discussion of IFB in the article comments thread and on Twitter “@DesignCaffeine”:


1 “Search UI Patterns”:

2 “Search User Interfaces”: book.

3“Alertbox, Breadcrumb Navigation Increasingly Useful”:

4 2009 UIE webinar “Faceted Search: Designing Your Content, Navigation, and User Interface”:

5 “Location, Path & Attribute breadcrumbs”:

6“Site Seeing: a Visual Approach to Web Usability”:

7“Design Cop-out #2: Breadcrumbs”:

8 “Designing the user interface: Strategies for effective human-computer interaction”:

9 “Shaping Things”:

]]> 10
5 Steps to Building Social Experiences Wed, 23 Dec 2009 08:54:40 +0000 Nowadays everyone wants social in their sites and applications. It’s become a basic requirement in consumer web software and is slowly infiltrating the enterprise as well. So what’s a designer to do when confronted with the requirements to “add social”? Designing social interfaces is more than just slapping on Twitter-like or Facebook-like features onto your site. Not all features are created equal and sometimes a little bit can go a long way. It’s important to consider your audience, your product—what your users will be rallying around and why they would want to become engaged with it and each other, and that you can approach this in a systematic way, a little bit at a time.

These concepts derive from a book I wrote recently with Christian Crumlish, “Designing Social Interfaces“. They are quick and easy things to remember when infusing social into your site. Each points offers some simple suggestions and points to consider when designing. Potential design patterns are recommended (and linked to) as examples for what could be done in your interface as you design and grow your service. Keep in mind that your context will dictate different specific solutions but the questions and concepts to think about will still be applicable.

Step 1 – What’s your social object? Make sure there is a “there” there. Give users a reason to rally. Why would someone come to your site?

Most people are drawn to a site based on their particular interests, in hopes of learning more or meeting others like themselves. They may be looking for information or they may have information to share. They have a passion—such as making handcrafted jewelry or taking landscape photographs—and at some point, they will want to share that with other people. That passion, that thing that people rally around is often referred to as the social object. It’s the object around which conversations emerge and thrive.

Remember that sometimes, the social object is a person – or the conversations between people. But don’t forget history (remember Friendster? or SixDegrees?), if the only thing to do is build a profile, people will eventually go somewhere else to have conversations or to do things around objects of interest.

Step 2 – Give people a way to identify themselves and to be identified.

This can be as simple as an “attribution” line when contributing and signing content.

Attribution of a comment on flickr
Attribution of a comment on flickr

It could be an “identity card” that shows a little bit about the person and is attached to every thing they do or can be as robust and complex as a “full profile” that is linked from all their contributions. The method can start out simple and grow over time.

Identity or Contact card as seen on FriendFeed
Identity or Contact card as seen on FriendFeed

It’s important to give people credit for their words and contributions. It helps others recognize their friends and disambiguate them from other people with the same name and builds a “reputation of quality” or lack thereof for their participation on your service.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing. Module shown from MyBlogLog
Relationship module shown from MyBlogLog

Once you have given people the ability to identify themselves, allow them to “find each other” and claim their tribe. “Relationships” make the world go round and online it’s no different.

Step 3 – Give people something to do.

Provide a path for participation so lurkers as well as early adopters can be engaged at the level of effort that is appropriate for them. Things like ratings (“1-5″ or “thumbs up“) are easy ways to get low participation people involved by letting them quickly register their opinion with little effort.

Thumbs up and down ratings for restaurants on GoodRec let people quickly register their opinion with little effort
Thumbs up and down ratings for restaurants on GoodRec

Allow them to “share items” they find interesting with their friends or family and “curate and collect their favorites“. The latter requires a little bit more effort, but lets your users have ownership over what they find meaningful.

Flickr allows users to “favorite” images they like and collect them for display to others.

At the other end of the spectrum is full authorship of content with “reviews“, “comments“, “blog postings“, and “wiki entries” all the way through to participation as a moderator or guide in your service.

Wikimedia allows collaborative editing of content on sites built with the software.

Start simple, with light features, and gradually add more complexity if it is really needed. Keep the structure flexible enough for your users to mold and adapt to their needs. In the book, we discuss several principles related to this including “Deliberately Leave Things Incomplete“, which reminds designers to allow features to emerge from the community behavior rather than forcing behavior to fit the UI and “Strict vs. Fluid Taxonomies” which merges a strict taxonomy like your site navigation with user generated groupings and organization with features like Groups, Message Boards, Tagging, etc.

Allowing behavior to guide your features and giving your users ownership of the structure make the site much more personal for them which in turn encourages repeat and longer term usage.

Step 4 – Enable a bridge to real life (groups, mobile, meetings, face-to-face).

Don’t be afraid to build in tools that allow your users to bring their community into the real world. In many online groups, a majority of people know each other personally.

Upcoming shows local events and allows people to add events to their calendar and view events their friends are interested in.

Providing tools to help plan face-to-face meetings and then archive those happenings will strengthen your site and the community. Consider incorporating “geo” features like “GeoMapping“, and “GeoMashups“.

Additional features might entail creating “subspaces (groups)” and coordinating real time “face-to-face meetings” and gatherings among users of your service.
Meetup lets people affiliate with groups of interest and the site helps coordinate real life - in person meetings and gatherings between members.
Meetup lets people affiliate with groups of interest and the site helps coordinate real life – in person meetings and gatherings between members.

Step 5 – Gently Moderate. Let the community elevate people and content they value.

This can be through simple things like ratings or “reputation labels“.

Reputation labels on the intranet at Yahoo!.
Reputation labels on the intranet at Yahoo!

The community can help you surface contributions of quality which in turn should help attract future participants and will help keep the interactions lively. This process also helps push bad quality content down and out of sight.

Keep an eye on the community, participate yourself, welcome people as they join, set yourself up as a role model.

Hunch founder, Catarina Fake, acts as a role model for the community being built on the site.

Notice who is passionate and who is potentially causing trouble. Conversations should run their course. Let the “community moderate itself” and provide tools to allow them to do that, like allowing them to mark content as spam or block trolls or “report abuse“. Step in only when necessary.

Report Abuse is available on every comment in Yahoo! Answers and allows users to moderate the content quality.

Make sure people are aware of the “terms of service” and “license” implications of content they create – both as it relates to your site as well as what they can permit others to do with their content.

Go out and get started

These are a few of the things to consider when building a social application or when adding social features to an existing site. There are a lot more features and concepts available within the social ecosystem but these should get you started and will build a good foundation from which more robust and complex features can be added to.

It is important to remember that you don’t have to do it all at once. You can apply features sparingly and let the community tell you when you need to expand. Consider the bare minimum while fleshing out your infrastructure. Add complexity as your community grows and scales. Remember that you are building a container for activity and conversation and that you don’t have to have everything figured out. The people will create their own paths of interaction making their own meaning and experience.

]]> 12
Integrating Prototyping Into Your Design Process Tue, 22 Sep 2009 22:50:01 +0000 Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you.

Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But here’s the thing… prototyping is not a silver bullet.

There is no one right way to do it.

However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered.

The dimensions of fidelity

A prototype’s fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a “high-fidelity” prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out what’s most important to UX designers, what it’s like to actually work with the prototype!

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Let’s take a look at some examples.

version w/ arrows

A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations.

That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations.

After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:

There is no such thing as high or low fidelity, only appropriate fidelity.

Appropriate Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others.

bottom left Low Visual and Low Functional Fidelity

Very low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:

  • Does the system have all the features required to support the user’s goals?
  • Does the workflow make sense at a high level?
  • Which UX concept works best?
  • Coming to consensus on a UX concept with stakeholders, e.g.“Is this what you meant?”

bottom right Low Visual and High Functional Fidelity

In my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes. Everything is black, white, and gray, but the interactions are extremely close to what they’d be in the developed system. These types of prototypes are effective in many situations:

  • Evaluating the usability of proposed designs for new systems
  • Exploring isolated interactions as a proof-of-concept
  • Validating UX design direction with stakeholders
  • Validating the implementation of requirements with stakeholders
  • Supplementing printed documentation for development teams
  • Performing remote testing

Remote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations.

By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it…. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth.

I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, I’ll know that and can release the design with confidence instead of with gritted teeth.

top left High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what I’ve heard termed a “slap and map” test from within a browser.

top right High Visual and High Functional Fidelity

High visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isn’t worth it. But there are a few situations where it is:

  • Evaluating the usability of proposed UX designs for an existing system
  • Performing usability tests with non-savvy user groups
  • Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.

Integrating Prototyping Into Your Design Process

What I’ve talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process?

First off, do what you’d do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose.

People like shiny things that move. The cool factor of prototyping will be difficult to resist.

As you near completion of the prototype, make sure you walk through the prototype with the project’s stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and you’re soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, it’s very likely they will actually request a prototype as a result of their first experience with you.

Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.

Corporate, Agile, Mature UX Practice

This situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your company’s products. In this situation, there are three points in the design process that prototyping can be of benefit.

  • Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.
  • High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.

You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system to build efficiencies into an Agile process.

Corporate, Waterfall, New UX Practice

In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organization’s need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Here’s how prototyping can help:

  • High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
  • These prototypes should also be used for user testing, if at all possible.
  • Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.


When doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like they’re paying for the same thing twice.

  • Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the user’s shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).
  • Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.
  • Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.
  • Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.

]]> 25
UI Pattern Documentation Review Mon, 29 Jun 2009 08:16:40 +0000 Introduction

User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development.

The very nature of UI patterns requires that they be familiar to end-users. An individual UI pattern is a discrete, repeatable unit of user experience. I refer to collection of patterns as a library.

In many cases, less proprietary patterns are more useful in solving a design problem as they can be implemented more uniformly across platforms. This characteristic and the efficiency gains make patterns an excellent opportunity for software companies to come together and promote UI patterns to the wider development community.

Producing a common pattern library, however, implies that the patterns presented are at the very least, consistently documented and most probably presented in the same single classification system. Currently though, patterns are classified and documented in various manners across publishers with no clear standard evident.

The problem

To date, the most common approach to propagating a single user experience standard is the development of UI guidelines and principles documentation within an organization. Development teams  — usually incorporating a user experience specialist — then reference this documentation during implementation and upgrade processes.

However, as the numbers of systems grow within an organization, so does the effort needed to maintain the quality and consistency of the user experience. For many organizations, it is now impossible to assign much, if any, time of a user experience specialist to all implementation efforts, and experience has shown that the UI guidelines and principles approach to propagating a single user experience standard does not scale well.

There are two common issues, both major.

The first issue is ensuring developers are familiar with all the principles and guidelines.

Documentation to fully describe a UI standard is, by its nature, extremely detailed and complex. Getting developers to know all this information intimately is an ongoing and often un-winnable battle.

The second major issue is that the application of guidelines and principles can be open to wide interpretation.

Requiring developers to combine guidelines and apply principles together to create a complete UI can be inefficient. This synthesis process can result in widely-varying solutions to a single design problem across teams — especially when working with widely distributed and possibly culturally diverse groups. Removing these variances to create a more consistent user experience requires rework.

The solution

UI patterns to a great extent mitigate the problems of weight and interpretation experienced with the principles and guidelines documentation approach of the past. In essence, patterns can be seen as prepackaged solutions based on guidelines and principles.
Patterns and pattern libraries are more convenient for developers because they solve common higher-level design problems without the need for deep knowledge of often-complex guidelines and principles documentation. Also, they implement best practices, so developers don’t synthesize what are often “slightly original” solutions that would need to be reworked later.

Much of the value of a pattern to the developer is its less granular and more physical nature. Principles of good UI design dressed up as UI patterns add little value over traditional guidelines and principles documentation, as seen in many of the UI patterns as described in the Design of Sites; examples such as “Low Number of Files” — while an important design principle or guideline — do not deliver up a usable UI component.

Also important is creating the patterns to begin with. The guidelines and principles that form the foundation of patterns still need to be developed before any patterns themselves are developed.

Integrating UI patterns

Integrating UI patterns into the culture of software development is to a large extent still beginning. Next-generation development tools such as those proprietary ones being developed by enterprise software companies that implement patterns natively are now or will be soon in the hands of developers around the world.

Embedded drag and drop UI patterns hold the promise to empower developers to create better user interfaces, faster — unsupervised by user experience specialists. While this may strike fear in the hearts of many a user experience specialist, issues of scale dictate such a pragmatic approach. Be aware though, that they also can perpetuate problems if the UI patterns implemented are out of sync with end-user expectations.

Why standardize UI patterns?

Currently, there is no recognized standard for the classification or documentation of UI patterns, as seen by browsing through pattern libraries from:

  1. Martin Welie’s UI patterns
  2. Jennifer Tidwell’s UI Design Patterns
  3. Sari Laakso User Interface Design Patterns
  4. The Design of Sites: Patterns, Principles and Processes for Crafting a Customer-Centered Web Experience by van Duyne, Landay and Hong.
  5. Yahoo Design Pattern Library

The variety isn’t surprising, since applying the pattern concept to user experience design is a relatively recent phenomenon. However, the successful introduction of a single classification and documentation standard could significantly increase the value of a UI pattern library to developers by…

  • Reducing confusion among pattern versions across collections. Not surprisingly, many of the same patterns exist across collections. A standard classification system (discussed below) can help developers make sense of both these patterns and their different versions in collections across the web and in paper publications.
  • Promoting development of net new UI patterns. A clear classification taxonomy is likely to make the “holes” in the current crop of pattern libraries more apparent, which in turn hopefully will increase the pace of development of new UI patterns.
  • Providing a standard UI pattern interface. As the number of patterns increases, pattern search tools will become more important. A standard classification and documentation approach will enable developers to quickly display their UI options.
  • Promoting UI pattern adoption. A clear classification taxonomy is likely to have the effect of making patterns easier to find and in turn increase their use.

Problems with the solution: UI pattern Classification Approaches

The following is a high-level analysis and discussion on classification approaches of the previously mentioned UI pattern collections. Each collection is mapped and discussed from a classification and documentation perspective.

Martin Welie’s patterns

Classification Analysis

Patterns in Interaction Design

Cropped version of Welie's patterns

Figure 1. Classification Map (click image to enlarge)

Welie divides the patterns into three delivery methods: Web design patterns, GUI design patterns, and mobile design patterns. Within the web design patterns channel (the focus of this document), the patterns are categorized into ten groups based on a mix of content and functional subjects.

Documentation Approach

Cropped version of Welie's approach

Figure 2. Documentation Map (click image to enlarge)

Welie’s documentation approach is simple, with a focus on visual elements to explain the function of the pattern. It can be broken into three main parts:

  • Description: This area of the documentation provides the name and image to describe the pattern.
  • Rationale: This area provides a description of the problem that is solved by the pattern, how it works, and the scope of its use.
  • Associations: This area provides links to other patterns related to the current pattern.

Jennifer Tidwell’s patterns

The following is a map of Jennifer Tidwell’s UI Design Patterns. (Click image to enlarge.)

Cropped version of Tidwell's patterns

Unlike Welie, Tidwell does not take into account different delivery methods. The eight categories she does specify look to be based on functional subject areas only.

Sari Laakso’s patterns

The following is a map of Sari Laakso’s UI patterns. (Click image to enlarge.)

Cropped version of SL's patterns

Like Tidwell, Laakso does not differentiate between delivery methods; he bases all seven of his categories on functional subject areas.

The Design of Sites’ patterns

The following is a map the patterns presented in “The Design of Sites.” (Click image to enlarge.)

Cropped version of Design of Sites' patterns

The most extensive pattern collection of the four sampled, Design of Sites does not specify delivery methods, and, in some cases, the items presented could be regarded as design guidelines or principals rather than patterns. Twelve categories are presented with a mix of content and functional subjects.

Summarizing the classification types

From this analysis three main types of classification are present — content subject, functional subject, and delivery platform.

Content subject classifications normally specify an application genre (for example, ecommerce and supply chain management). Examples of content subject based classifications can be found in the Design of Sites collection under “Site Genres” and in Welie’s collection under “Site Types.”

Functional subject classifications are based on logical breakup of functionality (for example, shopping cart and two-panel selector). This is the most common prevalent classification type and is found in all the collections sampled.

Delivery method is used to describe the platform on which a pattern has been designed to operate. This classification type opens up the possibility for unique patterns to be developed for the same subject classifications across platforms. This classification type has the potential to provide more resolution for developers looking to offtake a pattern within a specific UI delivery platform such as mobile, desktop, or web.

Based on the publicly available pattern libraries available today, there is no clear indication as to whether “delivery method” is a valid classification type. An argument could be made that the process of binding a pattern to a specific technology is will reduce the life of the pattern as platforms develop. However, the timelessness of a pattern is of little consequence to developers whose primary goal is product delivery rather than pattern lifecycle.

Another Classification type – Level

This author would like to include an additional classification type: Level.

The level classification would further divide patterns into the following areas of concern:

  1. Navigation architecture: Patterns relating to the navigation of content within an application
  2. Screen architecture: Patterns which position functionality and content within a screen
  3. Site furniture: Patterns for formatting functionality and content

In the case of the collections previously reviewed, the great majority of patterns would be classified as falling under the “site furniture” level type. However, it is this author’s view that considerable potential remains to develop patterns within the proposed navigation architecture and screen architecture level types.

A proposed classification system

Cropped version of the classification system

The above diagram (click image to enlarge) describes a potential pattern library classification hierarchy. In this case, client classification nodes are presented at the top of the tree similar to that of the Welie collection; the proposed new level classification nodes are added above subject.

Content and functional subjects would be implemented as tags because these classifications would occur across levels.

Why have a classification hierarchy — aren’t filters or tags more useful?

In many cases, being able to filter by classification node as required is more flexible than drilling down through a preset hierarchy. However, a present classification tree is also useful to:

  • Automate the generation URLs to enable cross linkages within the UI pattern library.
  • Provide a simple drill experience for end users who have no specific problem to solve but rather just wish to browse to learn and or generate ideas.

UI pattern Documentation Proposal

The value of a standardized UI pattern documentation to developers is a single interface for search tools. Such tools hold the potential to streamline the off take of UI patterns by developers with specific problems to solve in a world with hundreds and potentially thousands of UI patterns to choose from.

UI patterns are by their nature visual. It must be noted that strong support for pictorial content would seem obvious and reduce the necessity for long verbal descriptions that add little value next to their visual equivalents.

]]> 20
Photos for interaction Wed, 18 Feb 2009 23:55:54 +0000 When developing user interfaces, designers increasingly use custom graphical elements. As the web browser becomes basic technology for software interfaces, more and more elements derived from graphic and web design replace the traditional desktop approaches to the concrete design of human-computer interfaces.



Elements of interactive visual design


The role of photography in software user interfaces


Case 1: Photography as content





Case 2: Photography as design element



Benetton Web Site



3. Photography in software UI Design



SAP Enterprise Portal


Like in web design, the image is used here as an element of design but loses all its visual power due to its jammed position in a design that puts all emphasis on the representation of information. The "mise en scène" of the interface suffers from the poor integration of the photographic element, totally separated from all information. Its meaning in the application context is reduced to a vague bridge metaphor referring to the function of a portal.

The best of both worlds: towards a new quality


At same time, a lot of effort is being made to make applications more "shiny and glossy", to better imitate real world structures on the screen. Sometimes, like in current reporting tools for business intelligence, this additional glitter reduces the visual perception of information instead of enhancing it.


Examples for photography in interactive applications

Designklicks Designklicks


Space by the Barbarian Group for Getty


Société Générale Customer Portal


VDW Fine Art Website


Take the blinkers off, and think about experiences as a whole


So why posting this on a site dedicated to the "design behind the design"? Because interaction designers and information architects have become strong conceptual thinkers, driving an experience in terms of concept as well as it’s soul.  Visual design should enhance and implement this vision, which is in fact in most cases the contratry of "making things pretty."

Recommendations for photography in next-generation interfaces

  • If used as content element, think about alternatives to simply placing photography on a grid. There are a lot of possibilities to make images "tangible" to the user. Think of multiple layers, movable objects, or 3D approaches.

See also:

Interactive Identity: Bridging Corporate Identity and Enterprise IT
Visible Narratives: Understanding Visual Organization by Luke Wroblewski
10 ways by gettyImages

Coming soon:
Part II – Typography in User Interface Design

]]> 8