Design for wombling

In the 1970s the Wombles were Britain’s great engineers. They designed, built and fixed stuff by focusing on what was available and what worked, rather than using the proper stuff. There are lessons here for both software engineers and interaction designers.

Take Backpack. One of the great things about Backpack is that you can easily use it to do so many useful things and it neatly fits around your workflow rather than making you work around its workflow. And I bet that the 37Signals designers never imagined all the ways people might use their applications – and of course they didn’t need to, they just needed to design a system that let people womble. To work the way they want and support them in doing so.

The advent of SMS messaging is an even more stark example. According to Cor Stutterheim from CMG SMS wasn’t even designed for customers:

It started as a message service, allowing operators to inform all their own customers about things such as problems with the network. When we created SMS (Short Messaging Service) it was not really meant to communicate from consumer to consumer and certainly not meant to become the main channel which the younger generation would use to communicate with each other.

But because it was reliable, flexible, convenient and cheap the technology was repurposed and used by mobile ‘phone users in their millions.

SMS was the triumph of the consumer- a grassroots revolution that the mobile industry had next to nothing to do with and repeatedly reacted to. This is in stark contrast to the top down technology and industry led approaches to other nonvoice services such as WAP. (ref)

And away from consumer products we have the ubiquitous TCP/IP. Although it wasn’t designed to support the Internet as we now know it TCP/IP is the backbone for much of our social and business life. TCP/IP is able to be flexible and useful because the hosts and not the network are responsible for reliability. The network only enforces interoperability. This means it’s possible to join almost any network together, no matter what their characteristics. In other words its extensible, scalable and decentralised.

As Nick Gall in the Podcast TCP/IP and Shipping Containers argues if you want a system that is extensible, scalable and decentralised you need a solid, but basic underlying architecture. Too much architecture in the framework, and you’re locked in, without sufficient freedom. Too little, and you have neither interoperability nor room to improvise. In other words the users of the system can’t womble.

The balance between simple, formalised, underlying structure with a high degree of overlying freedom is critical. Too little structure and you are left with an inaccessible, chaotic system. Too much structure and you have a rigid product that can’t be easily molded into something else.

So what are the characteristics of systems that Wombles will be able to use in unexpected ways? I think they include:

• Independent subsystems tied together by a light weight, solid framework
• Defined and enforced interoperability between subsystems
• Platform neutrality
• General purpose simple interfaces
• Flexible user journeys and workflow
• Accessibility
• Open standards, open source, open protocols and open APIs
• Data neutrality
• And designed to respect that the data belongs to the user not the system

But I also suspect that the system itself can’t be built be ardent Wombles. If the system has be cobbled together then there’s a risk that it will lack the flexibility and structure necessary to allow its users to Womble – providing the light weight but solid framework may prove too difficult, or enforcing interoperability too cumbersome.

Photo: Flickr Hack #1 by Thomas Hawk. Used under licence.