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?


Bad designs, were they really all that bad?

19 04 2008

Barcamp presentationWell today is the first Barcamp in Canberra and it’s shaping up to be a blast.

To follow what’s happening at the event, you can follow on twitter by adding @barcampcanberra.

At this event along side a gamut of much more fantastic presenters than I, have played my part and put together a little something for us all to have a look at.

I did a presentation on bad designs, and explored a bit in a short 15 minute window, a few points that take a bit of the ‘dis’ out of reviewing a bad design.

The slide pack (bad-design-at-barcamp) and at slideshare goes through a few gems from the 90’s, and some points as to why they mightn’t be so nasty… from a certain point of view.


I laid out a challenge to all who attended, and you to, to nominate a horrible site, and either thump down a case for why it sucks or why it’s great, but still sucks.

The rules are pretty simple:

1. no questionable material if you please.

2. you can’t just nominate a site, you have to state why it’s good or why it sucks.

3. sites must be truely horrible.

So to participate, just comment away.

I’ll be participating as well, and I’ll be trying to stand behind any of the horrid, torrid, utterly nasty sites you find.

Game on everyone.

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.

Design Authority – Part one

21 10 2007

At my presentation this year at Web Directions South I spoke briefly about the role of the Design Authority.

I’ll start this off by saying that there is in my mind, not one role that is defined by Design Authority.

There are in fact three.

The differentiating factor being the context and therefore your viewpoint.

Programme Design Authority:

This Design Authority is single point of truth for the design of a Programmes outcome configuration. Programmes deliver benefits to an organisation or entity. The projects that are children to the Programme, are responsible for delivering the capability that will deliver the benefits that are sought after by the Programme.

In the program me context, the Design Authority marshals what capabilities are required to deliver the benefits, and subsequently the outcomes from the sub-projects.

Over time, through feedback from the sub projects the Design Authority will monitor the development and the alignment of those projects with the parent capability requirements (or Capability Profile)

Enterprise Design Authority:

Similar to a Programme Design Authority, however the Enterprise Design Authority, holds a persistent or lasting role. Programmes have endings, much like projects (duh because of their implicit relationship). The Enterprise Design Authority preserves the Enterprise business intent, and provides design assurance for the programmes of work within the enterprise.

Visual Design Authority:

This is the role that is more common around the traps and would be familiar to anyone working in a development house.

The Visual Design Authority is the role that is responsible for the design strategy, as it relates to all things visual or interactive. This includes aspects like how the visual appearance evolves of a website, or what methodologies are in place for the design of interactivity or business processes, whether or not information architecture principles are applied and how and when and by whom.

Everyone needs to set up their Design Authority in the way that best suits the purpose. The term design means different things to different people, hence since I come from more than one place (being both the interface design, enterprise design space) I can see both points of view.

Why I like the concepts around the Design Authority is that it disambiguates where the assurance responsibility lies. In many contexts this role can be very useful, especially in terms of assuring alignment of effort outputs with the original vision, and in terms of providing consistency and stability in terms of visual design output and approach.

Even for small business this can be useful, because where resources are limited and time is short, wasted effort that isn’t true to the original goal can be expensive and sometimes crippling.

Within the private web development field I would even actually say that the concepts behind a Design Authority, could hold a lot of value (from a visual design authority view) in terms of a Quality Assurance Regime. Where the outputs of a development team can be independantly reviewed against the original or captured client intent, which ALWAYS looks good.

I’ll endeavor to post again about the role of the configuration manager, who enables the requirements of the Design Authority through managing the configuration of the programmes efforts.

This Design Authority role is ever expanding particularly as there is more and more rapid work or agile work being done in the software / web development space. In light of that, if you would like to pitch a question about what a Design Authority role could do for you, or if you want to comment on how you use a Design Authority already, I’d love to hear from you.

Capability profiling – quickly – cheaply – for small sites.

3 10 2007

Good evening everyone!

Diving straight in, Capability profiles.

These are a fantastic little doodad which are very very useful for figuring out what a project has to deliver.

Often I’ve found myself starting off a project, and jumping straight into outcomes as derived from a vision statement.Something like this:

Vision: “We want a better online presence to improve the front end of our business.”

Outcomes: “well, lets build you information pages, and build in a blog, with an events calendar….” and so on.

