| HN Mirror

Well, if you ever do end up writing that follow-up post, I thought I'd share a game that I play with my brother, that I have found to help me enormously with interface design.

Some background - I'm a software engineer, with my true love being application design, though I have often worked in other fields. My brother is an architect, so he has had quite a bit of formal schooling in design technique, and well, he just enjoys doing it. Anyway, when we get together, we have a game we like to play where we pick an average every day device, and we try to design a better user interface for it.

There seems to be a very constant sequence of actions that we do when playing the game. The most important of all is to start playing the game - which is to say if you aren't trying to improve an interface, you never will. But once we start trying to improve an objects interface, we generally start by identifying flaws in the current design, the pain points. Once those have been found, we start tossing around ideas that might fix the flaw. It's at his stage that something interesting starts to happen - you get a deeper understanding of the problem the object was trying to solve, and that understanding frees you up to try something really different - the old smartphone to iPhone type of jump.

To give an example, the last time that we played the game, we were working on traffic lights. Some of the flaws that we found included:

Light bulbs that blow

Lights get lost in the background of dense cities such as Paris or London

The posts take up valuable street space, making them a hazard for pedestrians and dangerous if a vehicle loses control.

Inflexibility to changing conditions - for example, when I'm the only driver on the street for the last 10mins, why can I get stopped at lights for a minute waiting for it to go green?

Once the flaws are identified you can start tossing around solutions. In the case of the traffic lights, we started to understand that the object itself was the problem. Traffic lights are a solution that was designed before the advent of ubiquitous computers and wireless communications. These days you could design a system where your car receives a signal from any intersection saying whether it has tonstop or not. The traffic light itself can be moved inside the car, or even tied to the control system if you are about to run a red light. That would be a good first step, no more poles, no more distraction from blinking neon signwork. But ther would still be the problem of maintenance, the radios could blow. And it still doesn't stop you from getting stopped at an empty intersection.

Our next iteration required a deeper understanding of what traffic lights are actually trying to do, rather than just understand what they are doing. They are trying to control traffic flow. So, the final solution to traffic lights is to find a better traffic flow solution. In our game we eventually decided that ai cars, capable of driving themselves and connecting to a regional traffic control server, would be able to negotiate their passage at each intersection. No more traffic lights anywhere in the system, because at the end of the day they are a hack that was created as a stopgap solution at a time when we didn't have the technology to do any better, and which now continues on due to inertia.

Anyway, if you keep playing the game, you eventually get to the point where you really start to understand design as being an attempt to get to the heart of the problem you are trying to solve. This process helps you find the original solution to the problem that makes your object a plaesure to use rather than being something that you have to fight against