Thinking in patterns

Lego. Every kids dream. Or at least it was, back before children fell in love with playing pretend tennis on a Wii, or becoming gangsta’s in GTA4. Lego is a great toy for children, it encourages them to create.

What’s wonderful about Lego is its potential. You can make houses, housing estates, race cars, pirate ships, pretty much anything you want. This is because Lego comes in atomic pieces. You combine very small details to make impressive constructs.

What would happen if the basic units of lego were houses, boats, cars, buildings, playgrounds? Would it still be that much fun? If your bucket of lego contained three houses, two cars, and a petrol station, you’d hardly enjoy the creative side of things. You’d align them correctly, and walk away looking for something better, as you weren’t able to create what you wanted.

Availability versus suitability

This is my difficulty with Design Patterns. They encourage designers to look for ready made solutions, or to modify an existing pattern to fit a new case, rather than focusing on the problem they’re trying to solve. As a result of this, and an availability bias, web applications are built with far less analysis and creativity, and far more carte blanche re-use of what’s already in a designers toolkit.

Patterns are quite useful when you need to standardise presentation of elements across an application. The familiarity they offer is great for important interactions where users would be concerned about the outcome, for example credit card transactions. However, as a designer most of your time will be spent tackling new problems, usually more complex than a credit card form, and this is when you need to be wary about regarding your stencils as your toolbox. Obstacles upstream propagate downstream. If you rely on the use of patterns, you will never create anything new, and it’s unlikely your solutions will fully address the problems you face.

Good Intentions

Much like copying someones style, you should use patterns only when you’re sure that their intent matches your intent closely, not at some stupidly abstract “User wants to perform a task” level.

Otherwise where does it stop? If you keep on abstracting you’ll get to a scary level where one solution fits all. Why not just have a “Website Pattern” and be done with it?

The Website Pattern is available for download under a Creative Commons Licence. The beautiful Lego picture was taken by by Eric J. Paparatto.