London IA Mini Conference review - Part 1

On Monday night The Guardian hosted the first London IA Mini Conference, and yesterday I published an extended version of my presentation on the night: "Introducing Information Architecture at The Guardian"

Here is the first part of my notes from the rest of the evening after I'd spoken.

"Agile UX" - Cennydd Bowles

Cennydd was ambitiously trying to pull off what looked like a 45 minute presentation in 10 minutes, and managed it impressively. He was looking at the cultural clash when agile development and user experience practitioners meet.

His concern was that very often we end up with 'user scented design', not 'user centred design'. The agile process does not allow sufficient time for specific user research and design iterations, and leads to products which have a hint of being user-driven about them, but instead have been methodology driven.

Cennydd was very much of the belief that products needed an 'Iteration 0' that allowed the developers to sort out all their fundamental back-end and environment decisions, whilst the UX team were researching and designing like mad. He also thought it made sense to get the really basic stuff out of the way first, to give developers something to get going with, whilst you concentrated on the harder areas of a product. He supported the notion that you should be researching for two iterations ahead, designing the next iteration, monitoring the current development and testing the output of the previous iteration.

The final point I thought well worth noting was that Cennydd felt that agile was a philosophy that all too often had been turned into a dogma. He suggested, to short sharp gasps of horror in the room, that if we expected developers to bend their dogma to accommodate us, perhaps we would also have to relax our design dogmas a little. He can't have meant it ;-)

"Why users don't follow instructions" - Phillip Winwood

Phillip Winwood suffered the fate of being the presenter during a period in which the Scott Room's extraordinarily sophisticated and expensive A/V system mostly displayed 'Signal not available'. Phillip had to busk his presentation without slides, which he coped with admirably. At times it was like being at a 'visually described' event: "And now there is a picture of an iceberg..."

Phillip's background is in psychology, and he talked about some of the reasons why users simply do not follow instructions. He suggested the brain was a sophisticated pattern matching instrument, and that we learnt to use things based on familiar and comfortable patterns. Anything that deviated from that pattern becomes harder to learn, and the ability to learn 'new stuff' decreases with age.

He explained the theory that user's will learn something up to the point where they are 'sufficiently proficient', and then learn nothing more. This was a problem in both software and hardware design. He used the example of the mobile phone, where, perhaps with the exception of iPhone users, most of us old'uns use the same features on our phone as the ones we used when we first got a mobile in 199x. They can do a zillion things more, but we lose the need to explore functionality once we have an established usage pattern. He (eventually) illustrated it with a much better version than my crude rendering of his diagram:

He also produced the 800 page manual that used to ship with Word For Windows 2, to illustrate that the strategy for most users when faced with a manual that sized was to simply dive in and start using the program, whilst ignoring the instructions.

Another point that struck a chord with me, was the contention that people start off being inefficient with new software. Then they reach a comfort zone where they are productive. However, when they over-reach this zone and learn more, they go through a period of 'intermediate expertise' where actually, although they can use more functionality, their productivity drops.

I very much empathised with this theory. I can't count the number of times I've had some data or number crunching to do, and have thought - "I can do that faster with some kind of regex and a script". Then have spent longer trying to construct and test the regular expression and automate the process than I would have done by simply chucking the data into Excel and counting it by hand. I'm reassured there is an academic theory to back up my ineptitude.

"Spec docs from Axure wires" - Ken Beatson

Axure were one of the evening's sponsors, and Ken Beatson gave a demo of how he used the software. He doesn't use it to make 'pretty' wireframes or full-blooded prototypes, because the product is in a constant state of flux, and it is the job of the designer to get things pixel perfect.

Instead he concentrates on using the extra metadata that Axure embeds in a wireframe to note the changes that have occurred between wireframe versions. He illustrated how his wireframe work dovetails with the agile development being carried out at a remote site. He produces a full set of wires for each iteration. Additionally his diagram featured some 'lightning bolts', or '<quote>good ideas from management<unquote>'

Ken's presentation sparked some lively debate from the floor about the obsession that IAs have with documenting every thing down to the very last detail. One school of thought was that, especially in an agile development environment, the ideal was to do the bare minimum needed to explain concepts to the developers. Another view was that comprehensive documents were needed to ensure that sign-off meant sign-off, with a mutually agreed reference point. Andy Budd was unequivocal about it. He thought that if your user experience documentation was being used in this quasi-legal way then you should 'get better clients' - or at least start treating the sign-off issue as a 'people problem' rather than a 'solve this with sophisticated documentation software problem'.

Next...

Later this week I'll have some more notes from the evening, featuring Leisa Reichelt's wireframes workshop, Matthew Solle's forms flip-chart, and Tom Coombs' infrared webcam.