Seeking Rhythm in Design

Rhythm is pervasive. Binding music, shaping our daily routine, fusing us as a collective. Whether it knits or disrupts an experience, look hard and you’ll find rhythm lurking at its core. This talk will examine rhythm, its role in design and seek to demonstrate that, despite it’s omnipresence, rhythm is a concept which is too often ignored.

If like me, you’re a Snap fan, please head on over to the panel picker and vote me up. Thanks.

Oh oh, it’s a passion, oh oh, you can feel it, yeah
Woh oh, it’s a passion, oh oh oh-oh oh-oh oh-oh

Great lyrics.

Silverback was built to scratch an itch: Guerilla usability testing should be quick and easy-to-run, so it always felt frustrating having to set-up a video camera when macs have a far more subtle equivalent built in to them.

That’s half the battle. But for me, the real strength of Silverback is putting usability testing in to the hands of lots more people. Formal usability testing certainly has its place — sometimes you need a level of fidelity that you’re only going to get from quantative analysis. But, more often than not, usability testing is sacrificed because it’s considered too expensive or arduous. Silverback tries to solve that problem by being available where and when you need it.

You really don’t need permission anymore. Grab the Silverback demo, borrow a friend and run a quick lo-fi test over lunch. Trust me, the results are far more effective than the theory.

Enough guff, this is already reading like a Silverback pitch when I actually wanted to talk about a particular form of low-cost usability testing called RITE. RITE stands for Rapid Iterative Testing and Evaluation method. From the title you can probably guess RITE fits with the Silverback philosophy. It’s certainly something we’re experimenting with at Clearleft.

Apart from a funky sounding acronym, RITE is also a form of discount usability testing which sets out to avoid one of the more typical frustrations with the standard approach: Seeing that blindingly obvious problem come up repeatedly during several sessions. Some issues really don’t need twelve more participants to hammer home the fact that there is a problem. “Moderator: Ahem, so let’s just pretend there is a Buy button…”

That’s where the iterative part comes in. Only rather than doing this after twelve participants have mentioned there is no Buy button, you iterate between sessions. You add the Buy button and get back to testing your product (as well as testing your fix).

Obviously there are some problems that can’t be remedied in this way. RITE deals with this by classifying problems into four discrete categories. Excuse the tawdry labels — they’re my own addition:

• Fix-now.
  Problems with an obvious cause and solution that can be remedied immediately. Labelling issues being the canonical example here. Obviously, there’s a skill in picking these, but these things are normally indisputable (and so they should be).
• Fix-later.
  Similar to Fix-now only the solution cannot be implemented within the timeframe of the current test.
• Flummoxers.
  Problems without obvious causes or solutions that need to be argued discussed post-test.
• Furballs (Sorry…’Curve balls’ doesn’t start with an F).
  Issues resulting from exterior forces…maybe the test script is screwy…or the participant is an ex-girlfriend and she decides to put a chair through your monitor.

Silverback’s great for capturing the flummoxers. Hit the plus button on your Apple remote during the test, and Silverback adds a marker in to the movie. This allows you to jump to these when you examine the videos later.

On a very rudimentary level, that’s the Rapid Iterative Testing and Evaluation method. Obviously, I’m just scratching the surface here. If you want to read more, I suggest you read this far more thorough account of this stuff in action.

It’s not for everyone. One of the drawbacks being that you need someone on-board who can make the changes to your prototype. Anyone attending mine and Richard’s workshop at dConstruct this year, will know this is something that is within reach of IAs these days. We plan to spend a large part of the day talking about the mechanics and benefits of high-fidelity prototypes. These kind of prototypes are perfect for RITE.

This is lovely for many reasons, but it’s the last line that gets me: Context over dogma.

What a beautiful way to put it.

Some context: One of the principal reasons, I work at Clearleft is because we get to work with leading-edge companies and ideas. I like this; It challenges me and most of the time, gives me an opportunity to deliver work that I’m proud of. But one of the criticisms I’ve recently faced is that my work has been too ‘safe’. What do I mean by safe? Well obviously that’s open to interpretation, but you’d be forgiven for interpreting this as a compliment as opposed to a criticism. Afterall, safety offers protection and reduced exposure to risk, which from a business perspective, is something most of us would welcome.

But in this particular case safe wasn’t being used as a compliment. It was in fact, a term of disapproval and would be more accurately read as conservative or even unenterprising.

No, I’m not about to launch in to a rant about a client. In fact, I think the client’s criticisms were — on many levels — fair. The reason I mention this is because I see this type of criticism increasingly directed towards traditional approaches to user-centered design and this post is my attempt to try and understand why.

Allow me to generalise: As an Information Architect, my toolbox contains a host of tried and tested methods, many of which focus on the derivation of users’ goals. It can be hard work, but I know as long as I use the tools appropriately, they provide me with the ability to extract the basis of a solid proposition: a set of goals which if met, can form the essence of a successful product or service.

The problem is that goals exist in several forms and while I can rely on traditional IA tools to derive what Cooper termed End Goals, the Super-Best-Friend’s web (that’s Web2.0 to marketeers) has created an ever-increasing demand for their less tangible, more subjective counterparts: Experience and Life Goals (I’ve blogged about these previously). Within this space, a proposition has the potential to move beyond the realm of safe, even defensive design and in to the domain of delightful, meaningful experience.

Stephen P. Anderson captures this tension superbly, describing the jump from task-driven to meaningful experiences as crossing the UX chasm:

“With rich interactions, the Social Web, and other recent web application advancements, we are reaching the point where it’s finally appropriate to discuss things like ‘joy of use’ and ‘pleasure’ in interface design. This is also the point at which we must stop designing only to support tasks and begin designing to support experiences…I dub this difficult transition the UX grand Canyon. This is the chasm between designing to support tasks (with a focus on products and features) and designing to support experiences (focusing on people, their activities, and the context of those activities).”

Stephen P. Anderson, Getting from Tasks to Experiences: What’s Next in Interface Design

Substitute tasks for End Goals in the previous quote and hopefully you can see where I’m going. In case not, I’ve ruthlessly stolen Anderson’s pyramid diagram and then scrawled on it to demonstrate what I mean.

The base of our pyramid is built on the solid foundations of functionality, reliability and usability. All coveted attributes, that can typically be met via the fulfilment of user’s End Goals (and should in no way should be ignored). But in order to create experiences that lift users towards the peak of the pyramid, we must also pay attention to their Life and Experience Goals as well.

In hindsight, the project I alluded to earlier probably focused too heavily on End Goals and left little room for anything more ‘meaningful’. Budget and time was certainly a factor (isn’t it always?), but I also believe this was symptomatic of the persona-driven approach I adopted. This resulted in a thorough collection of End Goals which in my opinion was both necessary and worthwhile, but not enough.

The question is how? In my opinion, there’s huge scope for innovation in this space. Lots of smart people are interested in doing the same and it’s certainly something I’m focusing my 20% time on at the moment. It’s also something I’m intending to blog about as I explore different approaches. But for now it just feels good to get this stuff down.

As Jeremy noted earlier in the year, one of the most useful features is the ‘next’ bookmarklet, which simply loads the next unread post from your subscriptions. The crucial point here is that the the user is directed to the content’s original source as opposed to the homogeneity of the feed reader.

As trivial as this may sound, this little gem has had a fairly profound effect on my blog reading experience. Rather than being thrown knee-deep into unread message anxiety, the bookmarklet circumvents this, directing me to the next unread post in my queue of subscriptions. It’s subtle, but it goes along way to re-introducing an element of much-missed serendipity into the blog reading experience. A kind of one-armed bandit for the feed-reader generation (ahem).

Flicking through the Google Reader preferences, I noticed that the bookmarklet functionality has been extended to include tag specificity. Now I’m sure some people would argue that this is all getting a bit granular, but for me, this has added another layer of goodness. I really value the way in which I can now segregate my feeds to suit the mood I’m in. For example, there are certain blogs I can’t live without and others which only get read if the demands of the working day allow. Hence my must-reads are now tagged as ‘favourites’ and I now have a ‘next (favourites)’ bookmarklet sitting in my favourites toolbar.

