Comments on The Information Architect as Change Agent

Keith Instone — Sat, 01 Mar 2008 23:53:17 GMT

I think a lot of us are coming to the same “change agent” place. I may have gotten there a slightly different way. I started looking into “innovation” (e.g., hanging out with local business school people). I like to say that CEOs will pay a lot more for “innovation” than for “change” but otherwise they have a lot in common. I am starting to see that people are assuming a new, high-quality total user experience is a requirement for “innovation”. Innovation often implies change AND a better UX: a nice combination (nice for user experience professionals, at least). Perhaps if you can get work on “innovation projects” then the agent-of-change aspect will be easier. When I have attended “innovation” conferences, this UX person and the “innovation” people got along nicely.

I also discovered a nascent community of practice around “change methods”. There is a bible of “change methods” called, oddly enough, The Change Handbook. Many of our strategic user-centered design methods belong in that book (and some are being added to the next edition, I am told). You can study “organization development” in business school if you really want to be a “professional change agent”. I went to the “Nexus for Change” conference earlier this year, spending 2 days immersed in change methods. Some of it was way too touchy-feely for my comfort zone, but that was exactly why I went. It was very educational (or enlightening?), and I think people learned from me when I explained what I do as a UX professional. (It was also quite eerie: it was almost like I was at the first IA Summit.) A UX person and the “change methods” people got along nicely.

As seems to often be the case in our work, we are finding that we need to be good at things that are normally outside our professional “comfort zone,” like being a change agent. It is important that we recognize that there is already a profession that specializes in it. We need to “hang out” with them, learn from them, and teach them some of our tricks of the trade. For example, most of the change agents I met do not have a lot of experience with technology or implementing change driven by technology. They can make us better UX professionals; we can make them better agents of change.

I have a very loosely connected set of blog entries on my site tagged “Innovation, change”. See http://instone.org/innovation-change

PS Yes, I used WAY too many quoted terms above. Apologies.

Terry Bleizeffer — Fri, 12 Oct 2007 09:37:10 GMT

And that’s probably a bell curve, because I think one of the big advantages of websites is the ability to make constant, small, non-disruptive changes. So you either want to have bunches of tiny new version upgrades (so any given change is easily adapted), or what long periods between major upgrades so people can take advantage of that second learning curve you mention… and in the middle is frequent, medium-sized upgrades that constantly force people to learn the new system without getting to a comfort level, which is the worst-case scenario.

Matthew C. Clarke — Fri, 12 Oct 2007 09:37:15 GMT

Another dynamic is the frequency of change that is imposed on users by version upgrades. I attended a research seminar once about the relationship between version frequency and usage competence. You can imagine a productivity v’s time graph. When a user meets a new product, there is the “steep learning curve” followed by a plateaux where a user has learnt the 10% of the product they need to get by and isn’t learning anything new. Whenever a new version is introduced, there is a short term drop in productivity, but that is (hopefully) followed by an net increase once the user gets used to the change. That’s all fairly standard.

But the added aspect that this researcher had noticed was that if you leave the user for long enough, without changing the system, there is often a second learning curve when they are confident enough to stretch themselves and actually start becoming masters. The biggest downside of introducing new versions too frequently is that this second learning phase is never reached. The user has just become comfortable with the functionality they need for the task when along comes a new version. The disruption prevents them ever gaining mastery. We see the results everywhere—a mass of users who barely scrape by and virtually no-one who confident or competent enough to make the most of the wonderful features we built in there for them.

Terry Bleizeffer — Fri, 12 Oct 2007 03:17:12 GMT

Matthew: That’s a good point about the inevitability of inflicting change on the user. In fact, we have customers who have invested so much effort in learning our product that they believe there’s no such thing as a design improvement… because any design improvement involves a design change and change is bad. I want to minimize change for our users—but that has to be balanced by the need to improve and innovate and attract NEW customers.

However, I do think there’s a tendency to require change on the part of the user in order to make development’s job easier. Maybe we can file this under “unnecessary change”. This is the type I was thinking about in my reply. I usually see this happen in two scenarios. The first is a half-hearted notion that we should build generic interfaces then expect all the users to customize it to their own taste. It sounds good on the surface, but what it really means is that the onus is put on the users to figure out how to use the product in their environment. The second is basically hubris, when wicked smart architects decide how users OUGHT to behave, and that’s how we’ll design the product, and if they don’t behave that way then by God those ornery users need to get smarter. I’m sure I’m the only one who has experienced that. =)

But I do see your point – change is inevitable (and isn’t always bad), so we need to plan for it. I just have a knee-jerk reaction when I see design that intentionally expects users to change their behavior in order to use it.

Matthew C. Clarke — Fri, 12 Oct 2007 01:23:10 GMT

Paul: I only just discovered UXMatters a couple of weeks ago. I wish I’d seen your article earlier. It’s got many good suggestions.

Matthew C. Clarke — Fri, 12 Oct 2007 01:17:19 GMT

Joe: yes there is a lot of value in the Soft Systems approach. And you’re right that the notion of seeking equilibrium does not always apply. In most cases where there is a different dynamic, I wonder whether the reason is that the system’s _natural_ tendency to equilibrium has been over-ruled by some imposed structure or goal? One example is a leader who deliberately sets new goals and effectively keeps the organisation unstable. And that links closely with Pauls comment on organisational culture and inertia.

Matthew C. Clarke — Fri, 12 Oct 2007 02:59:34 GMT

Terry says “But I think it’s worth emphasizing that producing a product that requires our customers to change is a Bad Thing, and whenever we hit that situation we should immediately step back and ask ourselves whether we can change course so WE change instead of the customers.”

