For those who are involved in bringing products to market it is interesting to look at Adhocism as a piece of consumer behaviour. What exactly does it mean when one of our users picks up our carefully-honed product and does something completely unexpected with it?
Now, come on, be honest: it has happened to a greater or lesser extent, with every product we’ve ever worked on. “You don’t use it like that!” exclaims the software engineer when told of a bug which only appears if the user demonstrates, to the engineer’s eyes, perverse and abhorrent behaviour. The engineer’s reaction is likely to be to lock out that behaviour rather than fixing the underlying bug.
As a user, isn’t that part of the fun of starting to use a new product? The “I wonder what this does?” childish exploration of a new device. And as we explore, we start to find ways to apply the functionality that we discover. That application is as much a result of our own environment, our experience and our inventiveness as it is the product’s actual features. Oh, and almost nothing to do with the product designer’s intentions.
To me there are only two sensible reactions to this; denial or acceptance. Where it is really important that the user does follow a very carefully preordained sequence of operations, say in systems that can endanger lives, then we really need to deny them the possibility of adhocism. Recognising that we should help them to stay on track, and more importantly, try to retain their attention.
Where there is no such overriding concern, we really need to relax and give the user as much opportunity as possible to adapt what they do and how they do it. Despite all our market research we really cannot predict what a user may be trying to achieve when they use our products, so give them the possibility of using the functionality in any way that they want to.
I believe that the reason we don’t do this more often is because it is a whole lot harder to achieve this than deciding on a single path, and leading the user by the nose along it. We have, for example, to explain what each part of the functionality actually does, and then to design our systems so that the user can do things in different sequences. So here are a few principles for allowing Adhocism into our products:
- Design your UI so that users can investigate it and learn what the product does
- Break sequences into natural steps that can build on each other
- Find to display the status of each process and its associated data
- Give feedback on what the product is doing and how far it has got
- Allow for import and export of data at every stage so that several products can be used together
Finally: remember that wizards (and witches) are for 12 year old fans of Harry Potter.
