I really like Adrian Shaughnessy’s view on design authorship and that constant struggle to find the right balance between art and science in design. From A Layperson’s Guide to Graphic Design:

As designers we are inclined to solve the problems of our clients, but we want to do it in our own way and in our own voice.

Of course, this takes us to the essential paradox at the heart of all types of design: the urge for a personal authorial voice is considered to be antithetical to rational objective design. To be truly objective, the designer needs to remove all personal feelings from the equation and zero-in on a rational solution ”” or so we are told.

Yet there never was great design of any kind that forced the designer to eradicate his or her own voice, and all great design, the stuff that matters, has a strong personal signature which doesn’t impede functionality. Designers may not be artists, but they still want to ”” metaphorically and literally ”” sign the work they do.

(link via @justinspratt)

One of the talks I do at speaking events is a general introduction to the elements of user experience design. The slides are always evolving so I’ve been hesitant to upload the presentation to Slideshare since it will be outdated pretty much immediately. It’s also a presentation that relies heavily on the voice-over - it’s not really something you can just read from front to back.

Having said that, I think it’s time to put at least a version of the presentation online, with a bunch of disclaimers about how this is a simplified view of what UX is, that it requires explanation in a lot of areas, and that it’s definitely not exhaustive or the only way to think about UX. Here’s the summary:

In this talk I give an overview of the elements of User Experience Design, and more importantly, why you should care about it. The goal is to provide some baseline knowledge of the user-centered design process to equip anyone to take those skills back to their daily work and start applying it immediately. I discuss user experience research, content strategy, interaction design, and visual design, and how those elements work together to build great experiences.

So, here you go. I hope you find it useful.

Somehow my wife and I found our way to The Coffee Roasting Company at Lourensford Wine Estate on Saturday. We’ve never been there, and the experience was fantastic. I recently referenced an article on how architecture can be used to influence behavior, and this place is a prime example. The coffee shop is designed to encourage talking and not rushing.

You’re greeted with the almost-overwhelming smell of different coffees blending together. Next you notice the unpretentious, “we’re just here to brew good espresso” decor, followed by the rustic tables and stacks of well-read books about coffee scattered all over. This is how coffee should be enjoyed.

As my wife and I settle in to wait for our cappuccinos I pick up a book called Coffee by Claudia Roden. I read out loud to her:

In Turkey at one time, a man promised when he married never to let his wife go without coffee, and it was considered a legitimate cause for divorce if he neglected to do so. So important is coffee in Oriental life that it is common for beggars to ask for money to buy it. It is inconceivable that they should go without. Business and bargaining are always done over a cup of coffee served before the argument starts. Whether in a shop or a market stall it creates a bond and an obligation between buyer and seller.

The author goes on to say that coffee houses “required a certain leisure” since it took time to roast and prepare coffee, so people got accustomed to waiting and filling their time with conversation. As I read those words I think about something my dad brings up a lot. As a geographer he is very interested in “sense of place” and always encourages us to try to understand the soul of a town or a building. From Wikipedia:

Places said to have a strong “sense of place” have a strong identity and character that is deeply felt by local inhabitants and by many visitors. Sense of place is a social phenomenon that exists independently of any one individual’s perceptions or experiences, yet is dependent on human engagement for its existence. Such a feeling may be derived from the natural environment, but is more often made up of a mix of natural and cultural features in the landscape, and generally includes the people who occupy the place.

That’s what I felt as I sat there reading, drinking coffee with my wife, taking it all in. There is a strong sense of place not because of one single thing, but because of how the people, the smells, the architecture, and of course the coffee come together to create an undeniable identity.

What does this have to do with design? As my thoughts drifted I was reminded that all design has a sense of place - even web design. The interactions, typography, copy, images, etc., come together to create an experience. You can analyze a design in pieces, but you can only experience it as a whole.

We tend to break up the different functions of user experience design, and that’s fine. We need User Researchers, Information Architects, Content Strategists, Interaction Designers, Visual Designers, and [insert latest job title here] who specialize in what they do. But it’s fallacy to think that they can work in isolation as if each is building one piece of a puzzle that can merely be assembled once all is said and done.

