As a web developer, I find myself having the same conversation over and over with HTML designers when it comes to agreeing on how to style common markup elements. The development cycle I experience usually ends up looking like this:
1. Requirements are agreed upon, and handed to the project team.
2. The PM tells the HTML designers make wire frames, screen comps, and they get approved.
3. Everyone codes frantically – HTML designers are making markup while coders are making functionality.
4. Coders finish a chunk of functionality, and match up the HTML they are rendering against the HTML that the designer has mocked up, only to find huge differences.
5. Frustration and refactoring on both sides of the fence ensue.
While the disconnection between steps 4 and 5 may seem pretty obvious (and may even be lessened by careful planning and communication), it happens frequently because of two immutable aspects of developers and designers:
1. Most HTML designers don’t know (or don’t care) about the hoops that developers have to jump through to get HTML to appear on the screen.
2. Unless you make styling a requirement for a deliverable, your developer is not going to even think about styling until the code at least performs the functions required.
I believe that the best way to address this problem is to cross-educate. Developers should spend some time becoming savvy on the practices and principles that their designers employ. Designers should become aware of how the developer’s programming platform generates common elements (such as how data repeaters will generate tables, how controls are dynamically named based on their containers, etc.).