Paving the cowpaths: using architecture concepts to improve online user experience

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.


Embracing boredom

In Alone Together: Why We Expect More from Technology and Less from Each Other Sherry Turkle tells a story about having dinner in Paris with her daughter, Rebecca. While they are eating, Rebecca gets a call from a friend in Boston, asking if sh’s available for lunch. Rebecca simply answers that it won’t be possible, but that Friday could work. She doesn’t even tell her friend that sh’s currently in Paris. Sherry has mixed feelings about this:

I was wistful, worried that Rebecca was missing an experience I cherished in my youth: an undiluted Paris. My Paris came with the thrill of disconnection from everything I knew. My daughter’s Paris did not include this displacement.

I told me wife this story later that evening, and we started talking about our own tumultuous 30-day backpacking trip through Europe at a time when our relationship was”¦ well, let’s just say it was on less stable ground than it is now (remind me to tell you how we broke up on top of the Eiffel tower and got back together in Venice).

We talked about the truth in Sherry’s words – how being so utterly disconnected from the rest of the world played a big role in our ability to immerse ourselves in the newness and strangeness of the culture around us. We were only able to check email about once every 3-4 days. I can’t even imagine how I’d be able to go that long without email now, but back then it wasn’t a big deal. Less email = more time for walking through the streets of a new city.


Being your own biggest critic

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.

Deluge of Content on the Web Swamps Yahoo (and puts content creators in a tough spot)

The Wall Street Journal in Deluge of Content on the Web Swamps Yahoo:

As Web traffic explodes, Internet companies are struggling to profit off ads shown next to the articles, videos and other content offered to viewers.

It’s a simple rule of any market. The more information that is created, the more the value is reduced. And despite attempts to woo spending with bigger, bolder and more targeted ads, services that help consumers navigate that content, namely search, remain the big money makers online.

As I (and many others) have written before, it doesn’t look like display advertising is a sustainable business model for media sites going forward (and I think we can agree that it makes for a pretty bad user experience). This puts content creators in quite a predicament: how do you make money from producing content? The WSJ piece points to the central problem here:

“People tell me that content is king, but that is not true at all,” says Rishad Tobaccowala, chief strategy and innovation officer at Vivaki, the digital-media unit of Publicis Groupe SA. “Most people make money pointing to content, not creating, curating or collecting content.”

Although the value of pointing to content is indisputable, we need a better way than display ads for content creators and curators to make a living. And I don’t think we quite know what that looks like yet.

A Fresh Look At Usability Heuristics

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.

Hot Shots, Shoelaces, and Designing for Ordinary People

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.


In defense of RSS

There was plenty of chatter about RSS over the weekend, mainly because of this “you’re doing it wrong” article on Ars Technica.

Most of the responses I’ve seen are strong defenses of RSS, and I’m happy about that. There has been so much talk about Twitter replacing RSS that I’ve been wondering if anyone else still uses it as much as I do. In fact, because of the iPad and apps like Reeder, my RSS usage is at an all-time high.

Marco Arment argues for a combined Twitter/RSS setup:

I can follow tons of low-traffic sites and keep my reading list more diverse than if I relied only on social links, but other people ensure that I never miss anything great on the high-volume sites.

Ben Brooks has a different use case (more similar to mine) – he subscribes to lots of feeds, but he doesn’t allow the unread count to bother him. He makes a good point about not blaming RSS if you feel overwhelmed:

A tool is a tool. Should I get mad at my car because there are thousands of miles of road I haven’t driven yet to drive? No. If you don’t like RSS don’t use it. If you want to use it but don’t want to have thousands of items, then use it like Marco does. Or use it like I do and check the feeds more often.

But of course, no discussion on RSS is complete until its creator weighs in. Dave Winer blames feed readers (like Google Reader) and their insistence on showing you how many unread items you have, and asks us to separate that from the technology itself:

If you miss five days of reading the news because you were on vacation (good for you!) the newspaper you read the first day back isn’t five times as thick as the normal day’s paper. And it doesn’t have your name on the cover saying “Joe you haven’t read 1,942,279 articles since this paper started.” It doesn’t put you on the hook for reading everything anyone has ever written. The paper doesn’t care, so why does your RSS reader?

These guys all make a very good case for RSS so I’m not going to say too much more about it. I do want to add something I haven’t seen mentioned before though: using folders in your RSS reader to help manage the deluge of information. Here is a screenshot of my folder structure in Reeder:

RSS folders

I have a certain set of blogs that I tag as favorites, and those are the ones I read first. If ther’s time I move on to the others.

Note that I have a folder called “Large tech blogs”. The usual suspects are in there: TechCrunch, Mashable, Ars Technica, Wired… These blogs post a lot, so when the unread numbers get out of control I typically just scan some headlines and then mark all as read. With the big blogs I know that if something is really important, Twitter will tell me.

RSS will remain an important part of my workflow, and since I turn dock unread badges off, I don’t feel like my app of choice is silently judging me.

Setting up folders and actively managing your RSS feeds is hard work. But the payoff is huge for me – I can quickly get a broad overview of what’s going on in the industry without having to rely on the fleeting nature of a tweet coming across my timeline.

I’m a die-hard fan.

(By the way, if you’re interested in following my shared items, you can do so here)


Apple and Faster Horses

The Harvard Business Review says they have proof that Henry Ford never said “If I had asked people what they wanted, they would have said faster horses.” It’s an interesting piece, but it’s the conclusion I want to quote here:

The real lesson learned was not that Ford’s failure was one of not listening to his customers, but of his refusal to continuously test his vision against reality, which led to the Ford Motor Company’s failure of continuous innovation, resulting in a catastrophic loss of market share from which it never recovered.

Translation: regardless of where your innovative ideas come from, make sure you test those ideas with users and learn from their feedback.

The iPhone might have been one man’s vision, but the way users interacted with the first generation iPhone paved the way for the iPad and the iPhone 4. They tested their vision with a real product, and then learned from it.


  1. 1
  2. ...
  3. 184
  4. 185
  5. 186
  6. 187
  7. 188
  8. ...
  9. 194