Managing Web Developers and Designers

John Reeve | July 7th, 2009 | , , ,

Project management tips for resolving web developer frustrations with web designers
Photo by e-magic

There has been plenty of venting in the blogosphere about the difficulty and frustration that ensues when dealing with web developers. In fact, we’ve contributed to this topic ourselves when we wrote about The Myopic Web Developer. In an ideal world there would be a unity between the designer and the developer, a shared understanding of the medium and a unified approach to problem solving on the web. However, that is rarely the case. It’s just the nature of how a designer thinks and executes her ideas and how a developer approaches and solves a problem. They don’t mix well in that overlapping area known as implementation.

Having been on both sides of the relationship I can demonstrably state that the inverse can be equally as frustrating. Here are some common areas where developers can butt heads with web designers and some of our experiential insight on how to resolve conflicts while keeping creative vision and practical implementation (and, let’s face it, egos) intact. As a web site project manager, understanding the nuances of the relationship between designer and developer will help you manage your online projects more effectively.

  • Line wrap (AKA rag, widows and orphans)
    I once spent hours on the phone with a production designer at a large design agency going through the web site page by page, line by line, inserting line breaks so the text would wrap the same as it had in the design comps they delivered. Being a big design firm with a strong print background, they were particularly concerned with the look or the ‘rag’ of the text and the widows and orphans the browser had created. When I tried to explain that the exercise was futile, that different browsers would display the text differently, that the user themselves could resize the text and render this a moot point, I was countered with one simple statement: The web site had to look just right on the CEOs computer. Every other user who might come across this site — potential clients, future employees, scrutinizing peers — would be thrown to the winds of the browser-of-choice rendering engine.

    Although we found no resolve, we did approach it the correct way. We explained to the client the consequences of their actions and gave our strong recommendation for leaving the text alone. The web, we explained, is a much different medium than print. Then we let them make the decision. That is all you really can do in a situation like this, especially when the client is paying the bills.

  • Desired design dimensions and common screen resolutions
    The abundance of web analytic tools has given us developers a wealth of information regarding the user’s browser environment and their online habits. These statistics are invaluable when designing for the web, however, some designers refuse to acknowledge them. For example, we had a client whose usage statistics showed greater than 60% of their online audience were using computers with a maximum screen resolution of 1024×768. The designers delivered a comp that was 1280×1024, with most of the site content falling below the fold. When we pointed out the discrepancies the higher resolution was defended as being a necessity to keep the site in the same ranks as other high end sites in the industry whose resolutions had moved beyond 1024×768 eons ago.

    We presented a healthy amount of evidence to justify reducing the site’s dimensions. However, quantifying the human response has been a subject of research and fierce debate for years. As developers we would put usability before brand. As designers, the inverse sometimes prevails. It’s best to follow the advice of the wise sage Kenny Rogers, who said “You’ve got to know when to hold ’em, and know when to fold ’em.” Engage both the designers and the client in an objective review of the facts and be OK with the fact that they may still choose to exclude your perspective.

  • Browser text and graphical text, the SEO debate
    Fortunately, SEO has come a long way in the minds of designers and their clients over the years. It used to be that any clickable text on the page had to be graphical to incorporate snappy mouseover effects and crisp anti-aliased text. Today, web browser and css improvements have given the web developer a lot of power in producing great looking text for navigation menus and buttons. However, some designers are still holding out for graphical text. It is true that some of the sites don’t need to be concerned with SEO. But, for those that do, it can be difficult trying to convince the designer that creating graphical text will hurt online search engine rankings. The most common response is that the brand is more important than the rankings. The font families used in the design of the site are inseparable kin sticking together until the very end, regardless of what fate awaits them.

    Your best bet is to rely heavily on CSS to convince the designer to switch over to browser text. If necessary, specify the first font as the actual font in the original comp. This way it will look pretty on the designer’s and the client’s browser, while the rest of the world will see the secondary serif or san serif approximation. We have had a lot of success using CSS to create web pages that are almost identical to the original comp, thereby convincing the designer to do away with the graphical text. In other cases we’ve been able to convince them to convert a good portion of the text while retaining a few of the brand essentials as graphical text.

  • Image optimization
    Another area of debate can be image optimization. As the web developer it is your job to find that happy medium between image quality and compression. While broadband is alleviating some of the pressure on creating smaller image filesizes, optimizing some images can still present challenges. The threshold of what a developer considers an acceptable optimized image is always going to be lower than that of the designer. When this has come up with past clients we’ve always been able to find an acceptable compromise by sitting down together and optimizing a few baseline images in Photoshop.

    Everyone wants the page to load faster, making this issue an easy one to work through with most designers. Sit down together and optimize a few baseline images in Photoshop. Take note of the filters and optimization settings applied to create the images and use them as guidelines for the rest of the images on the site.

  • Too much Flash
    Yeah, it still happens. Despite the inability to bookmark a page, or use the back button on your browser, or email a link to your friend, along with the absence of a number of other usability features, web sites are still being developed in Flash. And to make things worse, publications such as Communication Arts usually give Flash sites much more attention and praise in their interactive annuals then they do HTML-based web sites. There are some amazing Flash designers out there doing some great work, it’s just not the type of work we do. So when a client approaches us about building out a Flash site, we simply say “no thanks.” Some designers can be persuaded from building out a Flash site based on the sheer number of usability issues, while others may insist on it and choose to look elsewhere for a developer.

    Building out a Flash site can take a lot of expertise. If you have that expertise or have chosen to employ a Flash developer, by all means, pursue it. If, however, you want to champion the building of more content-driven, usable web sites, explain to the designer and the client the trade-offs involved when developing a Flash site. Awards and prestige can create an insatiable thirst for catering to peers instead of the end-user, but we never wanted to be rock stars in the first place. The question to answer is, do you?

  • Content to imagery ratios
    I do periodic portfolio reviews of students graduating from my Alma Mater, the Art & Design program at Cal Poly at San Luis Obispo. And what I often see are web site designs that were created in Photoshop and then chopped and tiled in ImageReady. The result is a well designed poster pasted onto a computer screen using hundreds of small tiles, with atrocious load times and a general uncertainty of what is clickable and what is not. It’s not their fault. They don’t fully understand how the web works — how HTML and CSS can be used in conjuction with Photoshop to create more fluid web sites with increased usability and much less imagery. None of them have ever worked with a web developer or have been required to learn development skills as part of their curriculum. It is, afterall, a design program they are attending.

    Fresh designers with little exposure to web development are still a part of the design and development process. It is not uncommon for a client to bring in a student designer or a freshly graduated one to save some money and give the designer some real-world experience. Having been this designer once myself, I welcome them with open arms. The best approach in this situation is to audit the design from the perspective of a web developer. Give them feedback on how to alter the design to make it more web friendly. They are fresh and they are young, they will soak up your words of wisdom like a sponge.

  • Navigating the site
    Ultimately, it’s the content contained within a web site that the audience is seeking. As web designers and developers our goal is to get them there as quickly and easily as possible. However, we’ve been asked to jettison drop down menus, search boxes, and other useful navigation tools because they didn’t fit the look of the web site. We’ve also built out designs where the primary content is buried several links deep in order to force the audience through a series of intermediary pages that reinforce a message or a visual brand. While I can understand the importance of emphasizing the brand experience in an overcrowded and noisy market, there comes a point where you have to draw the line and put the needs of the audience first. Otherwise, they’ll go elsewhere.

    Similar to the other examples above, there are usability studies that support reducing the number of clicks. Likewise, there is data supporting the impact of branding on the consumer. It’s a game of repetition being played against one of reduction. There are two ways we’ve approached this problem when working with designers in the past. First, we suggest dropping some of the intermediary pages that are funneling the audience into a modal method of perusing the site. These pages can always be reintroduced in other areas of the site. Second, we suggest creating an alternative route into the deeper areas of the site, thus creating a more flattened site architecture. This can be accomplished with drop down menus or lists of popular links — anything to enable the audience to quickly descend into the site while still maintaining the brand objectives of the web site.

