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.

(more…)

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:

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)

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.

Back in 2004 Adam Greenfield wrote down some ethical guidelines for user experience in ubiquitous-computing settings. He starts off as follows:

Principle 1: Default to harmlessness. Ubiquitous systems must default to a mode that ensures their users’ physical, psychic and financial safety.

That might sound a little overly dramatic, but as we’ll soon see, it’s a very important principle for a designer to keep top-of-mind. Adam goes on to say this:

Principle 5. Be deniable. Ubiquitous systems must offer users the ability to opt out, always and at any point. As an absolute ethical imperative, users must be afforded the ability to make their own meaningful decisions regarding their exposure to ubiquitous perception, the types and channels of information such exposure will necessary convey, and the agencies receiving and capable of acting on such conveyance. Critical to this is the ability to simply say “no,” with no penalty other than the inability to make use of whatever benefits the ubiquitous system offers its users.

Now. Think about those principles, and then have a look at the newsletter preferences page for eBucks:

The text in the opt-out line reads:

I’m not concerned with my eBucks balance and I don’t think I should be the first to know about all the latest news.

It’s an interesting content approach taken by eBucks, and one I would argue violates both principles I quote above. They are basically making you feel out of touch (“be deniable”) and a little bit stupid (“default to harmlessness”) if you don’t subscribe to their newsletter. Are they also implying that you won’t be able to view your balance if you don’t subscribe? Probably not, but it can be interpreted that way.

Fast forward a few years after Adam’s article, and we now even have a name for this type of tactic. It’s a classic example of persuasion design:

Persuasion design doesn’t share User-Centered Design’s ethical neutrality. Instead, it makes an implicit but undeniable judgment that certain behaviours are preferable to others.

Persuasion design prioritises business goals above those of the user, and its values are irreconcilable with empathy, the central value of User Experience.

This is just one example, but you can see it everywhere. It might seem innocent at first, but it’s such a slippery slope to the evil of dark patterns. We need to consider the implications very carefully before we employ such techniques.

Frank Chimero on why designers should learn to code:

Design decisions are not only affected by the characteristics of the content being designed, but also the qualities of the format. The best way to understand the characteristics of the web is to speak its language.

Good design and good markup provide structure to content. Good markup is a fundamental part of good design: beautiful on the inside, beautiful on the outside. HTML and CSS give another venue to provide structure to content in the native language of the web, and learning these guides decisions by surfacing the affordances of the medium. Design decisions are affected by both the content and the format, like how a sculptor would make different decisions if she were working with clay rather than marble.

Spot on. The whole post is worth a read, and Frank gives some good suggestions for resources to help designers get started on coding.

A couple of weeks ago our 2-year old daughter threw my wife’s phone in the swimming pool. The resulting journey through the Vodacom customer service labyrinth to replace the phone was frustrating, but it also gave me a new level of understanding and empathy for the immense challenges of providing customer service to hundreds of thousands of people.

This is an article about social media, customer support channels, and the principles every company should establish in their culture to serve their customers better. And (spoiler alert!) I do manage to get a new phone for my wife.

“Umm, So, Our Daughter Threw My Phone In The Pool”

What’s most surprising about getting a call about my wife’s phone suddenly finding itself at the bottom of our pool is how completely nonplussed I was about the whole thing. When you become a parent the kinds of things that upset you change significantly. I think I’ve discovered a pattern: if there is no blood involved, there’s really no reason to get upset. So after establishing that there was no blood involved, I proceeded to the next step – trying to replace the phone.

(more…)

In There Will Be No Files In The Cloud Fred Wilson argues that file-based cloud computing will become a thing of the past:

This is why I love Google Docs so much. I just create a document and email a link. Nobody downloads anything. There are no attachments in the email. Just a link. Just like the web, following links, getting [stuff] done. I love it.

That’s the future. I’m pretty sure of it.

He has a point, but I think it’s important to clarify what he means by “file”. Sorry to go all Wikipedia on you, but I promise ther’s a point on the other side. Wikipedia defines a computer file as follows:

A computer file is a block of arbitrary information, or resource for storing information, which is available to a computer program and is usually based on some kind of durable storage. A file is durable in the sense that it remains available for programs to use after the current program has finished.

The point being that a file is a block of data that is accessible to the programs that need it. Based on that definition files are certainly not going away, because software will always need access to the data that makes it more than a pretty shell.

(more…)