The relationship between designers and developers is too often overlooked on projects. Commonly the two teams are removed from each other and designers are asked to simply throw their work over the fence to the HTML monkeys who faithfully turn the designs into a webpage using 10,000 typewriters. At SolutionSet, the “front-end” of a website is a combined effort of three different teams; The IA/UE team does the sitemap and the wireframes, the design team creates the designs, and the HTML/CSS team takes the designs and turns them into a web page. It is all too easy to fall into a pattern of non-communication between the departments where we start to lose focus on the real people that live on the other side of the proverbial fence.
In the web industry, there is a long standing battle between the design team and the development team. One source of the conflict comes from the varying backgrounds of the designers who may have a stronger background in advertising or print rather than web. In reality, it is the designer’s job is to push the envelope and make something inspirational, drawing from a diversity of sources, not just the web. HTML/CSS developers usually make poor designers because the more experience they have with HTML, the more practical their designs become. This is another source of the conflict: the developers can feel like the designers are punishing them by building designs that have drop-shadows over gradients, multiple different homepages load at random, as well as many other interesting and creative ideas that become difficult to translate into a syntax.
The conflict can get even more heated with a looming deadline. With a few pen strokes on a Wacom tablet, huge swaths of functionality can be added to a project. Suddenly there are light boxes everywhere, stylized tooltips, special buttons, a different width for the left column on every page, and the list goes on. Digesting a PSD is a daunting task and the natural process of design approvals ensures that each page will be *slightly* inconsistent. And of course, the design needs to be ready by next week so that the back-end team can take over.
It is extremely difficult (and not always desirable) for the designer to fully consider the development implications of a specific design. The developer is also faced with the fact that they are going to need to get elbow deep in the design, inspect it with a fine tooth comb—often zoomed to 1600%—and do it fast. This can get vicious for both sides.
Designers can develop too!
First, any designer that knows the most basic of the HTML/CSS rules will already bring something special to the table. Web designers should familiarize themselves with the basic rules of HTML/CSS and interactive elements in Javascript. What bugs exist in IE6 and IE7? What are the difficulties that come with lightbox that covers a flash element? Will my developer be able to implement an ajax image gallery if he has 6 HTML pages to build in a week? With basic HTML skills, the designer can not only create beautiful designs for the web but also determine the best way to create web beauty and developer friendly designs.
Developers can be designers too!
This one is huge. Get a front-end developer into the project life cycle earlier. Get them in on the design reviews, interactive design reviews, introduce them to the project timeline, the client, and the designer. This will allow the designer and developer to communicate with each other and gain a better sense of the difficulties of both sides. Letting developers become part of the design process allows them to gain respect from the designers for knowing what visual hierarchy is just as the developers are impressed by the designer for knowing about the double-margin bug in IE. It’s important to remember that most front-end developers went to school for web design not a degree in HTML/CSS.
Module design/development
In college a web designer friend of mine introduced me to a design methodology that he practiced that completely inspired me and has since become my primary way of development. When designing, he first determines the layout of the site (Right sash, left sash, 3 col, etc), the color scheme, and builds a logo. From here he designs all of the sites standard elements. This includes h1 - h4, paragraph text, links, link hovers, ordered and unordered lists, blockquotes, tables, numbers, drop caps, forms, buttons, any elements that the site will need. Then he designs by element in a modular way. He will take the header box and start designing only the header. He will add his login form, his logo, anything he wants to go in the header. He will not touch the navigation, the body, the footer, nothing else on the page until his header is complete. Then he moves to another element, and one after another he puts together a page. This is now how I develop. Build a navigation (or whichever element is ready to develop) in HTML/CSS/Javascript, test in all browsers, then copy/paste into the main site layout. This allows me to complete element by element and keep them all separate not only in my html but on my stylesheet. Everything remains completely organized, consistently cross browser compatible, and easily replicable.
A strong bond between the designer and the developer can create an extremely efficient development cycle using this type of methodology. There is always an offset between what the designer is designing and what the developer is developing. We obviously can’t be developing the footer until the designs are complete. The idea of modular development reduces the offset. If both the designer and developer can move from element to element, both teams can nearly work in unison.
At SolutionSet—time permitting—we produce style guides after we’ve had the initial designs approved by the client. Style guides essentially distills the Photoshop document into its base elements. There will be a page describing the grid, a page listing out all of the header styles, and so on. This is also a positive step in the direction towards modular design. Style guides help catch funny situations like having 25 different header styles on a site. In general, the style guide records the intent of the designer much better than the raw PSD’s. A designer under a time crunch can make minuscule mistakes (most frustratingly page to page) that aren’t noticeable to the naked eye but make a big difference in the CSS.
There’s always ways to improve a process. The biggest challenge is trying to make common practice out of something that is constantly changing. Every project is unique, every design will be completely original, new browsers will launch. It’s a tough world to keep up with. We shall see if some of these new ides bring anything to light. If you have other ideas, please contribute.