Yes, every one of these experiences is a true story. And yes, we found a way through each scenario and found a way to work together toward a completed project. The important thing for the web designer and web developer is to put the project before their own pride and inflated egos and see it through to the end. And it’s the job of the project manager to keep the work flowing through all of the intricacies of such a working relationship, while simultaneously keeping the client happy and the project on time and under budget.

6 Responses to “Managing Web Developers and Designers”

  1. Tina says:

    Very true! That’s why as much as possible, I take out my designer and developer on a coffee or lunch before starting a project and discuss the possibilities of the design and coding. Lol! Thanks for the info and tips ;)

Leave a Reply

Intervals Blog

A collection of useful tips, tales and opinions based on decades of collective experience designing and developing web sites and web-based applications.

What is Intervals?

Intervals is online time, task and project management software built by and for web designers, developers and creatives.
Learn more…

John Reeve
Author Profile
John Reeve

John is a co-founder, web designer and developer at Pelago. His blog posts are inspired by everyday encounters with designers, developers, creatives and small businesses in general. John is an avid reader and road cyclist.
» More about John
» Read posts by John

Jennifer Payne
Author Profile
Jennifer Payne

Jennifer is the Director of Quality and Efficiency at Pelago. Her blog posts are based largely on her experience working with teams to improve harmony and productivity. Jennifer is a cat person.
» More about Jennifer
» Read posts by Jennifer

Michael Payne
Author Profile
Michael Payne

Michael is a co-founder and product architect at Pelago. His contributions stem from experiences managing the development process behind web sites and web-based applications such as Intervals. Michael drives a 1990 Volkswagen Carat with a rebuilt 2.4 liter engine from GoWesty.
» More about Michael
» Read posts by Michael
Videos, tips & tricks