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.




4 responses

4 01 2007

Over generalised on the Macs, “Mr Windows Boy” :). But all very true especial in organisations where people become isolated.

Ben two words – usability testing.

With users, get humble go do it… developers designers no nothing. The user knows all.

5 01 2007

Oh, I’m all over the Mac’s at the moment. Really loving them. Got my life back. 🙂

I’m all about usability testing. Thing is, Usability Testing only covers the work that’s done. There are big things to gain from knowing your users and understanding them and their needs before you build.

If this is done successfully, then the usability testing should yield very little in the way of defects.

Theoretically speaking of course. It doesn’t accomodate for a long development time, where no change management or target monitoring has occured, and the product released is effectively outdated before it even comes to be. Which poses all sorts of other things to contend with in terms of design.

6 01 2007

That’s where you need a rapid dev cycle like Kelly Goto talked about. You need to get user (not stakeholder) feedback asap.

I’m a very strong believer in a good IA and then into a few cheap rounds of UI testing via a few paper models, then start the coding of the UI and only code the back end glue when the user testing is done. Especially for large projects.

In theory a good IA doco will/should present the user details etc. This is what a good IA is being paid for.

11 01 2007

To take it one step further Tuna, what I’m doing here in the Government with my Design team and our users is actually getting the users involved in the front design process from the get go.

Working with lo-fidelity rapid production drawings and process / functional flows, and getting input from them at this much earlier stage.

From there the black box design work stems, and is then iterated through the users again for validation and refinement.

Of course UAT is the formal process that rounds off the whole thing and guarantees it for production.

I wrote something about it in another area under the The lows and highs of fidelity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: