Design as an Emerging Property of User Needs
In my latest koan, a craftsman is mystified. He makes exactly what people ask, but somehow they end up being disappointed.
Also in software design there is a difference between an ask and a need.
In 2005 I was designing a scheduling application for a services company.
While looking for design ideas for an appointment calendar, I found an article by Ryan Singer about the use of patterns in web design.
It laid out a process of grouping lists of design considerations, and putting them together using a technique described by Christopher Alexander in Notes on the Synthesis of Form.
I was intrigued by the concept, and it made me realise that there was a flaw in my design. The client had asked for a calendar, and that seemed to make perfect sense, as service providers needed a place to see their appointments together. But neither the client nor I had taken the time to fully understand the context. There are multiple ways to show appointments. A calendar is just one option.
I started out with a list of user needs:
- the employee needs to know his route and schedule for the next two days,
- appointments are mostly scheduled in the same part of the day (morning, afternoon, evening),
- etc …
I ended up with a design that was much easier to read, and made much more economical use of screen space.
The reason that the Alexander method works so well is that designs are much more closely shaped around user needs and context. Instead of imposing a solution on a given problem, you let the context of the problem guide you to a suitable solution. The design designs itself.
I have used this method ever since, and it has served me really well.
In this video, Ryan explains the Alexander method in more detail. Highly recommended.