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 …http://www.bugaboo.com/ @ $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?

Advertisements




Design Authority – Part two

21 11 2007

Using the Design Authority concept in a large multi team agile environment.

Your Design is AUTHORISED!!!I was speaking with a colleague not long ago. He was asking me about using agile in a large team (50 plus developers, testers and designers), and the kinds of

The challenges as we saw them were;

  • That the software that the floor produced all serviced an internal client (i.e. the organisation).
  • That development efficiency was anecdotally noted as being not where it was desired.
  • That development consistency was also anecdotally not where it was desired.
  • That because of the changing priorities, consistency was a real issue, both in the visual, experience and technical areas, affecting the perceptions of quality, reliability and repeatability.

So I spoke with him about how he could firstly consider using agile methods to enable flexibility in his teams, so they could be configured against the outcomes required of them by the clients. We discussed the use of a configuration manager role, which would effectively marshal those team configurations so that the teams were created and disbanded in an efficient manner. We also discussed how he could still use a predominantly linear management technique to run the floor from an administrative perspective, thus supporting regimented accounting and reporting responsibilities.

Lastly we discussed how he could use a ‘Design Authority Cluster’ to cover off the following key areas:

  • Visual and interaction design
  • Business modeling design
  • Technical or architectural design

The versatility of the Design Authority role is such that the key concepts of having a dedicated role to maintain authority and provide that ‘single point of truth’, can easily be carried over consistently to pretty much any discipline. The only example where I can’t see it being applied, is in Project Management where a Centre of Excellence or PMO model is probably more appropriate.

Obviously the key points in actually considering these roles are:

  • Actual benefits of consistency of approach
  • Holistically as a whole does the development floor required to produce visually and technically consistent products?
  • How many people will be needed to fulfil the role of the Design Authority, and will they be full time or part time or just plain over-time!?
  • What is the cost of change to the behaviours and activities for development, planning, testing, release management and so forth to instill this new set of roles?
  • Is it a single point of truth that’s needed or an expertise Centre of Excellence. (hint; one is about guidance and accountability, the other is about capability development and provision, and you may indeed need both.)

In large organsiations, predictability is a big thing. This is because it serves the accountability requirements which is a big deal, particularly in organiations that have public obligations or responsibility to shareholders.

The Design Authority role, engineered and embedded well into an environment can go a long way to supporting those needs.





Loony tunes

16 11 2006

To tune or not to tune. That is the question.

Actually, that was the question! I was in a meeting the other day, with a collection of developers.

And amongst other things, which I’ll write about later, I got asked this:

“So in your opinion Ben, is there a significant value in tuning screens to show / hide capability from a user when designing an interface?”

Hiding my dumbstruck look, I answered “a very resounding yes my friend!”.

Now here’s what I thought was funny, and not really funny Ha Ha either.

To this particular guy, who I might add is an expert technology developer, the thought of having some functionality hidden from the user because they have no need to ever really use it, was just appalling!

Of course after a short thinking moment on my behalf, I remembered something which I had noted long ago about the expert technical worker profile.

WARNING!!! GENERALISATION PENDING!!!

When I did some initial research into the UI requirements of expert technology workers, I came across this sentiment:

“I’m a computer expert, therefore I want to have access to everything, so give me everything, and I’ll decide what I want to use.”

That led me down a line of further investigations.

I found that quite repeatedly, expert computer users have little problems cognitively filtering large navigation models.

They typically can remember hundreds of functions and associate them easily with their appropriate names.

This was quite contrasted from the Process Worker profile, where more menu options fed confusion about what they were supposed to do. To them, the concept of having more advanced and less commonly used functionality hidden away was perfectly fine. One person even likened it to keeping my less used pens in my desk drawer and only keeping my favorites out on my desk top. A sort of ‘workspace tidiness’ concept came across to me from that comment.

I’ll draw against the Microsoft Windows ‘Start’ menu. If you examine the menu containing the installed programs, there generally is more than 20 odd items in there. More if you have a typical development setup.

I’ll now ask you to compare that to the Apple navigational systems. Look at the way apples hide away the majority of the lesser used items, and bring to the forefront more commonly used ones. It allows you to customise it to remove even more, or draw out even more.

To me, apples are well suited to the average people. Normal people.

PC’s tend to lend themselves to more advanced users.

And if you look at the marketing campaigns for Apple, this simplicity of use is one of their primary selling points. In fact in one commercial I saw them handing the crown for processing capability and ‘number crunching’ to the PC world.

I guess the overall points here are these:
– Tuning interfaces has significant value, as long as you are tuning on researched or validated UI requirements and profiles.
– As designers you should be aware that some technical experts may not understand why you chose to use a tuned UI.
– Because of this, your role needs to include helping your developers understand that they don’t need to understand why you designed the UI a particular way, but that you came to the design to meet the users requirements. In many ways, they are doing the same thing by meeting the technology needs of the user. Your job is to make the technology usable to the users.

Know your users. Don’t think you know. Actually KNOW.