I have to commend the Google Reader engineers for their ingenuity here. Lots of people are working hard to try and tackle the information overload that RSS aggregators lead to, but the focus (understandably) tends to be on achieving this within the app itself. By ignoring these constraints and focusing on the user’s goals, the good folks at Google have provided an elegant and simple solution that goes along way to solving a problem that every other reader suffers from.

You’ll find the next bookmarklets under the Goodies tab within Settings.

“Enough confidence to believe you can solve any design problem and enough humility to understand that most of your ideas are probably bad. Enough humility to listen to ideas from other people that may be better than your own and enough confidence to understand that going with other people’s ideas does not diminish your value as a designer.”

Larry Tesler, Vice President of the User Experience and Design group, Yahoo in Dan Saffer’s Designing for Interaction.

“…watching a tool in use is the same as observing a conversation. everything, in a sense, has its inputs and outputs. From that point of view, the boundary between “interactive” and “noninteractive” tools start to dissolve.

Interaction design is largely about the meaning that people assign to things and events, and how people try to express meanings. So to learn from any tool, interactive or not, go watch people using it. You’ll hear them talk to the tool. You’ll see them assign all sorts of surprising interpretations to shapes, colors, positions, dings, dents and behaviors. You’ll see them fall in love with a thing as it becomes elegantly worn. You’ll see them come to hate a thing and choose to ignore it, sell it, or even smash it. And I guarantee you won’t have to do much of this before you encounter someone who makes a mental mapping you would never dream possible. And you’ll learn from that.

I’ve been using tea kettles as an example in some of my teaching, because on the one hand kettles are so familiar to us, and they’re only interactive in a borderline, predictable, mechanical sort of a way. But once you start to examine the meanings involved with kettles in use, you realize they have things to say that people would love to know, but most designs allow them to be said. “I’m getting hot, but I have no water in me.” “My water is a good temperature for a child’s cocoa.” “I’m too hot to touch.” “I need to be cleaned.” And so on.

Marc Rettig, Founding Principal, Fit Associates in Dan Saffer’s Designing for Interaction

Complex information, such as price lists and timetables, cannot be designed on a preconceived grid. The page arrangement has to stem from the content and structure of the information itself. First you have to find the shortest and the longest elements, and then ignore them; if your layout accommodates the extremes you will end up making allowances for a few isolated exceptions. The thing to do is make the bulk of the matter fit, then go back to the exceptions and work with them one by one. If there are only a few long lines in an otherwise short listing, it should be considered an opportunity to flex your creative muscles: design them or rewrite.

Eric Spiekermann & E.M. Ginger, Stop Stealing Sheep and find out how type works

Cooper divides user’s goals in to three distinct categories, noting that these can range from highly specific product expectations through to more general aspirations. These are End Goals, Experience Goals and Life Goals.

End Goals are perhaps the most obvious of the three and represent the user’s core objectives when engaging with a product. Hence, when I use my email application, one of my end goals may be to read my latest email from Joe Bloggs. Naturally, it’s these kind of objectives that are commonly prioritised by an effective UI – and rightly so – if I can’t read my email I’m unlikely to want to use the that product again.

Experience goals are a more emotive subject concerning the way a user aspires to feel when engaging with a product. As opposed to End Goals, Experience Goals are typically unconscious sentiments and as such can be difficult to articulate. When user testing, we often preach that a system should never undermine or insult the user’s intelligence. This is largely due to the damaging effect this can have on to experience goals. Each time we reduce a user’s sense of achievement, we are in danger of affecting their self-esteem or at least encouraging a sense of resentment to the system itself.

Life Goals extend beyond the context of the current system, representing the more general aspirations of the user. These range from the more tangible ambitions such as running your own business, buying a bigger house to something more personal like earning the respect of your peers. Although Life Goals are unlikely to be directly related to they way in which user interacts with a system, they remain useful in explaining the underlying drivers that bring the user to the product in the first place.

Due to their more tangible nature, End and Experience Goals are inherently more measurable than their Life counterparts. As a result, they often receive greater focus during design. But it’s important not to neglect Life Goals; Cooper notes that these rarely figure directly in the design of specific elements of an interface and to an extent I’d have to agree. Nevertheless, as social software evolves, the potential for achieving Life Goals is greater. In fact, achieving all three is the mark of a great product.