Mar 30, 2007
Designing with Constraints: The Good and Bad
Ever since our yearly journey to Austin, TX and the massive SXSW Interactive conference a few weeks back, I have been thinking a great deal about constraints and their role within web design. I came to the conclusion that they are both good and bad. Understanding both has been pivotal for us in building a successful web design company.
The Good
While it may not seem like it all of the time, structure inspires great work. Nasty terms like "deadlines" and "client specifications" exist for real reasons, and can actually be used as an advantage for designers.
I have heard a number of designers speak about the power of a deadline to make them try something they never would have tried. Somehow in those last hours, the light bulb comes on. Or maybe being forced to work within a specific wireframe for a design helps contribute to an idea you never would have been capable of without structure.
I see evidence of this principle often when designers have ultimate freedom, like on a site of their own. There are no deadlines, so the site literally takes months longer than it should. Sadly it also results in a sub-par product, simply because 110% effort is never given to it for any considerable amount of time.
A site without written specifications or pre-meditated structure can also suffer from the same complications. When we have ultimate freedom, somehow that makes us want to insert every possible feature or design concept. Again the end result takes much longer and it can be very cluttered.
Constraints only allow for the necessities and nothing more, which is a good way to start on the web.
The Bad
One thing people perceive as a constraint that I don't understand is code. Thanks to technology, the web is a place where most anything is possible to create, so I see no reason to take shortcuts or water things down by considering code during the design process.
Quality web design should start with a user-friendly interface, something that is intuitive for users of all experience levels. Keeping that in mind, there is a TON of room for being creative and building a user experience that is not only functional, yet fun to look at and representative of everything the brand is about.
This principle comes into play with our design process at Project83. Our designer Jared does not get involved in the coding process. I believe this helps him focus on his primary objective, which is design. While having an understanding of how the code works, it is not a primary factor when focusing on the creative process in each site's development.
Jared's designs are very detailed, often encompassing tons of layers, gradients, rounded corners and other elements that are scary for geeks. But those characteristics make a good design a GREAT design, something that really leaps off the page. By thinking about the code and how much longer details like that would take to add, we might leave them out. Sure it can take much longer to code the design eventually, but I think it is absolutely worth it.
This is something I have grown to feel very strongly about. First, design for users. Then design for the sake of creating something unique, detailed and representative of the particular brand.
I would like to encourage all web designers to create something without code constraints, as if it were only being printed out. The result could very well be a design with more depth, detail and overall character.
Of course there will always be exceptions to both of these rules about constraints. I see more and more incredible design on the web every day. But in general, I feel these principles have merit. They certainly do in the way Project83 develops websites.
Posted in Project83 - Web - Join the Discussion (1 Comments)



