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

 

 

Follow fast

I’ll pick on a random industry. Let’s say you are an airline. Part of your digital strategy includes a refresh to your website (maybe you were inspired by this presentation I did a while ago on digital for airlines!). You’ve built a business case and secured funding for the project.  First things first, you get a design agency in and set them to work.

Some sort of competitor analysis is performed that proabably includes features and functions that “we like”, (for example ‘the tactile sliders in kayak.com. We like!  And an iPhone-like coverflow, got to have one of those…)

The information architect takes these ideas away and starts building wireframes and the creative team produce designs that bring these wires to life.  The team come up with lots of new, innovative ideas.  This is after all a ‘refresh’, and ‘innovation’ was probably one of the words in the brief.  The creative is fresh and ‘of the moment’, the IA has developed some new interaction models that are unique and compelling.  The business is sold on a new, innovative way of interacting with their customers, something that no one else does and will blow all their competitors away.

I’ve been bouncing ideas around with Luke Barrett (and because he doesn’t blog, I’ll write them down for him) around this approach; specifically the value of innovation against ‘follow fast’.

Luke reminded me of a project we worked on together many years ago. Before we started designing webpages we did usability testing. We did usability testing of the competitors, and of sites that were getting a lot of press as ‘innovative’.  This was at a time that boo.com had just started and the client were talking about how cool an avatar would be on their site, just like boo. We put people in front of boo.com and watched them suffer. Clearly the avatar was an idea good on paper, terrible on execution.  So we killed it.  Not on our site.

We observed what worked and what didn’t on a multitude of sites with real users. Then, like magpies, we took what was good and worked. Nothing particularly innovative, (let other people do that), we took the best of what existed and delivered on that.

So back to our airline. How about a different approach where they start by usability testing their competitors. Ask participants to book tickets on competitor websites. Understand what interaction elements work, what don’t.

Those kayak sliders, cool for geeks (maybe), but how about the target audience that flies and buys online with you?  It may not be cutting edge design, but Does a drop down work better?

The coverflow may be cool on your iPhone, but how successful is it for people seeking a holiday?  A static list has worked for websites till now (and it wasn’t so long ago that horizontal scrolling was the Great Taboo), just because Apple do something that looks cool for a particular purpose on their products, doesn’t mean you have to follow by scrapping your navigation.

There are no prizies for (design) innovation (other than for some award that the design agency may covet). The only metric that counts is conversion rates and the ability of the website to deliver the business case. Leave others to do the crazy innovation stuff, let others go through the dip when they launch new features, make sure you have got the platform and expertise right and be ready to follow fast.

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.

Where are the missing floors?

Lift panel with numbers missing

It is fairly standard practice in Hong Kong for buildings to have no thirteenth or fourteenth floors. They are considered unlucky numbers. Not sure what happened to the first, second and fifth floor here. And back-to-front button numbering that is neither in the telephone format nor the phone format. There’s a couple of lessons to learn here; when designing human-technology interactions consider cultural norms and existing design stereotypes. (Sorry, its the Human Factors conditioning in me that notices such things).

Cross cultural considerations at the Sandwich bar

In their paper Content preparation for cross-cultural e-commerce: a review and a model, Liao et al. conclude that (1) Westerners pay more attention to information about product components or contents than East Asians and (2) East Asians pay more attention to information about price… than westerners. This is in the context of eCommerce in “present[ing] appropriate information content to facilitate consumers’ decision making”.

A practical example of this in the bricks and morter world can be seen at this Sandwich bar in Hong Kong.

Sandwich bar counter

Clearly modeled on the western way of buying sandwiches, the counter layout supports the customer selecting the product (sandwiches and fillings on display) moving on to the cashier at the end of the counter to pay.

This isn’t the way things are done in Hong Kong where money comes first before the product. “Please place your order at the cashier”… before dwelling in front of the display cabinet. This results is congestion around the cashier counter and poor workflow and a slow and tedious customer experience.

Sandwich bar or internet offering, consider cultural differences before transferring the concept and content.

Let common sense prevail

Me: “Hello, I’d like to book a flight back to London on Thursday please”.

BA: “Certainly. BA 28. Midnight Thirty Five.”

And that was it. No friendly warning, so close to doing this again.

If I ask for a flight on Thursday, common sense suggests that the fact that the plane is scheduled to depart 35 minutes into Thursday, and I need to be at the airport at 10pm on Wednesday, then it really isn’t a Thursday flight. Not being explicit and clear with this is rude business.

The scourge of Document Driven Design

Documents, or rather words are the scourge of product design. Because words can never convey the true meaning or emotion of what is really required. All to often, software development projects are driven by the documentation – agile projects can be equally guilty of this- driven by words on paper (or card) that convey what the requirement is. Issue #1. Developers don’t read!

Except for a few exceptions, software is all about a user interacting with a system in order to accomplish a goal. Trying to describe that premise in terms of features and functionality is fundamentally flawed as it will be nested in the language of technical implementation, not in the user interaction. “Find” becomes “search”, “buy” becomes “shopping cart”, “check” becomes “validation” and so on. Issue #2. The desired outcomes become lost in a smog of technical jargon.

Solution: Picture Driven Design. Up front. Yeah! I’m all for up front design! A picture tells a thousand words. It has the power to remove ambiguities, clarify the vision, showing what the journey to realise outcomes look like. Start with a day in the life of… scribble out the flow, the user journey. Nothing complicated, boxes and arrows. Then scribble out what the user interface might look like. Done. That’s your up front design. That’s your documentation. That’s your scope. What you do next is up to you, write loads of documents that describe it and produce the software in a waterfall way if you want. I’d prefer you were more lean and adopted agile practices, but whatever you do, start with the picture. I’m convinced it will save much pain later on.

CAPTCHA: a barrier to entry

When a customer starts completing an application or registration form it demonstrates they are committed. It therefore makes sense to pay attention to the usability of that form. But how often is the content of the form considered? Are there content barriers in the form that prevent customers from completing it?

Marcelo Calbucci (Via Luke Wroblewski) describes a barrier that everyone assumes just has to be there so it is not tested: The CAPTCHA. When the team removed the CAPTCHA from the Sampa.com registration form they recorded a 10% increase in conversion rates. Marcelo writes “we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time” (interestingly when I looked at the page I got the CAPTCHA). A 10% increase in conversion is not insignificant, and probably more than outweighs the additional effort to implement an alternative solution.

Does enterprise IT know what Google is?

Imagine an investment bank, a trader has a requirement for a tool to screen stocks. The requirement is to select stocks based upon different parameters, so for example find companies with a market capitalisation between a selected range, and a P/E ratio, Dividend Yield and Net Profit Margin between other selected ranges. And maybe the ability to add additional parameters.

Typically the process will be for these requirements to be captured by the Business Analyst who acts as the conduit to the development team. Nowhere is the user interface explicitly referenced – it will almost certainly be articulated in the reality of the current systems; what the BA knows and understands. Despite the iterface being delivered through a browser, the developers are not web developers. Inevitably the finished product will be functionally correct, it meets the requirements, but it will be clunky: select parameters > search > results… because it reflects the requirements as the trader put them “I want to do this and this and this, press a button and get a list back“.

So what are the chances of an internally developed investment bank application looking like Google finance’s Stock Screener? And what would your trader rather have?

Consistency when things are poor

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency – for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal – do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel – a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this – the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture – the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

1 of 2
12