Thursday, October 11, 2007

The Information Architect as Change Agent

Changing organizational thinking through IA ...

"Some years ago I designed an expert system to advise cotton farmers about the appropriate choice of pesticides. We spent a lot of effort dealing with some major technical challenges to turn research techniques into a commercial product. Unfortunately, we didn’t spend as much effort dealing with how it would be deployed to the real target audience: farm managers with little experience of computers. It’s not (just) that we didn’t think enough about the software’s user interface, but we didn’t consider how the farmers would need to change their behavior to make effective use of the expertise that the software made available to them. As far as I can tell, this project became one of the 19% of IT projects that were never used.

... The kind of work IAs do leads to changes in the way people behave. We are in the business of providing tools and structures designed to allow people to do something in a different way (hopefully a better way!) than how they did it before. As Goodman wrote in the article cited above, “As IAs, we are not just architecting information; we are using information to architect change.”

Yet for all our concern about accessibility, usability and the user experience, we seem to think very little about the nature of change. How many projects have you worked on where the implementation team gave any consideration to the way people would be affected by the changes the new system would impose on them? If your experience is anything like mine, then the answer would be “bugger all”, to use a raw but expressive Australianism.

A software company I once worked for employed many outstanding people: a team of excellent programmers with a genius leader, hard-working and intelligent people in QA, dedicated and professional consultants, productive and dependable technical writers. Nevertheless, good IA was always crippled by non-technical, organizational factors: inadequate communications processes, inadequate specifications leading to frequent re-work, the wrong person doing the job (for instance at one point the Vice President of Marketing was personally doing the software’s graphic design) and scope creep caused by revenue imperatives, etc.

This business context, in which organizational factors contribute more to the success or failure of projects than technical factors, is far from unique. In such a context it is insufficient for the IA to contribute just their technical input to the system design: the effective IA must also play a role as an agent of change. Sometimes this role is within the product development team: educating and channeling the team to “take on board” good IA practices. At other times this role is oriented towards the customer: educating the end users and preparing the soil in which the new system will be planted."    (Continued via Boxes and Arrows)    [Usability Resources]

0 Comments:

Post a Comment

<< Home

<< Home
.