Systems — including information environments — need to adapt to changing conditions. If they don’t they won’t be around for long. If your aim as a designer is to produce a resilient system (and why wouldn’t it be?), you need to consider how it will address change.

Think of an information environment where users of a family of software products solve technical problems. When you’re designing such a system, you start with a particular set of information that needs to be shown to users, a taxonomy that will affect how people find this information, and navigation structures that allow people to move around the environment.

This particular configuration won’t stay fixed for long. It will need to respond to changing conditions inside and outside the system. An example of an internal change: the company launches a new software product which requires new tech support information. An example of an external change: a new technology appears that allows for instant live screen sharing with website users.

You can design a system to be very pliable (it changes frequently and in multiple ways) or very rigid (it changes infrequently and only in a few key ways.) In the former case, the system is at risk of losing its integrity; it will respond to change by changing what it is, compromising its objectives. In the latter case, the system will preserve its identity, but risk not going far enough to accommodate changing conditions. After a while, it will be rendered obsolete. Different systems call for different balances, but I suspect most of the time you want to be somewhere in the middle.

Wherever you land on this, be certain that your system will need to address change. If you think through how it will respond, you have a much better shot at creating resilience. Here are some questions to help you think through the pliability of your system:

  • How do you know something has changed inside the system?

  • How do you know something has changed outside the system?

  • Which system parameters are open for re-consideration? (Variables vs. constants)

  • How do you ensure the integrity of the system isn’t compromised by change?

  • Who will be responsible for determining what needs to change?

  • Who will be responsible for implementing changes?

  • How frequently must evaluations happen?

  • How will this work be funded?