user experience design

Is good design to be equated with functional?

Is good design to be equated with functional?

Musings on my past, good design, functionality, ergonomics, customer experience, taps, light switches and a juicer.

Is good design to be equated with functional?

That was the question. For the next 40 minutes I scribbled the answer to the ‘A’ Level History of Art question.  Twenty five years later two things strike me. Firstly, that my answer must have satisfied the examiner because I got a good grade.  And that after all these years, that question still sticks in my mind.  (My answer, not so much).  It sticks in my mind because I’ve spent most of my working life addressing the inverse of that question. Is functional to be equated with good design? More often than not, the answer is a resounding no! Design is treated as an afterthought (if at all). The result is systems, products and processes that are hard and nasty to use.

What do you do?

“So what do you do?” I am often asked.

I pause.  My job title doesn’t describe what I do. “Customer Experience” is not an activity; it’s not something you “do”.  Customer experience is something I strive to make better.  It is not something I am, as in I might be a designer or a developer or a marketer or a salesperson. I am not a customer experience. My passion is to help lead teams to create and curate great customer experiences.

So what am I?

I’m thinking that I should answer with what I am qualified in.

I am an ergonomist.

What does an ergonomist do? To quote from the Egonomics Society:

Ergonomics is about making life easier for people.  This includes the products you use at home, at play and at work, the places in which you live and work… and the system that keep day-to-day life functioning properly.

“So what do you do?”

I am an ergonomist. I make life easier for people.

Why do I do this?

Twenty five years ago, with the question “is design to be equated with functional” rattling in my head, I stumbled across Ergonomics as a degree course at Loughborough University.  As a degree I couldn’t decide whether I wanted to do; something scientific, something social or something arty. Ergonomics (or human factors as it is often known as) covered all three.

In the first year at Loughborough we had an Introduction to Ergonomics and Design course that was attended by design students as well as the ergonomists. Assessment was through a team project.  The problem my team addressed was the design of bathroom taps (or faucets if you are reading this is the US).

The tap project

Is good design to be equated with functional?

At the time, the design vogue for taps was minimalist and that meant smooth.  With wet or soapy hands it could be hard to grip and easily twist the tap, especially a problem for the elderly or less dexterous amongst us. We set up a rig to adjust resistance and measure the force involved in turning different tap designs. We had control data to work against.  It was a great, multi-disciplinary team and we created an elegant new design that subjectively measured to be more pleasing to look at, and the data demonstrated that with wet or dry hands it enabled greater torque to be applied. It was easier to use.

It was obvious!

This is the way all products should be designed – get the user involved and use data to validate your assumptions.  It is only in the last few years that this thinking is becoming more widespread.

Finally (with the poster child of Apple) we are beginning to see Functional equated with Good Design.

Hot or not?

Like that exam question, the design of taps has continued to haunt me.

But why am I rambling on about taps? Because there is still some quite shocking tap design still out there! Or rather, I suspect that if you know how to use this design you don’t see the problem with it.

Tap centrally positioned

Take a look at the above tap.  Sorry for the quality of the picture. It’s a tap in a cheap hotel I stayed in a while ago.

Which way do you turn the tap to get hot water? Do you turn the tap to the right, fully exposing the hot circle (move tap right = lots of red circle = lots of hot water).

Tap with handle twisted to right

Or do you move the tap to select the hot circle (move tap left = red circle selected = lots of hot water). But all you can see now is blue which is cold!

Tap with handle twisted to left

 

Now I assume that if you have one of these taps at home, you have learned the behaviour of this design, it is second nature to you. It is obvious to you!  The ergonomist in me cringes every time I see one of these taps, and I still have no instinctive idea which way is hot and which was is cold.

When you are designing products, do you apply empathy and try and think like someone else? Listening to Dan Pink’s excellent book To sell is Human, he talks about role play; imagine selling an everyday product to an imaginary customer who has time travelled from the 17th century.  (For example, try explaining buying a hamburger from a drive-in MacDonalds to someone from the past! You can’t even assume the time traveller will understand the concept of the hamburger, let alone a car…)

Take a look at the post I wrote about let’s pretend user testing, but this time role play as though you come from a different place and time.

Now do you think your product is still easy to use?

Here’s another example.

Light switch

The humble light switch. Is it on or off? Trouble is, this is a cultural question. In the US it is on, in the UK it is off. (This picture is actually the light switch in my daughters bedroom. It was unintentionally wired the wrong way round.  She’s recently grown tall enough to switch the light on and off. When I asked her the question, away from her room, “which way is it to switch a light on?” “Daddy,” she said, “that’s easy. On is up and off is down”. Your view of the world is how you learn it).

Juicer Vs iPhone

Is good design to be equated with functional. 

alessi juicer

I started by stating that I couldn’t remember much of my answer to this question. I do remember drawing one object to back up my argument. The Alesi juicer.  Undoubtedly a beautiful object. But form and function? I think not. As a desirable artifact to have in your kitchen? Definitely. As an orange juicer? Definitely not.  Read the reviews; here’s a typical one:

A nice product to look at but rather difficult to use. I managed to get more juice down my front than in a glass!

It is good design, but on a functional level it fails. There are far better juicers out there that do not have the aesthetic, but are far more effective, cleaner in getting the job of squeezing out a citrus fruit.

The Alessi juicer has something in common with the iPhone. Both are the product of visionaries. Both were driven by uncompromising individuals with a single minded design vision.  Both are products whose attraction ultimately lie in their design.  The difference between the two is that the iPhone is user centred whilst the Alessi juicer is idea centred. It delivers on the idea, not on the needs of the user.  One of the last times I met with Luke Barrett we talked about these products. If Apple and the Alessi juicer are driven by leaders for whom design is paramount, what about the other end of the scale. Products that are the result of design by committee. On a Wagamma placemat we sketched out the following matrix.

Quadrant

It was easy to fill the idea centred, group design box. You see this shocking design in almost all enterprise software. (“Enterprise software”. The term makes me shudder with unease. Because large organisations don’t call themselves enterprises.  It’s a label that has been applied by software vendors touting their software to be applicable to companies they perceive to be large, often unwieldy and the potential source of large revenue streams for them).

Is functional to be equated with good design? No, most certainly not! Because enterprise software is usually focused upon the functionality, the idea of what the user need is, and the how is not rooted in user centred design.

It is rare for a large organization to have a design visionary who passionately cares about the quality of the design in the same way that Steve Jobs did.  Go beyond the startup and design is almost inevitably going to be the responsibility of many people. Hitting that magic quadrant in the enterprise, the place where most of us should probably be, is going to be hard. It is, as this article suggests, the next UX revolution. I think we are getting close to this at Auto Trader. In the future I’ll write about it.

 

 

Rout me a parcel

Graham Charlton wrote a great blog on eConsultancy a couple of days ago on how on-line retailers are managing customer expectations. (Or not as the case may be). He takes it as far as the check out, but what happens next?

The ability for customers to track parcels and delivery is becoming increasingly common.

The requirement is simple. Take the package tracking status (that we have already) and display it to our customers.

The execution of this separates the customer led from the IT led. The former will take the internal codes and language, ditch the codes that mean nothing to the customer and translate the status into words the customer understands. The latter just display the internal codes and status verbatim.  Both deliver the same functional requirements, one delights, one confuses.

Compare the following:

1. BPost: what does “parcel is routed” mean?

status from bPost

2. Royal Mail: “We received item xxxxxxx at [Placename] DO on the 2010-12-22. The item is now ready for delivery.”

3 For exactly the same package at the same time, Amazon track its status as “Latest event: Out for delivery – Dec 22, 2010 4:34:51 AM”

As you’d expect, the eCommerce website does eCommerce the best.

IT chalta hai

“Hearing the words ‘I LOVE this…’ from a client is a magical thing”  So tweeted Graham Smith.

Now how often does “the business” say that that to IT?  Rarely I guess.  Why is that?  Why doesn’t “business” love IT?

I think the Indians have got a phrase for this: Chalta hai.

I’ve recently come back from India.  As always it was a pleasure to read the Indian newspapers and weekly news magazines.  In discussing the Commonwealth Games, several columnists in their English language columns made reference to the hindi ‘Chalta Hai‘.  There is no direct translation (hence the columnists use of Hindi) but “it’s all right” or “it’ll do” comes closest.

Chalta Hai is an attitude.  It is mediocrity.  The columnists applied Chalta Hai to service culture and getting things done (or rather the lack of it).  Whilst Chalta Hai may be an Indian affliction, India is not alone.  I’m going to suggest that corporate IT suffers from Chalta Hai.  There’s an industry mindset that success is just getting stuff delivered.  Success is  “it’ll do”.  Mediocrity is a sufficient goal.  To hell with the experience; who cares what the users think, it’s all about delivering functionality and features.  We’re happy if “it’s all right”.  No-one has the desire to hear the business say “I love this!”

Let’s bring some magic into the enterprise.  Let’s introduce a new acceptance criteria to our requirements; that the stakeholder who signs it off says “I love this”.

What would Sally do? Personas for retail financial services

Personas are ‘pen portraits’ that bring to life users or customers of a system, service or product.  Giving a personality and back story to your customers helps keep your thinking true to their real needs and goals.  Rather than using  ‘user’ or a segment descriptor such as ’empty nester’, or ‘this is what I would do’, what would Sally do?

Here’s a set of personas for financial service organisations, geared towards the retail / B2C market.  Sally is included (Shes skint).

View more presentations from marc mcneill.

Do customers want to customise your site?

Have you ever added a custom tool bar on your office set up?  Have your non-techy friends and family changed the background image on their desktop or changed their screen saver.  Is there a demand for customisation?

So here’s the question.  Do people really want to make your homepage look the way they want it to?  Is there a demand for iGoogle and netvibes customisation?  They look cool and are attractive to the geeks in us, but do they have mass market appeal? Is there any research out there on the take up of user customisation?

“…back when Windows 95 was released, users could easily change My computer to something more personal. Apple users had been able to do this for many years, and many of them did name their computers. But few Windows users took the opportunity to do this, suggesting that they saw the computer as more of a tool than something with which they wanted to have a personalized relationship.” (David Malouf)

Just because we can doesn’t mean that we should.  When you log into your bank account it could look like netvibes, complete with BBC news feeds and YouTube videos (you decide what you want).  But should it?

Why should your customers see your website as something to have a personalized relationship with, especially if you don’t engage them with a personal relationship throguh your other channels?

A picture tells a thousand words. So prioritize pictures not words

Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence.  This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement.  And we do it in words.  Those slippery things that are so often misunderstood.  Things get really slippery when we try to prioritize those words against each other.  Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority.  And because they are supposedly independent, you loose the inter-depedencies between them.  Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories.  It’s too early to be writing words.  Muda.  Create illustrations of widgets and features and functions.  Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire.  On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on.  Identify the stakeholders who will interact with the requirements.  For example the retail website, the operational support application, the finance system.  Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release.    Let them draw extra functionality if they like, but everything must be on post-it notes.  Now pull the post-it notes off, one by one.  What if we removed this? What would happen if it wasn’t there?  Is there something simpler we could do?  Something more elegant?  Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more.  Any less functionality would not be a meaningful release.  Now we can get down to writing the stories, focusing our effort on something we are agreed looks right.  We’ve prioritized pictures, outcomes over words; Picture Driven Design.

Fear of focus groups

I was recently talking to some IT professionals.  We were talking about customer journeys and understanding the customer needs.  They were second guessing these, making assumptions about what is important to the customer how how the customer would best interact with the application.

“How about running a focus group with customers?” I suggested.  Blank expressions.  “Not sure” came the response, “we’ve never done those before”.

But you have done that before.  Every time you run a workshop with the business, that is a focus group.  The listening skills are the same.  Effective facilitation, and using stimuli to promote debate, elicit opinions and test ideas- they are the same.   You just have a different audience and call focus groups something different.

IT should have no fear of talking to real customers, end users.  Getting them together in workshops is something that should come as naturally to IT as it does to the marketeers.  Let’s get focus groups into the vocabulary of any IT project.

User interface is a disruptive technology

Last year, according to Gartner, with belts tightening, technology executives need to focus upon disruptive technologies (that cut costs).  The top ten list of disruptive technologies makes strange reading.  How will social computing and mash-ups cut costs (enterprise 2.0?)  Most interestingly, coming in at number six on the list is “user interface”.  Now let’s leave aside the fact that a “user interface’ is hardly a technology (it is how technology manifests itself to the user) I’m interested by the fact that it can be considered to be disruptive. What is disruptive about user interface design?

But think a little further.  What is really disruptive is the realisation that good design is more than just adherence to functional requirements; good creative design is more than ‘bells and whistles’ or ‘gold plating’.  A good user interface will cut costs by enabling the internal user base be more efficient and productive.  A good user interface will enable customers to succesfully complete their transactions / goals.  In a world where poor UI on enterprise applications remains, maybe user interface is indeed a disruptive technology after all.

The user journey

“Faster, slicker, easier to use.  That’s how we sold it to the business.”  It is a common theme, IT have a system that is costly to maintain, hard to extend, is on a dated platform and no longer fit for purpose.  The business are persuaded of the need for a replacement.

This is what happened at an organisation I recently visited.  But it didn’t quite go to plan.  A number of years later and they’ve got an application that is slower, uglier and harder to use.  What happened was the business intent was distilled into requirements (based upon the existing functionality).  Each requirement was captured as a control on a screen.  These were bundled up and sent to India for coding, and the developers went and built a bunch of screens.  They considered interface design but not interaction design.  They focussed upon technical processes rather than user journeys and the resultant deliverable was something that functionally ticked all the boxes (it did what the specifications said it should do) but was ultimately rejected by the people it was intended to help. The code may have been great but that meant little to the business who found the application a pig to use.  Another failed multi-million dollar IT project.

User interface design is more than just screen design, it is about the journey the user takes to accomplish their goals.  Remembering that could have saved this particular organisation a lot of money.

Design vision

Don’t be fooled into thinking that you don’t need to do any design when you adopt Agile.  Agile development strives to deliver business value early and often, focusing on getting working software to market as soon as possible rather than dwelling in documentation and ‘analysis paralysis’.  But let’s be clear, “business value” and “working software” are not the same thing.  You can quite easily get something into production that fails to generate revenue, decrease costs or whatever other yardstick you use for ‘value’.  What differentiates the two of them is design.  I don’t mean big up front design that details all the features and provides a concrete spec, I mean a design vision that articulates what the product goals are and a roadmap for getting there.  And what is a design vision?  A short statement of intent is a good place to start, and soon after a user interface mocked up in pen and ink.  It is cheap and easy and helps bridge the path from idea to execution.

1 of 2
12