For a design to have a strong and desirable sense of place a natural ebb and flow between the different aspects is essential (even if it’s all done by the same person). Turning a wireframe into a high-fidelity mockup isn’t a one-way activity - there will always be things to reconsider about the interaction or the content (or a multitude of other aspects). As I’ve written before, designing in isolation can be dangerous and very unsatisfactory for everyone involved.

I’ll add this: designing in a place like this is way better than designing in a cubicle. Creative spaces beget creativity.

Also, that coffee was amazing.

I love Tom Armitage’s post Asleep and Awake, about the differences between the Kindle and the iPad. Here’s how he describes what happens when you wake each device up:

The Kindle blinks ”“ as if it’s remembering where it was ”“ and then displays a screen that’s usually composed of text. The content of the screen changes, but the quality of it doesn’t. Ther’s no sudden change in brightness or contrast, no backlight. If you hadn’t witnessed the change, you might not think there was anything to pay attention to there.

When the iPad wakes up, everything else in the room disappears; your attention’s been stolen by that burst of light.

He goes on to describe the Kindle as having a “quiet confidence” while the iPad constantly seeks your attention. The conclusion serves as a healthy reminder of the scope of true user experience:

The Kindle, much like a paperback book, is just as happy “asleep” as it is in use. It’s a reminder that the design of genuinely ubiquitous devices and products is not just about what they are like in use; it is also about what they are like when they are just present.

We need to remember that even on the web, we’re not just designing online experiences. All the touch points with users have to be designed. Yet we often don’t apply user-centred design principles to areas like customer support and logistics. Let the Kindle’s “asleep” state remind us to do so.

Kelly Sutton provides a great reminder of what design thinking is all about in Your idea is terrible, a post about startups and the current obsession with “social layers”:

The problems that your project solves shouldn’t start with “Wouldn’t it be nice if”¦” Instead, they should always be phrased, “X sucks because Y and Z.” You may not even have a solution. Technology may not even be the right solution. But please stop adding social layers to social layers and raising 5 million dollarbucks.

Every UX project should be framed in the same way.

Don’t start with “What would happen if we move this button over here?” Instead, start with “Our checkout process sucks because our research shows that users are not seeing the ‘Pay now’ button.”

I recently wrote about persuasion design on the web. In How Whole Foods “Primes” You To Shop, Martin Lindstrom gives some great examples of how grocery stores use persuasion design tactics to get people to buy more:

Ever notice that there’s ice everywhere in this store? Why? Does hummus really need to be kept so cold? What about cucumber-and-yogurt dip? No and no. This ice is another symbolic. Similarly, for years now supermarkets have been sprinkling select vegetables with regular drops of water—a trend that began in Denmark. Why? Like ice displays, those sprinkled drops serve as a symbolic, albeit a bogus one, of freshness and purity. Ironically, that same dewy mist makes the vegetables rot more quickly than they would otherwise. So much for perception versus reality.

I get it, and I understand that businesses need to make money, and this helps them do it. I don’t have to like it though, right?

I’m becoming increasingly fascinated with the parallels between architecture and web design. Dan Lockton recently published Architecture, urbanism, design and behaviour: a brief review - it’s an extract from his PhD thesis where he discusses how architecture can be used to influence behavior. It’s a long article, but well worth your time - I highly recommend it.

It’s full of architecture concepts that can be applied to designing for the web, but I want to discuss one in particular - the idea of “paving the cowpaths”:

One emergent behaviour-related concept arising from architecture and planning which has also found application in human-computer interaction is the idea of desire lines, desire paths or cowpaths. The usual current use of the term [”¦] is to describe paths worn by pedestrians across spaces such as parks, between buildings or to avoid obstacles ”” “the foot-worn paths that sometimes appear in a landscape over time” (Mathes, 2004) and which become self-reinforcing as subsequent generations of pedestrians follow what becomes an obvious path. [”¦]

[T]here is potential for observing the formation of desire lines and then ‘codifying’ them in order to provide paths that users actually need, rather than what is assumed they will need. In human-computer interaction, this principle has become known as “Pave the cowpaths” ”” “look where the paths are already being formed by behavior and then formalize them, rather than creating some kind of idealized path structure that ignores history and tradition and human nature and geometry and ergonomics and common sense” (Crumlish & Malone, 2009).

