Month: <span>February 2013</span>

Seen recently in my Twitter feed:

I absolutely agree. Software should empower you, not distract you. It’s a tool, and like any good tool it should feel like a part of you. Once you know how to use it, the software itself should fade into your subconscious.

In cognitive psychology, they call this automatization. It’s what happens when you learn to balance and walk, learn to write or type, learn to talk, learn to drink from a water fountain, or learn to play a musical instrument.

Your brain very deftly, and quite without your knowledge, watches as you consciously and intentionally carry out repetitive or pattern-based tasks, often requiring lots of mental effort at first, and it creates little programs that do those same tasks without having burden your conscious mind with the specific moment-to-moment mechanics.

Soon, after some practice, you find yourself doing the same tasks seemingly effortlessly, and with high precision, while your conscious mind is free to direct your activity at a “higher” level.

But Jake, what does this have to do with UI design?

Because humans are so good at automatization – so good in fact that they do it nearly universally without even knowing it – user interfaces that are easier to understand quickly, will be easier to automatize.

By minimizing, focusing first on understanding, nailing key features, and minimizing frills and clever pixel-wrangling, you just might find that people actually like using your software more.

Why? It won’t get in their way. It’ll be quick to learn. It will feel good to use. It’ll probably run faster. And as an extra benefit for you, it’ll be easier to maintain and have fewer bugs.

And once people learn your UI, your software will become another useful tool, by accomplishing the task you designed it for. Just like a water fountain, or a spokeshave, or a musical instrument.

Don’t get me wrong – I’m all for beautiful designs, but for me at least, function comes first.

Apple has done an amazing job in this regard over the last 12-15 years, and not just in the iPhone/iPad world. They’re not the only ones, but at least in the consumer technology world, they’re almost undisputedly the best at it.

Less really is more…

Computers are hard. Software is hard. Many geeks reading this have a propensity for figuring out hard things, and an aptitude for seeing through… um… difficult user interfaces.

But that’s not good enough for most people. You’ve probably invested many hours in your UI and you think it’s great – but most likely it needs to be easier.

Here’s something to try:

Ask a non-geek to use your software for the first time and watch them carefully. It’s probably not nearly as easy to understand as you thought it was.

Where do they get stuck? Where do they ask questions, and what about? When do you see their face light with recognition and understanding? Try not to offer help or explanation. Let them explore and get stuck. You want to know about the problems people will hit when you’re not there with them.

Now before you do anything else, make some quick notes… And then go help your poor test subject.

Now it’s time to fix it. You’ve got your notes right?

One good way to cut through confusion is to make your UI simply… less.

Cut away all but the essential settings and controls, geeky preferences, custom scrolling ballistics, the animated GIF of your cat, and the sound you hear in your first-run walkthrough. (In fact, see if you can get rid of the first-run walkthrough altogether.)

Make your top one or two key interactions dead-easy. Then look again and see what you can do to help people understand your UI as a tool. Just by looking at it.

And then go test it again. Ask the person you showed it to last time. Then ask someone new. (You’re taking notes, right?)

Less really is more… Except when it isn’t

There are of course exceptions – scenarios for which this is exactly the wrong idea. For example, users often automatize clicking the Okay button on two-button dialog boxes.

But if the question you’re asking is:


… then you’re doing it wrong. Less UI isn’t always better UI. Sometimes you need to be “in your face”.

Some things to keep in mind

Here’s a short list, off the top of my head, of some of the things I try to remember when I’m thinking about UI design:

  • Form follows function
  • Focus on “core scenarios”
  • Don’t make me think
  • Simplify, simplify, simplify
  • Text is really important
  • Don’t assume people will read it
  • Do you really need another preference?
  • Be consistent, in context
  • Respect prior art

I’m planning on writing more on these and lots of other UX-related stuff soon.

Stay tuned…

User Experience

Just tripped over The Old Reader in my referer logs. Has anybody played with it? Here’s how they describe themselves:

Welcome to The Old Reader, the ultimate social RSS reader. It’s just like the old google reader, only better. We’re in beta right now, but we’re constantly working on improvements and new features.

Not sure what “the ultimate social RSS reader” means.

It looks like it’s being built by a 3-person team, and they seem to have on the order of less than 10K users, but are growing. (And they have a blog.)

If they’re really serious about aligning their service with the (perhaps) ailing Google Reader, then they’re well positioned to win a lot of new users &emdash; enough new users to knock themselves off the air, unless they’re built to scale both their tech, and their income.

As many have said, running a centralized RSS reader is probably going to be enormously expensive for a large number of feeds and users.

I wish them luck!


Yesterday, Dave Winer described an AHA moment he had after talking to some folks about Google Reader’s possible impending Syncpocalypse. He asks:

“Why isn’t this something a news org jumps on. It’s their business. And for crying out loud — do it with a revenue model. No paywall. Just charge the users for the service. Make this a market. Let’s start building in a non-fragile way.”

I think this is a great idea, and if it gets any traction, I’d be happy to help with what limited time and resources I have.

I’d also like to offer a pair of suggestions to anyone who wants to do this: Clone Google Reader’s API, and support OPML for importing feeds, as many feed reading apps already do.

Cloning Google’s API and supporting OPML would make it as easy as possible for developers and their users to migrate to new services, and would open the market up to real competition, which is sorely needed in this space.