I'm Todd Sieling, and I help design software experiences and strategies for the web. Here I write and can be contacted about creating humane, effective and memorable products for the connected world.

Learn about what I bring to making better software

Not So Obvious: Context and the Apple Remote

Dec 1st, 2009 Comments 2 Tags: , ,

The proverbial They are often heard to say that a hallmark of good design is that it’s obvious.

It’s hard to argue that understanding what something does should not be as immediate and easy as possible. There are exceptions, such as in games where exploration and challenge happen in part by decrypting the utility and purpose of the unfamiliar.

Embracing that maxim, however, can lead us to dismiss the reasoning behind a design choice when the need itself isn’t immediately obvious. I learned just that by taking a close look at the recent update to the Apple Remote and its puzzling addition of a Play/Pause button.

Read more »

Comics and Keynote: Testing UI Flow in Wireframes

May 28th, 2009 No comments yet. Tags: , ,

A couple years ago I learned from Paul Hibbitts a way of using slideshow applications for testing the flow and completeness of a design. Typically, I use Apple’s Keynote for this, though PowerPoint or Impress can work as well.

The essence of the method is to put all screens and all their states into sequences that follow a task or scenario. Paging through that sequence, imagining or even pointing to screen elements as you go, brings missing pieces and potentially confusing points into focus, often with shocking speed.

I’ve used the technique in a number of projects since then, always with good results. But in describing it with others I could rarely put my finger on why it worked so well for spotting what was otherwise missed when just looking at the wireframes on their canvas.

Yesterday at lunch I was talking up this method once again, but this time I hit on what I think explains its effectiveness by drawing from Scott McCloud’s Understanding Comics.

Read more »

The Four-Legged Dance

Apr 27th, 2009 No comments yet. Tags: , , ,

Last week Garrett Murray’s commentary on the state reviewing culture on the iTunes App Store reviews circulated through the the blogaverse, catching my eye by way of Lachlan’s Pool Room.

Garrett’s application, Ego (iTunes Link), lets iPhone users check in on their Google Analytics stats on the go. A snafu with Analytics caused his app to be blocked, but in true web spirit Google and Garrett worked out the problem, and an update to Ego was submitted into the App Store’s approval process, which takes about a week.

Meanwhile, on the App Store and Get Satisfaction, Ego customers reacted badly, giving rise to the Garrett’s two core grievances on how commenting on the App Store and elsewhere works:

  • Reviewers can be quick to criticize and don’t read every detail before doing so.
  • The App Store doesn’t give developers a way to respond to specific comments, or comments in general.

These are fair criticisms, one rooted in problematic human-computer expectations (and if we acronymize that to HCE, we can go on speaking tour), and the other in the design of the interface at the App Store. Along with people commenting on Ego’s problem, we have Google Analytics and the App Store not coming off very well. But there’s a fourth leg in this interaction dance, which is how the Ego app itself handled the unexpected use case of being blocked by Google. Read more »

Efficient vs. Effective

I came across a short post on a Google-watching blog that draws from some statistics on the most commonly-used features in MS Office:

Jensen Harris, Group Program Manager of the Microsoft Office User Experience Team, published in 2006 a list of the most used features in Microsoft Word 2003, according to data collected from the users who opted for the Customer Experience Improvement Program:
1. Paste (11% of the usage)
2. Save (5.5% of the usage)
3. Copy
4. Undo
5. Bold

These five commands account for 32% of all the command usage in Microsoft Word 2003, as they are used very often.

The post goes on to say that as a development strategy, Google’s office-apps development teams could use those stats to refine the few operations that are used most, rather than trying to cram in more numerous and more complicated features. On the surface, this makes some good sense: follow what people are doing most with your apps, and support them as much as you can. But it misses some of the deeper thinking that can make the difference between an application that does just enough to one that truly evolves.

One thing that relying too much on statistical usage data can get you is a blind spot for parts of the application that are important, despite a low frequency of use. An anonymous commenter points this out with a gentle poke:

This is like saying that most time spent in car involves going and only a little stopping, therefore stopping is not important!

True, that. Sometimes it’s useful to take an idea to an extreme to show its weak spots. The more problematic thing with making plans by stats alone is that they opt for incremental gains in efficiency or raw power without stopping to ask the question: why do people use this feature so much?

Probing the reason for high frequency of use can reveal opportunities to solve underlying problems. That pasting is the #1 feature suggests that data isn’t moving from one document into another, or replicating through the same document, intelligently enough. A user who repeats a Paste command over and over might not be hip to the magic of Find and Replace. That Undo is at #4 suggests that people are making a lot of mistakes or changing their minds. It could be that the natural number of typos pushes Undo to the top five, but it could also be that usability issues are leading to mistakes or unwanted results. Making it faster or easier to Undo a mistake isn’t better than preventing the need to reach for Undo so often.

To appreciate this, consider how Google Docs does solve an underlying problem of trust in the software to get around the need to click Save so often. Again, from the post that kicked this off:

Google Docs auto-saves documents so you don’t need to press the Save button…

Provided that immediate saving doesn’t create other problems, like exposing thoughts before they’re ready to show, this is a perfect example of solving the problem rather than just making it easier to take the action.

Stats can be very useful, but they’re misleading without an analysis that questions the reason for a trend. Spending some time to ask why a feature is needed so much in the first place can reveal the way to a better experience, not through statistical gains in efficiency, but by removing the need for the feature altogether or showing a better way to the same result. After all, the best solution doesn’t make problems easier to solve, it makes them go away altogether.