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.1
Several past articles on Boxes and Arrows have mentioned the idea that an IA is often an agent of change. It’s worth reading those previous articles in full, but here’s a summary:
* In “Succeeding at IA in the enterprise”:http://www.boxesandarrows.com/view/succeeding_at_i, James Robertson writes that, ideally, information architects would be part of a team in which someone else is responsible for change management, but that in practice the IA often does not have the support of such a team and needs some proficiency in organizational change.
* In “Enterprise Information Architecture: A Semantic and Organizational Foundation”:http://www.boxesandarrows.com/view/enterprise, Tom Reamy accepts that IA’s are often agents of change, but points out that so are many other people, and that role ought not be seen as essential to the definition of IA.
* In “Change Architecture: Bringing IA to the Business Domain”:http://www.boxesandarrows.com/view/change_architecture_bringing_ia_to_the_business_domain, Bob Goodman introduces the term “change architecture” and neatly summarizes Kurt Lewin’s three-phase approach of Unfreeze, Transition, and Refreeze.
In this article I argue, with a bit of logic and a bit of experience, that IAs can do their jobs better if they understand organizational change management, even if they don’t need to be change management specialists. I’ll also suggest a variety of concepts and practices that can (hopefully) help IAs in their change agent role, and I promise to throw in something entertaining as well.
Speaking logically…
Premise: Information architects frequently introduce new technology into organizations.
Premise: Technological change inevitably causes behavioral change.
Premise: Organizations are systems that seek equilibrium and resist change.
Conclusion: A necessary condition for the successful implementation of new technology is the successful navigation of organizational change, and the information architect is often required to act as an agent of change within this context.
There’s Often No Choice
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.
Primer on Change Management
There is a large body of theory and expertise in change management and I don’t mean to suggest that IAs need to master that whole discipline. What’s important is to be sufficiently aware of the dynamics of change that you can work alongside other players to support organizational acceptance of new IT systems. On that basis, here’s a list of some core change management ideas as they relate to the role of an IA.
1. All change is stressful
Every change brings with it some balance of costs and benefits, but even when a change is entirely positive, at least two factors cause stress. Firstly, introducing a new IT system will require the users to learn something: perhaps a new user interface component, a new range of configuration options or a new workflow. It might mean a change in responsibilities that affects the way they relate to co-workers. Because of these effects, a software change often results in a short-term loss of productivity. Secondly, a transition to something new almost invariably necessitates that something is left behind. People undergoing change often experience a grief process, the extent of which depends on the size of the change, the length of time the person has been using the previous system, the level of personal comfort with the previous system, the individual’s social support network and probably a bunch of other psycho-social factors.
The stress of change is exacerbated when the change is involuntary. For most people, a change imposed by external forces is a source of disempowerment, reducing their feeling of control and increasing their stress.
2. Systems resist change
The stress of change is evident just as much in organizations as in individuals.2 An organization is a complex system, and like all complex systems it seeks equilibrium. Organizational behavior tends towards a point where inputs, outputs, and internal processes are all stable. Such systems react to change as a threat and act to restore equilibrium.
In some cases change is resisted and sabotaged so that the organization reverts to the known equilibrium of the past. In other cases, change is accepted and the organization moves on to a new equilibrium. What guides an organization towards the second scenario is effective change management. This is where Lewin’s “Unfreeze, Transition, and Refreeze” approach can provide a useful framework.
In Why resistance matters (available from “http://www.beyondresistance.com”:http://www.beyondresistance.com/), Rick Maurer notes that “Resistance is not the primary reason why changes fail. It is the reaction to resistance that creates the problems.” The professional IA will understand that resistance to change is inevitable and should use some of the techniques below to pre-empt and respond to that resistance.
3. Communicate
The people who will be affected by an IT change are unlikely to be impressed if the change is just sprung on them without warning. IAs can reduce resistance by ensuring that the nature of the technological change and expectations of behavioral change are communicated ahead of time. Concerns to be addressed include “Why do we need to change?”, “How will the future state differ from the current state?”, “When will the change occur?”, “Will it happen all at once, or gradually?”, “Will I receive the training that I need to make the changeover?” and “How will the change benefit me?” The last question is perhaps the most important, because people who can see the benefits of a change are far more likely to support that change.
Even if you believe the change will benefit the users, they may still have their own reasons for subverting the process. There’s a saying that goes “You can lead a horse to water, but you can’t make it drink”. I once heard a psychologist add to that saying: “But you can put salt in the oats!” He meant that you might be able to make the horse thirsty enough that it will welcome the water.
The next few points suggest ways to “salt the oats”.
4. Use participative design to foster “ownership”
There are many forms of communication and not all will avoid the resistance to change. If communication is one-way – from the people imposing change down to the users – resistance is virtually guaranteed. And it’s no good faking two-way communication with a couple of open question and answer sessions and a suggestion box. What you want is real involvement throughout the process by the people who will be affected by the change.
In a “First Monday article”:http://www.firstmonday.org/issues/issue10_7/marty/index.html, Marty and Twidale repeat a common claim that “the best way to evaluate an interface for usability is to test that interface with representative users”. I don’t disagree, but I believe that greatest benefit of user testing is not the feedback it provides about usability but the opportunity it provides to involve the users in the IA process. User testing is an important means by which the voice of the user can influence design decisions. The more participation there is by the user community, the more that community feels some control over the change.
This is a basic principle of participative design.3 When the people affected by a change feel ownership of the change because they were part of its design and development, they will more readily support the behavioral changes necessary to make the system a success.
Associated with this sense of ownership is the value of a shared vision. If the body of people who will be affected by a change understand the intended future state and are convinced of its benefits, then the energy and excitement within the group can drive the transition forward. This is even more so, of course, if the users created the vision in the first place.
5. Build relationships
The IA who is just a technical resource is far less valuable than one who can listen, build trust, and facilitate group interaction. The effective change agent is adept at forming relationships with business management, other technical contributors, and users. The IA is typically not the head of this team, but can be central to it, playing an empathetic and facilitative role as a conduit between the various stakeholders.
The IA can make a big difference to the outcome of a project by relating to users in a way that acknowledges the value of their contribution. That can be done by taking their opinions seriously (which is what user-centric design is all about), by personally thanking them, by giving public recognition of their ideas and by engendering a collaborative environment that encourages honesty.
6. Find a sponsor and a champion
In the team responsible for implementing a new system, two particular roles are worth special mention: the Sponsor and the Champion.
Some writers confuse or conflate these two roles. In “Think like a consultant”:http://www.interactionbydesign.com/thoughts/thumbnails/00000016.html, for instance, George Olsen considers the need for an IA to be an agent of change and suggests the priority of enlisting the CEO as a champion but I think he means a sponsor. A Sponsor (or Patron) is a high-ranking person whose support for the project will guarantee that others will co-operate. The Sponsor just needs to “give the nod” occasionally to vest the IA with authority.
In most cases, however, the IA will not be senior enough to call the shots. Even with the Sponsor’s blessing, the IA will need the support of other significant change agents. In many cases, it is an effective partnership between the IA and the Champion that drives change. A Champion is the one who will push the project forward; ensure that the right people attend meetings, hire the necessary consultants, talk to everyone about how important the project is, inspire the team, push aside the barriers etc. Whereas the IA is often an outsider, the Champion is a respected and trusted leader within the organization.
The Sponsor and Champion may not always be two separate people: they may be one or it may be that many such people are enlisted to help others to change.
7. The objective side of change management
Not all change management is as “soft” or subjective as the previous suggestions might imply. Insights from Enterprise Performance Management approaches, such as the Balanced Scorecard Methodology, can add elements of objectivity to change implementation.
* Document a set of clear goals, for example, “Decrease data entry error rates”. If an IA project doesn’t have goals, how will anyone know whether it succeeded?
* Define a set of measures that indicate the extent to which the goals are being met. In many cases, these need to be tracked over time or at least measured before and after the change. For example, “Number of times data validation errors are displayed” and “Percentage of transactions that are edited after initial submission”.
* Identify project risks–that is, internal or external threats to the stated goals. Categorize the risks according to their estimated likelihood and potential impact and then plan how to either avoid them or mitigate their effects. For the IA, one significant risk will always be lack of user acceptance of the new system.
* Reward behavior that supports the goals. That’s pretty obvious really but often overlooked. What do data entry operators gain from making fewer errors?
To understand how these suggestions can be quantified and systematized there’s a good overview of the Balanced Scorecard Methodology on “answers.com”:http://www.answers.com/topic/balanced-scorecard?cat=biz-fin. While these techniques are totally ineffective without the inter-personal dimension, they can add depth to the IA’s toolkit and help to position IA within the larger domain of organizational strategy.
Conclusion: Encourage Authentic Participation
Through this article I’ve focused on that aspect of the IA’s role by which they contribute to change management. This may not be their primary role, nor even an essential role but being an effective agent of change can often mean the difference between a successful IA project and a failure. An agent of change needs to understand organizational dynamics and use their inter-personal skills to facilitate, motivate and empower behavioral change. I believe the most important principle in this process is to encourage the authentic participation of the people affected by a technological change in the design and implementation of that change.
Oh, and here’s the promised entertainment … Change is inevitable, except from vending machines.
Further Reading
Some useful starting points for studying change management further might be:
* Fred Nickols’ “Change Management 101: A Primer“:http://home.att.net/~nickols/change.htm and his lengthy “bibliography”:http://home.att.net/~nickols/change_biblio.pdf.
* The white paper Organizational Change: Managing the Human Side, available from “http://www.apqc.org”:http://home.att.net/~nickols/change_biblio.pdf
* Dagmar Recklies’ article “What makes a good change agent?“:http://www.themanager.org/Strategy/change_agent.htm
* Enid Mumford’s online book “Designing Human Systems: The ETHICS Method“:http://www.enid.u-net.com/C1book1.htm
Footnotes
1. See “How to Spot a Failing Project“:http://www.cio.com/article/124309 by Rick Cook for a discussion of IT failure rates.
2. Some consultants, such as “Sandy Fekete”:http://www.companiesarepeopletoo.com/, push the analogy even further, evaluating “corporate personality” using psychological instruments like the Myers-Briggs Type Indicator.
3. The term “participative design” can be understood intuitively to mean “involving the users in the design process”, but I’m actually referring to the technical use of this term as it is employed by “Enid Mumford”:http://www.enid.u-net.com/ and others who follow the socio-technical approach to systems design.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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: 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.
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.
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.
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.
Keith – Your comment about the change conference made me chuckle. Years ago I attended an internal conference on “accelerating change” that included everyone from executives to developers to marketers… and I was the token UXer. There must have been 20 times during the short conference where some well-meaning individual would say, “We need a process improvement to help manage XYZ kind of change in the ABC process,” and I would reply, “The process you’re suggesting already exists… we call it user-centered design.” And they would look surprised and say, “Oh, I didn’t know that was part of UCD!”
It was oddly depressing and encouraging at the same time.
P.S. Don’t worry about the use of “quoted terms”. As a longstanding “violator” in the overuse of “scare quotes” and “using quotes to make sure people don’t take this word too literally”, I proudly stand behind your “right” to use quotes whenever you deem “necessary”… I find their use almost as “addictive” as I do unnecessary clauses.
I think the theory of this article is really important to understand. However it is the application of this thinking that gets a bit difficult. I’ve come to expect concept maps and diagrams when I read articles on Boxes and Arrows, which illustrate the thinking of the writer.
I work in a non profit where our goal is to create an adult-business infrastructure that reaches inner city kids in non school hours and provides age appropriate mentoring, tutoring, coaching, etc. from elementary school all the way until the youth is in the first stages of a job. There are huges systems changes implied in what I’m trying to do, and thus there is all sorts of resistence. Many people don’t understand what I’m talking about because it comes from a different frame of reference, and from a speaker who is not a traditional leader.
Thus, I’ve started to use concept maps and other communications tools to illustrate this thinking. You can enter the maps at http://cmapspublic.ihmc.us/servlet/SBReadResourceServlet?rid=1178301962705_378512451_14531&partName=htmltext
I’m not an expert in IA or other forms of visual communications. My goal is to recruit people who do have this expertise, and who would use their talent to help me a) because they care about the cause; b) because they expand their own knowledge and experience in facilitating change.
I hope that some of you will reach out to me here, or on Face Book, or at http://tutormentor.blogspot.com and offer your talent to help facilitate the massive systems change that would result in more kids born in poverty having the adult network that assure that they are in jobs/careers by age 25.
Daniel, you’re right that theory is easier than application. I’ve heard it said that in theory there is no difference between theory and practice, but in practice there is!!! Your aim of empowering youth is admirable and I wish you well.
Matt.
I would hesitate to call yourselves change agents if only for the same reasons as Terry mentioned above. Yes any IA work will cause change, but lets face it, so does pretty much any work. If I fill up my car with petrol, am I a change agent? I am, but I wouldn’t like to call myself that. What do I think would be a good term? I hate to say it but user experience designer seems about right to me.
In other ways I agree with both Terry’s and Matthew’s conflicting points on who should change. In the case of the farmers mentioned at the start of the article, obviously it is the ability of the process to change to the way the farmers will work. However if you are designing software to improve efficiency internally, then it will need to be the users? The difference is the purpose of the design. One is designed to improve business processes and is in many ways mandatory, the other is purely an optional thing that people can use, or not. In the former case you are more likely to get resistance, in the later it just won’t be used. How you approach the work should then reflect this.
Simon
Simon: I see your point, but the other important part of Matthew’s article has to do with changing the way the development team works in order to produce a quality design. As he says in the article, “Sometimes this role is within the product development team: educating and channeling the team to “take on board” good IA practices.” To put it another way, if a user experience designer accepted all the existing organizational, process, and cultural norms on a project and did nothing but whatever design they had been assigned, would they really be accomplishing everything they could be accomplishing? Very, very rarely, IMO. This is what I meant above when I said, “All the really interesting things that I’ve done (or need to do!) have required some form of organizational change,” because I believe removing “roadblocks” to usability leads to bigger improvements than producing high quality design… which may or may not get implemented as designed. I consider this to clearly be a “change agent” role.
I agree with you that when Matthew extends this role to the customer, things get murkier, but I think he has an interesting point that the same skills that apply to internal change management also apply to producing software that will require change on the part of the users.
I’m glad Terry picked up that the IA may act as change agent within the development group just as much as within the user group. I hadn’t actually identified that distinction clearly myself, which is why it’s quite hidden in the article.
Maybe I could also have been more explicit in stating that I agree with Tom Reamy’s point (reflected by Simon’s comment) that _many_ people act as agents of change and that it’s not a role that is _essential_ to the definition of IA. But like Terry, I think that some of the most interesting and valuable contributions of an IA are in that area.
–Matt.
I totally agree, but you have to consider that the norms might be there for a reason, and these reasons should be considered in the first place (never thought I hear myself saying that). There is little point in change for changes sake, only to increase efficiency and reliability.
On the point of going out to the customer. I would again say thought that it depends on your market. Say you have a new tool for the IT industry. They are probably more able to cope with a different interface design. However you look at farmers (and apologies to all the high tech farmers out there) or a better example is say pensioners, and you would need to develop something that would not be too confronting, or so different from a standard web interface that they are not prepared to go further.
Great article. I’ve been busy with work and just got a chance to read this.
I agree that the IA may need to be a change agent on many fronts.
A few years ago, I worked with a client to re-architect and redesign a large public site. Our team started with a usability review, developed user scenarios, conducted focus groups, developed a more user-friendly IA and content structure, and designed a site that got much closer to meeting the public site user’s needs. We also made recommendations on repurposing old content, creating new content, and deleting outdated or bad content.
The roadblock came when the client needed to gather new or repurposed content from subject matter experts. While originally behind the redesign, the subject matter experts were overwhelmed by the work they saw in front of them. Client-side staff started asking why a new IA was even necessary. It was the new IA that they thought was causing their pain…so, it was the new IA they attacked. We had planned on resistance here. We just didn’t expect it to be so strong. Part of the problem was that the client-side person in charge of content strategy didn’t really implement an internal process for content development as expected.
We didn’t want this resistance to cause failure in what we thought was a solid IA and a great site improvement. In this case, we acted as their internal change agent. Our IA and content expert quickly scheduled a meeting with all content providers, discussed their concerns, and then scheduled a half-day workshop where our team helped them prepare content to fit into the new IA. We also provided quick-start tips and checklists. It became a fun workshop and some staff even completed their content during that session. In the end, the public site was a huge success and the staff supported the new IA.
Great story! And getting the reisistors together for a workshop is a great solution. That’s an especially good solution when there is a lot of murmuring and gossip, or when everyone is blaming someone else. Get the various parties together and bring the concerns out in the open. You’ve got to make sure, however, that the facilitator is up to the job otherwise it can be a disaster.
–Matt.