Jeckecko

Context over dogma

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.

Safe

I’ve been wrangling with something for a while. I was hoping the wrangling would end and I’d reach a logical conclusion to this all. And then blog about it. But that’s not happening so I’m resorting to a splurge. Maybe the conclusion will come later?

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.

Readlet

Google Reader has been my feed reader of choice for a while now. There’s no deep-and-meaningful-here — it does the simple things well and that’s all I really want from this kind of tool.

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.

Humility & the Interaction Designer

When asked what personal qualities make a good interaction designer, Larry Tesler highlighted humility:

“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.

Listening to 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

Ignore the Exceptions

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

No

Oh deary me. The new(ish) Marks and Spencer website has a flash intro. I so hoped these days were behind us. I don’t know what’s more disturbing, the collective frustration of the site’s users or the fact that a designer somewhere still thinks this is a desirable experience. Way back in October 2000, Jakob Nielsen’s provocative article on Flash noted that “one of the Web’s most powerful features is that it lets users control their own destiny. Users go where they want, when they want”. Even Jakob himself admits that Flash has come along way since he originally published this article, but this statement certainly still remains true. Unfortunately, it looks like someone forgot to tell M & S.

User Goals

Alan Coopers’ About Face 2.0 talks extensively on the importance of personas during the design process. At Clearleft, we use many of the approaches he recommends. Just recently, I was leafing through the relevant chapters and was reminded of a smart breakdown Cooper gives on what lies at the core of personas: user goals. It’s often tempting to clump goals together under a universal banner, but Cooper’s breakdown reminded me of the dangers of such an approach. Different elements of the UI can target different goals so it’s important to keep the full range in mind.

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.