Restrictive design

When we speak about design, it is surprising how often we mean creativity and idea exploration. The nature of design is unlimited and mystique—it's a world of known and unknown, visible and invisible, a world with unclear and even non-existing boundaries, which only a naive designer might try to explore in the hope to prove that the impossible can be converted into the tangible. Such wide thinking is very stimulating and beneficial, but it can also be a waste. With brainstorming under constraints, we can generate ideas more effectively. But we also need to restrict ourselves throughout the execution path that will lead to the final design—the intended result of the idea. Very often, we lose ourselves in the details of going through the path, without noticing that we peaked all possible indicators. In the name of the end result, we allow ourselves sloppy execution, not being assertive enough of the context in which individuals and teams should operate. In order to be suitable to our current project or situation, our actions need to be clearly prioritized.

How we work can be affected in many ways and they need not always have to do with resources like time or money. For instance, it might be a good idea to limit the expenditure of energy during the day and use it more wisely where it can bring the most value. Running wildly might not give the best results at the end of the day. Communication within a team can also be limited, so that members quickly discuss multiple issues together and return back to work as opposed to having frequent chats on small things. Collaboration can also foster creativity when people work in pairs for a limited time and then change their partners.

Restrictive design seeks higher cost-effectiveness. We ask how we can do less things better instead of doing more, but low-quality things. So we can't say that responsive design is restrictive, because we have to deal with more breakpoints, more devices and more browser tests. But if we ask ourselves how we could possibly finish a project in ten days instead of fifteen without sacrificing quality, we might find potential problem areas that wouldn't be visible otherwise.

It's easier for restrictive design to work in isolation, which allows us to experiment and learn faster from it, getting enough feedback early to move in the right direction. A minimum viable product is created in a very restricted way, but very often, the "today and now" mentality can be a sign of inability to delay gratification, which—in the long-term—will always lead to mediocre products, since they weren't a result of a systematically developed, thought-out concept. It's rare that a product created in a day could survive market exposure; feedback in itself isn't sufficient to change this. Working within a set of constraints doesn't always have to mean "minimum", especially when clients tend to prefer "maximum".

A portfolio of restrictions isn't necessary a bad thing to have. It can be very versatile due to its similarity to a pattern library and its project-components can be applied with less effort to a more diverse set of future projects. It isn't as specialized and specific to be considered useful only by a few clients.

Restrictive design isn't showy or pretentious; it's rather quiet. People who practice it, put effectiveness on pedestal, knowing that beauty lies in the simplicity of the solution as a whole and not just in the visual design, however exceptional it might be.

By trying to delight people, we often invest disproportionate effort, which can limit our future ability to work. By being restrictive about how we execute, we start to see through the limits of our ability, realizing that extraordinarily simple is almost as hard as extraordinarily beautiful if we abstract away the need to make both usable.