Good ol’ design constraints. They definitely keep life interesting. On good days, they are important drivers for innovation because of their ability to clearly outline what is not possible–subsequently giving shape to what *is* possible. On bad days, they can become the designers worst enemy: derailing design direction or collapsing the solution space to an unworkable singularity.

So how can we have mostly good days? One instructive way is to understand how things can go awry.

Timing

Oftentimes, it’s not the design constraints themselves that are troubling, but the time at which they appear. Slow requirements gathering, unplanned technical limitations, and late-stage usability testing can all reveal serious constraints late in the product cycle. This type of constraint can nix a design instantly and often crop up with even the most careful planning. Of course, with less than perfect planning, they crop up constantly.

Mental Blocks

These are illusory constraints, often stemming from limitations that no longer exist, or from long-standing biases and mental blocks on the part of the team. The only way around this is persistent creative thinking, and a willingness to question why certain constraints exist. This is easier said than done of course, especially if the illusion is being projected down from the top.

Reasoning

Design constraints are often the result of a reasoning process that underestimates the difficulty of changing the design versus changing technical or business requirements. For a manager, it can seem like the right choice, since it’s easier to envision a design change than fully grasp a technical change. But just as technical changes can be hard or easy, interface design changes can be hard or easy as well. There are foundations like the global interaction metaphor and the information architecture which are very difficult and risky to change late in a project. The reasoning gap occurs because a manager can sketch out “this other great way to do it” in 30 seconds. It feels easy enough, but enforcing mixed metaphors quickly leads to unworkable constaints.

Now that I’ve hit some ways that design constraints issues, it’s your turn. What’s the funniest or craziest constraint that’s crossed your design desk? What was the best?

The product was a speech-recognition driven auto attendant - you say the name of the person you want to speak to, your name, then you get connected to the person you want to speak to.

Unfortunately, the speech recognition was taking too long, leading to a lot of silence which slows the user down and also makes them think something’s wrong.

So, the chief brain in R&D turned the speech recogniser into an almost asynchronous process. It would crunch for a bit synchronously (i.e. before returning to the dialogue engine) and return with an indication of its confidence that it would eventually come up with an answer (i.e. it would throw out the times when the caller said nothing, when a loud train went passed etc.)

Confident that an answer would happen eventually, the dialogue engine would then ask the caller their name, which took time to play a prompt and more time to record the answer. This gave the recogniser time to finish off the crunching in the background, and the dialogue engine would then collect the answer and route the call.

This was all before the current hype for AJAX - there’s very little new in computing, just the same old stuff done bigger/smaller/faster.