Particularly with websites, analytics software can take the place of the worn grass, and in the process reveal extra data such as demographic information about users, and more about their actual desires or intention in engaging in the process. [”¦] This allows clustering of behaviour paths and even investigation of users’ mental models of site structure. [”¦]

From the point of view of influencing behaviour rather than simply reflecting it, the principle of paving the cowpaths could be applied strategically: identify the desire lines and paths of particular users ”” perhaps a group which is already performing the desired behaviour ”” and then, by formalising this, making it easier or more salient or in some way obviously normative, encourage other users to follow suit.

This is such an interesting perspective on user-centred design. We all know that we need to design for real user needs, and not what we think they want, but it’s often so hard to do all our design work from that perspective. That’s where real-world analogies like this can be extremely helpful.

By starting a redesign project with an explicit goal to “pave the cowpaths” we’re always pulled back into that frame of mind. The same questions will keep jumping into our minds:

• Do we have analytics to back up this behavior?
• Are we sure this is what users naturally do on the site?
• We know most users click on this navigation element to get things done - how do we make that behavior easier for them?

One real-world example we can look at is the recent announcement about upcoming changes to Windows Explorer. The team made a big deal about their data-driven approach to the design:

Over the years, Explorer has grown to support a number of different scenarios, many unrelated to file management ”“ launching programs, viewing photos, playing videos, and playing music, to name just a few. We wanted to know which of these capabilities customers were really using. Using telemetry data, we were able to answer the question of how the broadest set of customers use Explorer in aggregate.

The resulting design leverages this data in a very real way:

The Home tab is the heart of our new, much more streamlined Explorer experience. The commands that make up 84% of what customers do in Explorer are now all available on this one tab.

You can make a strong argument that by following this approach Microsoft is paving the cowpaths they discovered. But let’s look at a sentence I left out of the original quote from Dan Lockton’s article:

The counter-argument is that blindly paving cowpaths can enshrine inefficient behaviours in the longer-term, locking users and organisations into particular ways of doing things which were never optimal in the first place (Arace, 2006).

This brings a very interesting perspective to the design. Are the most frequently used commands in Windows Explorer really the most effective way to accomplish user goals? Was there an opportunity to drastically reduce and combine certain paths to simplify the interface?

It’s certainly not easy to figure out how to balance paving existing paths vs. using that data to design systems that guide users to more efficient ways of doing things[1]. But it brings me back to the main point: an analogy like this forces us to think hard about these questions and at least make informed decisions about the design.

The alternative is to just let it happen and possibly get caught with a blind spot we didn’t even know existed.

---

1. This is where qualitative user research methods like ethnography and usability testing can be extremely beneficial, but that’s a topic for another article.↩

Ryan Singer in Identifying conflicts in a UI design:

When I’m working on a UI design I look for things that are wrong. I have to do that because ther’s no checklist of things that are “˜right’ that make a perfect product. You can’t check a requirements list and say “Yep, everything’s there!” and conclude that you made a good design. You have to look at the design itself and hunt around for problems: things that cause friction, things that aren’t clear, things that take too long, things that break expectations.

These conflicts are the heart of design. If we could just pile features one on top of the other, we wouldn’t have to do design. Design is what you do when piling elements onto each other doesn’t work. It’s the process of identifying and resolving conflicts.

This is so true. As the debate about unsolicited redesigns rage on (most recently on ignore the code), I often think about the dangers of pointing out the flaws in designs. I try to remind myself that there are most likely missing details and nuances behind design decisions that I don’t know about. As Rebekah Cox says:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

That said, Ryan’s article reminded me that pointing out what’s wrong with a design (based on objective principles, not feelings) is the most effective way to figure out what’s right. And that process has to start at home. If we’re serious about relentless quality we have to be the biggest critics of our own designs.

Alex Faaborg for UX Magazine in Debating the Fundamentals: The geographic, temporal and political nature of usability heuristics:

On the surface, usability heuristics provide a simple checklist for making any interface perfect. But what is fascinating about them is the extent to which all of the heuristics are actually in direct opposition to each other, the extent to which they are geographic and temporal, and the extent to which they expose the designer’s underlying political views (at least in the domain of things digital). Usability heuristics present a zero-sum game with inherent tradeoffs, and it is simply impossible to achieve all of the heuristics simultaneously.

