I’ve been writing about design and usability recently, including a good example with the iPod and a case where a new elevator system could use some work. Naturally, there are many poorly designed systems out there, and they’re easy to spot, but even in the case of the iPod, which I think is well designed and elegant, I was able to find some things that could use improvement. Furthermore, I’m not sure there’s all that much that can really be done to improve the iPod design without removing something that detracts more from the experience. As I mentioned in that post, a common theme on this blog has always been the trade-offs inherent in technological advance: we don’t so much solve problems as we trade one set of disadvantages for another, in the hopes that the new set is more favorable than the old.
When confronted with an obviously flawed system, most people’s first thought is probably something along the lines of: What the hell were they thinking when they designed this thing? Its certainly an understandable lamentation, but after the initial shock of the poor experience, I often find myself wondering what held the designers back. I’ve been involved in the design of many web applications, and I sometimes find the end result is different from what I originally envisioned. Why? Its usually not that hard to design a workable system, but it can become problematic when you consider how the new system impacts existing systems (or, perhaps more importantly, how existing systems impact new ones). Of course, there are considerations completely outside the technical realm as well.
There’s an old engineering aphorism that says Pick two: Fast, Cheap, Good. The idea is that when you’re tackling a project, you can complete it quickly, you can do it cheaply, and you can create a good product, but you can’t have all three. If you want to make a quality product in a short period of time, it’s going to cost you. Similarly, if you need to do it on the cheap and also in a short period of time, you’re not going to end up with a quality product. This is what’s called a Trilemma, and it has applications ranging from international economics to theology (I even applied it to writing a while back).
Dealing with trilemmas like this can be frustrating when you’re involved in designing a system. For example, a new feature that would produce a tangible but relatively minor enhancement to customer experience would also require a disproportionate amount of effort to implement. I’ve run into this often enough to empathize with those who design systems that turn out horribly. Not that this excuses design failures or that this is the only cause of problems, but it is worth noting that the designers aren’t always devising crazy schemes to make your life harder…