publications

users, vision + architects /4

November 29, 2006, 23:32

Today we cover the section in the article by Don Norman, titled ‘static screens versus dynamic sequences.’

‘The methods of HCD seem centered around static understanding of each set of controls, each screen on an electronic display. But as a result, the sequential operations of activities are often ill‐supported.’

Don Norman

This matches my experience. My usability colleagues seem to perceive the initial screen/page/window segmentation as set in stone. That is,

• how a system is segmented into particular screens;
• how a website is segmented into particular pages;
• how an application is segmented into particular windows.

In my experience this segmentation is in 99.9% of projects either very technical; very functionality oriented; or simply bollocks—but always inhuman.

meanwhile, upstream…

Instead of starting with incremental improvement of layout and display within the given screens/pages/windows, I find it much more rewarding to focus on flow.

That is, user flow. Focussing on elegant flow for essential user activity is a very powerful tool for arriving at a natural screen/page/window segmentation.

As a side effect, a lot of the initial layout and display problems have by then simply disappeared, and the right approach for the remaining ones has become obvious.

don’t call me a…

Every now and then I am mistaken for an information architect. Or worse, information architects imply we’re all one big family.

Interaction architects add the dimension of flow, to the two‑dimensional world of information, and that makes all the difference.

next…

…stay tuned for the fifth article, on dealing with user requests.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /3

September 28, 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: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /2

July 29, 2006, 00:33

Let’s move on with the next two sections in the article by Don Norman, starting at ‘human‐centred versus activity‐centred…’

‘Successful devices are those that fit gracefully into the requirements of the underlying activity, supporting them in a manner understandable by people.’

Don Norman

‘Does this UI optimally support the activity’ is one of my key criteria when I perform an expert evaluation, or when selecting from different interaction design variants for my clients.

Supporting the activity is the difference between UI that ostensibly makes the functionality available to the user and UI that makes the activity a piece of cake, and the software a true joy to use.

‘only software that supports the activity adds user value, and is worth using’

ps

Hitting the sweet spot where the UI optimally supports the activity is a great development team motivator. On every project I work on, the eyes of all involved start glowing when we have that Zen experience: we got it. You can see the developers calculating how with a little bit of effort they can put together this really cool piece of software.

‘only software that supports the activity adds company value, and is worth developing’

ps

users will adapt

Actually, users suffer in silence, when using software. This leads to the ‘we did not get any complaints’ phenom­enon. There is a backlash from this when it is time to innovate.

Remembering the last time they had to learn how to ‘work around’ the current UI, which does not support their activities, users fight change hand and tooth. Many parts of the software industry are stuck in the dark ages because of this.

The only way to break this loop is to hit the sweet spot. Show people UI that optimally supports their activity and they’ll want it, right now. They will have their Zen moment: this is the best thing since sliced bread.

highly efficient machines

It is the interaction architect who takes the responsibility to lead the development team to the sweet spot. To focus on the activity, take a collection of features, functions and technology and to shape them into a nifty, highly efficient machine that supports the activity.

next…

…stay tuned for the third article, dealing with user testing and ease of use.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /1

July 18, 2006, 17:52

So let’s get started with the article by Don Norman at the top‐left corner, and work our way through the introduction, up to the musical instruments.

the paradox

Norman starts off by observing a paradox:

• there is quite a bit of software in this world that, while produced according to human‐centred principles, is complex and confusing;
• there are lots of tools and objects (not software), that have been made without any human‐centred design methods, but that are used successfully across the globe.

Norman goes on to explain that the latter may be the result from a deep understanding of the activity performed. He then defines activity as the big picture of what people do.

In the final part of this introduction, Don shows—with examples—that it is quite normal for people to adapt to rather artificial systems, simply in order to get things done.

living with the paradox

The 99.9% of functional analysts, GUI developers and multi‐media/web designers out there, who work on projects that involve no human‐centred design at all, may feel vindicated by all this. And by the way, all those projects that ‘ask users how they prefer their GUI’ are part of the 99.9% (an upcoming instalment will cover why).

We all have read the reports about how some of the top‑5 software companies in the world (in revenue) have impressive usability departments, and are adviced by the biggest names in my industry. But I have to say: where did all the effort go? Look at the market‐place indicators:

• a cottage industry of training companies for this software (official slogan of one: ‘we are the aspirin for the headache of having to use xyz’);
• project implementers for this software relaying to me their customer’s response: ‘oh please, not xyz’;
• the wide‐spread reputation among users of this software.

stop smiling

It is my experience that those 99.9% of software/multi‐media/web projects are not achieving the second part of the paradox. Because the ‘deep understanding of the activity’ is missing.

As long as the project team keeps working at the level of features and functionality, it will not understand the activity. It is staying within the relative safety of supplying an addictive commodity (new features) and practising UI as a technical discipline.

Only when when the team can leave this level behind, and use methods to acquire this deep understanding, to get the big picture, then I say: ‘welcome to interaction architecture.’

next…

…stay tuned for the second article, dealing with highly efficient machines.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /intro

July 14, 2006, 19:29

Two weeks ago a link was posted on the iXda mailing list to an article by Don Norman on what he calls activity‐centred design. I finally got around to reading it, and check out what that entails.

What Norman describes in the article greatly matches what I have experienced and learned myself in the past 13 years in this industry. This has resulted in the methods that I have developed and put into practice at m+mi works.

the series

By the time I finished reading the article the idea had been born to publish a series of blog articles, where I comment, expand upon and put into perspective the different themes in Don’s article.

So stay tuned for the first article, dealing with the paradox.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting: