Is User Centred Design only for software?

19 05 2008

I had a conversation today, which was I interesting and enlightening.

We were talking about User Centred Design, and the person I was talking to, let’s call him “Bob”, was all fixated on how UCD was born from the IT age.

I of course argued to the contrary and being an Industrial Designer (actual buttons that you click with your fingres and so on)

You see, UCD in all it’s forms and even as simply as a reseraunt, asking the customer how they like their coffee and thus changing the menu.

It’s alive in the automotive industry like nothing else. Look at the features that appear in the new cars each year, how do you think they arrive at what is on that list? how do you think motorcycles (the finest and most incredible machines this world has ever known) have become such highly focussed and purposed solely for integrating the human with amazing speed and grace?

I digress. But to make my point, I’ll look at a new different product all together. A perambulator.

Specifically a terriffic one made by Britax (Steelcraft), called the “Strider”.

We just got one for our new kid. Me being me, I reviewed it quite carefully when we were purchasing it.

To me, took up the role of the technical, financial, and coach buyer. The boss took up the role of the User buyer, as well as a little bit of the financial buyer.

From my perspectives, having reverse engineered the design, and the product itself:

Technical buyer:

– it’s machined nicely, with all the fittings, … fitting well, and operating it is easy, and well thought out, for a human to work, (who has two hands, TWO not THREE Bertini)

– it was made from good quality extruded aluminium.

– it had solid motion through all its joints, and bushes moved silently without catching or rubbing.

– the tyres were airless, and thus would never run flat, and could have the tread replaced.

– the wheels pop off, and the bassinet pops off easily to reduce stack height when folded down.

– light weight, with minimal plastics and over complicated jointing systems.

Financial buyer:

– in terms of construction cost to produce the item, to the obvious quality standard, seemed reasonable. Easily besting the “could I build it myself for less?” question.

– in terms of quality in comparison to the other things on the market (ahem … @ $1500AUD for a pram!) and versus the more economical bretheren, certainly seemed to offer good value for money.

– Because of the inherant quality of the product, wear and tear or lifespan questions are well met.

Coach Buyer:

– Because the financial buyer and the techncial buyer (which is a common male role to play in such a decision) were happy, the Coach buyer was provided with many good things to help coach the User buyer into a position of purchase. Why? Because it came with this terriffic two part brochure, the one set of pages, had all the technical information and instructional information I in my roles (and as a male) would want. Plus!!! it had all the information I would need to be able to support my actual decision maker in her decision.

Of note, it wasn’t a con, or underhanded in my view. Because Britax gave me all the information I wanted to know, and made the product in such a way that it addressed my concerns, my job in my role was made easier.

From the Boss’s side, she got great usability, reassurance from her technical and financial buyer that the thing was good, and to boot, because the financials were reasonable.. heaps of extras for bub.

Which suited me also.

So where’s the UCD in all this?

I’ll ask you this.

We bought the pram. We’re happy about it, we like it, like to use it, and had no post purchase buyers remorse.

How do you think the company could have achieved that, if they DIDN’T ask users what they wanted and then acted upon that information?


Enterprise Human Factors…001

13 11 2007

There’s a lot of talk I come across from some very very clever people in the UX, UCD, BA, WebTech spaces that revolves around doing user centred work.

Including user centred work and themes during the software delivery lifecycle (SDLC) is a great thing. I’ve been involved in many key works doing exactly that, right from being the designer, to being the antagonist pushing to get the concepts in place. It’s all good stuff really, getting user research down as being a standard part of the process for developing software, getting rapid prototyping in all its forms in to the way of life, was and still is a great way to spend the day.

But am I really fixing anything? is the source of the problem resolved?

In some ways, while designing the software to help the users is fixing one problem, being that the solution provided at the end of the day is usable, easy to work with, likable even…. is the task that it has to perform sharing those traits?

Lets look at the eTax system from the ATO. The software itself is designed relatively well, not how I would do it, but well enough. Admittedly they have a hard ask posed to them, no one likes doing their tax, they just want to get the cheque at the end of the day. Well I do anyway.

The ATO software is designed relatively well, it’s easy to use (ish) and relatively well positioned in terms of providing good support to novices. Plus I know from personal experience, the ATO invests heavily into it’s user centred design concepts and work, and they have truely top class people on board doing the work.

But, are they addressing this one:

“Are human factors considerations implicated across all facets of our business?”

When policy is created, is the real world impact of the decisions being made at that crucial point in time being considered? What will happen to the Australian public if we generate just one more form for them to fill in? Are we generating a cost for the public through the generation of that form? What is the cost to the public of filling in that form, and is that something that the ATO needs to consider?

Small companies / organisations have less of this issue, but let’s look at this one.

Say there is a reporting requirement for all Australian Residents to fill in a simple 20 data element form, which confirms their postal address. This form conceivably could take no more than 3 minutes to fill in, lick the envelope and put in in your bag to go to the post office tomorrow.

Now for the unseen overhead:

– two minutes to read the envelope, swear about having to fill in another form, find pen and load the requirements of the form into the brain.

– three minutes to fill it in, pack it for posting and whack it in your bag.

– 10 minutes to locate a post office box, post it, and recover from your detour on your way to work or way home.

So the total spend is 15 minutes to do all of that.

Spread that across all mature adults in Australia (i.e. over 18) 15,917,876 X 15 minutes = 3,979,519 Hours spent across Australia.

Now imagine if that were to be paid back at the minimum average hourly rate of Australia, being $12.42/hour.


OK, so that little calculation is rough as guts, but the point being that with large organisations / enterprises, small changes can have large ripples across their user groups. In the ATO’s case, all of Australia.

I’ll say at this point, ATO are keenly aware of this fact, and go to great lengths to limit this kind of effect occurring.

Large enterprises can take that concept of careful consideration of the user base to form not only support or rationale for doing or not doing something, but even for discovering what activities they should be undertaking to meet the needs of the communities they serve (or wish to serve).

The concepts behind benefits profiling being the keystone for delivering an organisations plan can and perhaps even should be created in part through considerations of the humans who will be affected by the desired benefits.

In software development, humans are intertwined into the design and indeed the final output. These concepts can be applied to an entire organisation, how it operates, what benefit it delivers, how it measures success, and how it supports itself into the future.

Perhaps if organisations adopted some of the human centric concepts that occur at the implementation layer of an enterprise, they may be able to significantly improve their success and ease of operation.

Remember consideration is not about constraining change, it’s about optimising and embracing that change.

Thanks to the Australian Bureau of Statistics for the numbers.