users, vision + architects /3

28 September 2006, 00:23

After the summer break, let’s continue with the next instalment in this series, which deals with the section in the article by Don Norman, titled ‘why might hcd be harmful?’

‘…HCD has demonstrated clear benefits: improved usability, less errors during usage, and faster learning times. What, then, are the concerns?’
Don Norman

Following this quote, Don touches upon three interrelated concerns, each of which I will discuss below.

emphasising learning

The first concern is that one is actually customising the software for a limited number of users. I want to go deeper than that. My concern is that one is actually customising the software to improve the ease of learning for a limited number of users.

Ease of learning competes with ease of use and ease of remembering. One has to strike the right balance between them in each project, using 3E’s analysis.

The human‐centred methods usability folks depend upon are uniformly biased towards measuring and optimising ease of learning. This is inherent to the methods, and all usability professionals I have talked to agree with me on this.

The result is that with human‐centred methods one shortchanges the ease of use and ease of remembering requirements of the software.

discrete and limited

The second concern is that of not achieving seamlessly scaling software.

Scaling software offers a stable but discoverable environment which grows more sophisticated as the user masters the activity—and this by the way, can take years.

Human‐centred methods employ a limited, discrete number of users in limited, discrete number of exercises. This does nothing to uncover the seamless, incremental nature of software use. What should be a smooth ramp is analysed and modelled as a (preferably) three‐step stairs.

sprawling software

The last concern is that of loss of cohesion. No powerful, elegant interaction models can be harvested from users, but you do get lots of personal feature requests. Both of these work in the same direction: confused, sprawling software.

In no way does this lead to a compact concept for natural working environment, where the software allows straightforward actions that can accommodate any kind of activity.

instead…

All three concerns are interrelated, and there is also where the solution lies. It is the big picture.

It is perfect to use usability methods to map out how the user thinks and works. But then it is time to create value and this is an architectural process, asking for strong concepts. It is then perfect again to debug the concept, with usability testing, but it is the architect that keeps the model intact during these necessary changes.

Interaction architects are constantly aware that they are taking decisions for anywhere between thousands and tens of millions of users. They value the input from usability methods, but also know where this value ends.

next…

…stay tuned for the fourth article, dealing with information architects.

Labels: , , ,

PS logo

0 comments · post a comment

If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.

portrait of Peter  Peter Sikking is an experienced
interaction architect. He unabashedly puts shipping great products at the centre of his design practice. He is known for his work for Google, Nokia, the Metapolator & GIMP open source projects, and startups.

Peter teaches, mentors, lectures and publishes. He enjoys working with small teams in an international setting, but also the fact that his work can be found on half a billion mobiles and creates billion‐dollar revenues.

What is Peter up to? See his /now page.

get in touch: email · twitter · g+ · linkedin · xing