This is the best UX article I’ve read in a while. Like most UX designers I live and breathe the usability heuristics, and have always been reasonably comfortable with the tradeoffs, but this article perfectly articulates the complex interplay at work.

But it’s not just a theoretical exploration, I really appreciate the thought put into the practical approach to managing these complexities:

Novice designers memorize the list of usability heuristics and try to employ them in their work. As a more experienced designer, you may have already seen a deeper dynamic at play here. Instead of using heuristics as a simple checklist, try placing pairs of the heuristics against one another in a spider graph.  Achieving every ideal isn’t possible because the pairs exist in direct opposition. Realizing this, the challenge shifts to shaping a design that captures as much surface area as it can, given all the opposing forces.

This is one of those “I wish I wrote that” articles.

There’s a scene in Hot Shots! Part Deux (shut up, we all have our guilty pleasures) where Charlie Sheen’s character (Topper Harley) rescues Rowan Atkinson’s character (Dexter Hayman) from prison. The conversation goes something like this:

Topper: Dexter, I’m here to rescue you. Dexter: You don’t understand. I can’t walk. Topper: Why? Dexter: They tied my shoelaces together. Topper: Bastards!

The joke is funny, of course, (shut up, it is funny!) because of the ridiculous nature of the claim that tying someone’s shoelaces together can somehow stop them from walking around. We look at the situation from the outside and think they’re idiots - don’t they realize they can just untie Dexter’s shoelaces?

I often think of this scene when I hear designers defend their decisions by insisting that users will “figure it out”. I hear statements like “it’s not our fault that they can’t use this feature”, and I think about users with their shoelaces tied together, unable to move. We look at them with pity in our eyes - if they could only see the obvious and untie the knot, they would have no trouble using the site.

You Are Not The User

But of course, that’s not how it works. We think users are stuck because they aren’t untying their shoelaces, while they’re actually knee deep in the cement of poor usability we put them in. We can make T-Shirts that say “I am not the user” and wear them all day long, but somehow we still manage to find a way to blame them when something goes wrong. Not cool.

We will never be able to design web sites that don’t confuse users unless we observe them using our sites, and fix the issues that uncovers. We cannot think like our users - as designers we are simply too close to the product, and way too proficient in all things web. It reminds me of something Douglas Adams once said:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

There is a great post on the Agile Bits blog that talks about the difficulties of designing security systems. In one part they discuss the problem of designing for users and sum up the issue perfectly:

Security systems (well, the good ones anyway) are designed by people who fully understand the reasons behind the rules. The problem is that they try to design things for people like themselves ”” people who thoroughly understand the reasons. Thus we are left with products that only work well for people who have a deep understanding of the system and its components.

Stepping Into Their Shoes

We have to be able to step out of this cocoon of deep understanding, and the only way to do that is to regularly observe users as they make their way through our applications. Whether you take your laptop to a coffee shop and ask random people to give you a few minutes of their time, or set up full-scale usability tests, the payoff of uncovering usability issues on your application is so worth the time. What’s the upside, you ask? Matt Gemmel sums it up really well:

The biggest (and most lucrative) set of customers is ordinary people, without a computing degree or specialist knowledge. These are people with no interest in specific technologies, but only in how easily they can finish today’s tasks without reading the manual. Apple caters to that market; companies who loudly proclaim their device supports CSS3 and MPEG4 and SDHC don’t even understand that it exists.

If we can get into the heads of those ordinary people who use our products every day we’ll be able to meet their needs so much better. I agree with Jeff Gothelf on this one: test everything, regardless of its polish or fidelity:

Increasing your time with customers throughout the design and build process improves the outcome of your project by continually nudging the interface in a more appropriate direction. As an added side benefit, you also begin to build a user-centric culture within the company if it didn’t already exist ”“ a huge plus.

I’ll end with the words of Jeffrey Zeldman in Style versus design, because it articulates so well why this is such an important issue:

Not enough designers are working in that vast middle ground between eye candy and hardcore usability where most of the web must be built.

Most of all, I worry about web users. Because, after ten-plus years of commercial web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the web ”” which is what most of them do when they’re online.

Let’s realize that the problem is a little more complex than untying shoelaces. Better yet, let’s realize it’s our problem if users get stuck, not theirs. And best of all, let’s allow them to help us fix it.