I think I agree with the sentiment, but not the detail. It’s a great principle to make the computer model of a task match the existing users’ model as closely as possible. And asking ourselves whether we can do so is the right thing to do. The problem is that the answer is often “No”. There are (at least) two reasons why we can’t avoid the need for the customer changing their behaviour.

The first is perhaps pedantic, but the introduction of *any* new tool must change the way the task is achieved. Even a change to an existing tool means that people have to use the tool differently. So even a minor front-end IT change necessitates a change in user behaviour, even if its just clicking in one part of the screen rather than another. Even small changes in the tool mean that the user has to learn something new and leave some earlier behaviour behind.

The second reason is a practical one: the current state of technology often doesn’t allow it. Computers are in the early stage of their evolution and in many ways are very primitive. There are ways we’d like to implement applications that are not (yet) possible. Language parsing is an important example. We’d love to allow people to communicate in a way that is most natural to them—i.e. using their natural language. But we have to force other UI metpahors onto them and make them change the way they communicate because current technology cannot match their preferred behaviour.

Paul Sherman — Fri, 12 Oct 2007 01:20:44 GMT

Good artcle. I’ve been taking the same perspective myself, and I’ve also called for UX professionals to see themselves as change agents. (Reference: http://uxmatters.com/MT/archives/000162.php)

I think your points about organizational resistance are spot-on. My particular take on this is that organizational culture drives most, if not all, organizational inertia.

Joe Lamantia — Fri, 12 Oct 2007 01:20:48 GMT

Good highlight of such an important aspect of practicing this discipline – one that we (surprisingly often…) miss at our own peril!

Have you looked at SSM – Soft Systems Methodology? http://en.wikipedia.org/wiki/Soft_systems

A couple of quick notes on the second major idea, Systems Resist Change:

You say, “An organization is a complex system, and like all complex systems it seeks equilibrium.”

Systems often seek states other than equilibrium, something especially true of organizations in business environments, typically oriented toward growth of some kind, or efficiency. (Lately, the buzzword is innovation, but the pattern is that equilibrium is not their goal.)

Which leads to, “Organizational behavior tends towards a point where inputs, outputs, and internal processes are all stable.”

This sounds similar to the homeostatic view of organizational goals and behavior. It’s important to mention that many kinds of organizational goals work against homeostasis; think of the startup pursuing aggressive growth, innovation, acquisition, etc. Stability in this context is something to work against.

“Such systems react to change as a threat and act to restore equilibrium.”

As above, some organizations embrace changes in their states, or even actively seek changes: meaning change is not always a threat to these systems, and is often regarded as a benefit.

Basically, I’ve taken the long way around to say that context matters at the level of change management, which means that we should be aware of the organizational goals that drive our assumptions and approaches to change management in order to be savvy IAs.

Terry Bleizeffer — Fri, 12 Oct 2007 01:20:55 GMT

As the years go by, I become more and more convinced that “change agent” is the most important part of my job. All the really interesting things that I’ve done (or need to do!) have required some form of organizational change, including the ever elusive “culture change”.

You wrote (edited for length): “A software company I once worked for employed many outstanding people…. 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 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.” This is an easily missed point. I once took a project management course where the instructor started the course by saying, basically, that software projects never fail for technical reasons. Even if the project fails because the development team couldn’t implement the code in a timely fashion, that’s not a technical failure, it’s a project management failure.

The only quibble I have with the article is about being a change agent with the customer, ”...educating the end users and preparing the soil in which the new system will be planted.” I agree that this happens and I agree that it’s sometimes inevitable and I agree that when it’s inevitable that IA/UX needs to be deeply involved. But I think it’s worth emphasizing that producing a product that requires our customers to change is a Bad Thing, and whenever we hit that situation we should immediately step back and ask ourselves whether we can change course so WE change instead of the customers. So when we run into situations like this, ”... 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.” I think the appropriate response is to ask, “How can we minimize (or eliminate) the need for the farmers to change their behavior to take advantage of our product?” The more change we require from our end users, the less likely are our chances for success.

But again, I agree with you that this is sometimes inevitable and IAs/UXers need to consider that as part of our jobs.

Matthew C. Clarke — Wed, 10 Oct 2007 23:25:32 GMT

Thanks for the encouragement.

That’s a good point Debra about the IA’s special knowledge of users. We should be able to act as spokes-people, representing the interests of the user to the rest of the development team.

James Robertson — Wed, 10 Oct 2007 23:22:08 GMT

Great article, definitely a topic that warrants discussion within the IA community, particularly those working within organisations. At the end of the day, we need to take (some) responsibility for getting the right outcome, not just creating the right design.

debra levin gelman — Thu, 11 Oct 2007 11:18:14 GMT

I enjoyed this article very much! I would add another dimension here… as IAs, we are the ones who will have direct insight into existing user behavior, through the primary research phase that (ideally) precedes recommendations for system design. This positions us perfectly to play a key role within the change management process. By understanding our target users’ behaviors, prior to implementing change, we can ensure the design process takes these existing behaviors into consideration and does not completely disregard the ways our users currently accomplish their tasks. It seems as though we shouldn’t have to salt the proverbial oats, or manipulate our users into leveraging the system we’re building, rather, we should be able to demonstrate deep knowledge of their existing processes and develop a system that maps, as closely as possible, to their current mental models, while providing greater efficiency, rapidity, etc etc.

Patrick C. Walsh — Wed, 10 Oct 2007 12:41:56 GMT

Terrific article. I especially liked your emphasis on the IA as a facilitator for change and the human dimension which is central to the change management process.

Greg George — Tue, 23 Oct 2007 13:32:54 GMT

Nice and concise. The six questions for change is a nice idea. It forces communication between the changers and the changed and provides a common ground for dialogue about the change. I think you place the IA in an acceptable spot within the change management process.