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.
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.
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.
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.
…stay tuned for the fourth article, dealing with information architects.
22 September 2006, 12:26
I have just finished the selection procedure for the openUsability sponsored student project: GIMP. This is a project where I work with an associate interaction architect on revamping the GIMP. This project is also the pilot for the season of usability initiative.
From the jump in the server statistics for mmiworks.net I can see that the news of the student project spread around the net infectiously on August 11th. This caused a first wavelet of applications. We closed the application period a month later, the announcement of which triggered a second wavelet.
- fourteen people applied for the position;
- quite an international showing, with applications coming from Europe, USA, Russia and India;
- a significantly high number of applicants (5) were born in the countries formerly of the Warsaw pact, although only one was still living and studying in that part of the world;
- I selected three applicants for phone interviews, and all turned out to be from the Warsaw pact faction, maybe it is just something in the water…
So how does one identify an up‐and‐coming interaction architect? In the requirements section of the advertisement you can already see what I was looking for, but I will elaborate on those words here.
‘Interaction architects need to see from the user point of view, know what makes user interfaces tick, have a mathematical eye for the beauty of the simplest solution, a sense for clean layouts and know what can be developed in practice’ps, in the original advertisement
There are five disciplines in the quote above and I was really looking for evidence of all of them in the CVs I reviewed. And I was looking for balance. A straightforward university education in usability, graphic/product/interaction design, software engineering, mathematics or psychology can give you a background in at most 1½ of these disciplines.
This skews a CV and needs compensation by evidence that the applicant went out before or in parallel to the current studies to obtain a background in the other disciplines. No need for a handful of university diplomas, just any kind of experience that can give me a vibe of the particular discipline will do.
Another vibe I look for in a CV is an absolute determination to make it in interaction architecture. This is still absolutely necessary in the software and web industry of today.
When graduates do not stick to their guns, the industry they enter will fob them off on jobs like UI or web developer, web graphic designer, functional analyst, requirements specifier, product marketing person or the token usability tester. All of these jobs leave zero opportunity to take charge and introduce solid concepts for interaction.
So absolute determination is needed for aspiring interaction architects in order break the vicious circle of no awareness in the industry of how strategic interaction is to their bottom line, and few jobs for interaction architects.
to be, or not to be…
A final point I want to touch upon here is the topic of owning ‘it.’ I reviewed several CVs of applicants who are totally fascinated by interaction, and are really determined to make it their profession. But they are still looking at it from the outside, looking forward to enter the field.
To get the job of associate interaction architect one’s to be one, no matter how little experience one’s got. It is a state of mind.
After the phone interviews it was clear to me that Kamila Giedrojć is the applicant who meets the requirements above most successfully. I look forward to kicking off the project with her.
14 September 2006, 15:50
For a practical example to illustrate the tutorial with, I selected the tv‑browser. I had already developed the product vision and the user scenarios together with the project team. An hour and a half session flies by once you get a discussion going, so I had to allocate most of the available time to the essentials:
- show how I developed the product vision with the project team;
- explore with the audience new interaction designs, based on the product vision.
so, how did it go?
A big surprise was that the hands‑on practical sessions were hosted in a steep lecture theatre. So I could forget about my idea of letting the people sketch interaction for 15 minutes while I walked around and coached them. Also because of the steepness of the theatre, I could only see the first two rows of people, the rest where already too high up to see their reaction and to communicate.
I asked all the audience to sit in the first three and a half rows, to be able to discuss without the need for a microphone. I really enjoyed the discussion, and I could see that there was a resonance with the dyed‐in‐the‐wool usability practitioners who have been struggling with projects where defined goals where a luxury. The technique of kicking off a project by writing down a product vision was an eye‐opener for them.
One thing I learned to stress more when exchanging thoughts with usability people, is that sandwiched between the user centred phase of surveying and observing users to get a feel for the domain, and the user centred phase of usability testing to validate and incrementally improve the software prototype, there is the not user centred phase of creating the concept for the interaction.
In the concept phase the value and the inner strengths of the software project team have to be expressed. It is the interaction architect who guides the development and graphics team to achieve this.
I noticed in my—and also in other—sessions, that for many usability professionals the concept phase is a black hole in the middle of their user centred process where they lose their footing, and try to regain a sense of security by employing user involved brainstorming and sketching techniques. This passes the creativity buck to the user group. Alas, where it comes to interaction, users are a most reactionary force.
The day after my session I had time to attend some lectures, and of course I had to see usability of presentation software by Meinald Thielsch, having done the openOffice Impress redesign project last year—see our lecture. The gist of the session and the big surprise: there is almost no published usability research available on powerpoint & co. I was surprised to learn that by performing the expert evaluation and redesign of Impress, I obtained some pretty rare expertise.
So it turned out that with Meinald, Matthias Müller-Prove from Sun (starOffice/openOffice) and me in the room, we had a remarkable high concentration of worldwide presentation software experts. Meinald is in Berlin regularly, so we’ll have the chance to meet up and swap stories.
That’s it for now, stay tuned for more episodes in the users, vision + architects series.
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
What is Peter up to? See his /now page.