But there is a critical step in there that often gets missed.

And it’s fiendishly easy to do, and very very valuable.

A capability profile is a set of statements, which can describe in plain English, almost conversational terms, what capability is needed once the project is done.


Well, my learned friends a capability profile would look something like this for a fictitious company.

Capability profile

For: That Company over

1. Ability to be able to offer time limited sale opportunities to our clients.

2. Ability to be able to offer special online services to a member group.

3. Ability to manage that membership group, and send out email offers and other sales or marketing materials.

4. Ability to maintain the content and page structure ourselves.

5. Ability to have a photo gallery of our products.

6. to have purchase oriented transactions be performed through the site.

And so on….What this gives you as the developer / designer / whatever, is a really useful communications tool to use with your client to help them define exactly what the site is going to do.


But absolves both / all parties of needing to look carefully into what is going to be built exactly.

In Agile managed projects (and waterfall ones for that matter), the capability profile can be used as a single point of truth, owned by the Design Authority role (see my slide share on Natural Project Management With Notes or Without Notes)

Now, clarity around what the end state capability should be is really useful in a financial sense as well, becuase particularly with Agile developments, having clarity of vision can really save the development team a lot of money and time.

I should note as an ending statement, the capability profile is NOT a static document, and should be reviewed by both the project team and the owners at every iteration.

Particularly in an agile development, because as we all know, because agile is so powerful new desires for more capability come up ALL the time.

To support anyone who is interested, I have a neat little set of .PPT / .KEY worksheets and a workshop agenda process which are great to use to help work through the development of your capability and outcomes profile.

If you’d like to get your hands on it, drop me a line!

Childrens toys leading UI design?

28 01 2007

I often look at the toys my two boys get for inspiration and insight into UI design.Now this may seem like a stupid thing to do, kids toys are for kids and I handle design for complex business systems.So what’s the gig?Well I actually intend writing several articles about this and what I’m finding.The product I assembled or disassembled more correctly was an “imaginext” castle from Fisher Price toys.Now, when I pulled the thing out of its box, I in typical fashion ignored the instructions relying of course on my amazing talents and sharp mind to be able to effectively assemble a childs play thing.Typically also, this gamble never pays off and I’m left sitting on the floor hunched over some instructions I can barely make out because I’ve half assembled something in the wrong order and am likely looking at something that more accurately resembles a ball of twine over the Batman’s lair i originally purchased.Anyway, as I was undoing the last of the 14 million wire ties holding the toy castle in its cardboard cocoon I noticed that at the top of the toy there was a little toy king held in place with a white surround around his feet.The other knights were contained in a little plastic bubble “see but not touch” wrapping of the open type display box it was all contained in.The king stood at the top of the castle above the drawbridge (see pic).imaginext castleNow here’s the UI bit. The surround holding the king in was coloured white. There were no other parts on the castle that were white….other than the white plastic reinforcements that were fastening the aforementioned wires which restrained the toy in it’s packaging. I’d been happily removing all the white plastic bits from the toy and it wasn’t until it came to remove this last piece from the toy, that I realised this.Fisher-Price in all their wisdom had decided to colour code all the removable parts white!And I, even with a well trained eye completely automatically keyed into the “obvious” visual clues that led me to instinctively know that all white bits should be removed.(Reading the instructions later revealled that they had indeed done this on purpose, and that I had done the right thing.)So there you have it. As kids we are taught games which teach us how to spot differences, and make choices based on those differences. “Odd one out” games if you will.By purely instinctivly playing the “odd one out” game with this toy through the practice of removing the packaging, I was going to achieve my goal!Can this same thinking be applied to more complex interface design? Probably. I’ve not invested much in the way of figuring out and active application for the “odd one out” game in terms of application or web interface design. BUT!!! Surely there are many other games we played as children which we can tap into in terms of our designs to enable our users to intuitively interact with our software?Kids toys… well I never.Next article will be about another toy I quite like, which is the Leapster game from a company called Leapfrog. It’s excellent, and my 3 year old son can use the device like a pro. In his world, instructions are meaningless. Poor little tike is still working on numbers and how to eat custard while resisting the temptation to stick it in his brothers hair for a larf.Users first. Particularly if they are kids.

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.


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.