Design Process, Clients, and Web Standards: An Interview with Jeffrey Zeldman
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Design Process, Clients, and Web Standards: An Interview with Jeffrey Zeldman
Sites full of eye candy have little usefulness. It's become a problem of designing for design's sake to shout, "Look what I can do!" Such designers have created a beast, an eyesore. Like judging a book by its cover, they believe offering awe-inspiring beauty will blind the users to the fact that it's not usable.
Instead of admiration, it provokes responses of "This is taking too long to load" and "How do you use this site?" Clients who request Web design services may fall in the pile of "do something cool" instead of "let's see how we can best meet our customers' needs." This is where it gets thorny as Web designers have to balance politics with advice of focusing on "need" as opposed to "want."
When working with clients, the challenge is to avoid the black hole of creating comp after comp after comp because of "cherry picking," where bits and pieces of every comp are picked for changing and creating a new comp. No one wants to tell a client, "Enough! Just make up your mind," at least, not out loud.
To avoid potential sticky moments, try adding a maximum number of rounds or time spent on iterations to the contract. Taking this approach prepares the client to make solid decisions during the design process. In this interview, Zeldman speaks of how he works with clients to meet their needs while giving design a purpose.
Initial Meetings with the Client
Zeldman indicates he's lucky in that his clients approach Happy Cog, his company, expecting certain things. Because clients know what they stand for, and because they come to them wanting what they do, they're spared the kind of circular dialogs that plague the initial planning phase of many projects. Instead, Happy Cog can focus on the heart of the problem, finding out everything the client knows about his or her existing audience. They ask what makes the client's product or service unique, where the product or service currently lives in its users' minds and in relation to competitive offerings, and where the client hopes to evolve.
Clients don't always have the answer to all these questions, but they understand that these are the right questions, and they're able to work together as creative partners from the very beginning.
Zeldman says, "If you establish your point of view and evolve from that point, you attract clients who want what you have, and you set the stage for projects that develop naturally, from shared goals. If you try to be all things to all people, you become everyone's second or third choice, and you waste time bidding on projects nobody really wants you to win. When you do win, you waste a lot of time coming to terms, because it's not clear what you do."
Assuming clients come to you for reasons other than price or proximity, Web designers spend a lot of time in the initial contact phase learning all they can, and deliver a proposal that's tailored to the client's needs, including some needs of which the client may be unaware. "Boilerplate responses smell like what they are, and have a low success rate. Proposals that include a preliminary needs assessment and a conceptual model of what you hope to achieve are naturally more attractive to client than rehashes of stock proposals," explains Zeldman.
Find the heart of the site, the thing that will solve its business goals and bind it to the hearts of a particular audience, making it essential to them. You need to learn everything the client knows about the product or service, and funnel it through your design expertise.
Staying on Track
Zeldman indicates he has never met a stupid client or anyone who knows less about his product, audience, and competitors than he does. He encourages clients to talk and treats them as full partners. After all, it's their site. When they're not happy and something's wrong, the project won't succeed.
With bigger clients you sometimes have discussions that spring from internal political jockeying rather than the site's needs. And with smaller clients, you sometimes get excited talk that's all over the place, because someone (your agency) is finally listening, and the client can't stop rambling — like a guy who's just fallen in love, and needs to tell his partner every detail of his life story. Useful nuggets can come out of those long rambles, so Zeldman encourages them and listen patiently or at least pretends to listen patiently.
When client and contractor get off track — when the long rambles through the park of the client's mind no longer turn up the occasional gold nugget — it's time to steer back to the client focus. Zeldman suggests doing this by responding only to the few points that merit it, and responding in a few short sentences outlining one plan and an alternative. The client realizes he or she has been heard, and also recognizes that they've reached a stage requiring a decision.
Dealing with Multiple Iterations
Some agencies take three or more designs nearly to completion before asking the client to make a decision. That's a waste of time. It varies by client and project, but Happy Cog's contract indicates they'll show two to three initial designs, and unless they're way off base, they can generally focus on the one that's working best by mutual agreement.
A good place to start is where the client's identity is weak or non-existent. Logo and theme-line: one round of three, discussion, and refinement. More often, it helps to place the logo and theme-line in a visual context. Comp a look–and-feel that includes these and other elements that are needed on the site's front page.
In a perfect world, you've discussed the architecture and know exactly what's needed. Zeldman has found that what you agree to in a storyboard or wireframe may not work right in the context of a designed screen experience. Designers complain about clients changing their minds after agreeing to a site plan. But sometimes the client is right. And designers change our minds, too. Directors change scripts when a film scene isn't playing. The same thing is true of Web design.
"So instead of holding my clients to a paper plan and punishing them financially when they diverge from it, I treat the comp as a learning tool for us as well as the client. Maybe we thought we needed two levels of navigation plus one-click access to specific products or areas. Maybe when we see it in a comp, we realize it's too busy and would only confuse the site's visitors. The client may even bless the work, but if we're not happy, we say so, and come back to them with something that works better," says Zeldman.
Establishing mutual trust and respect up front leads to a more willing client when it comes to changes especially when a designer thinks about the client's changes. Happy Cog spends much up-front time getting to know the client to ensure they'll make compatible partners. Otherwise, if you don't have that level of trust, you shouldn't be doing the job.
If a project has a "hundred iterations" problem, it stems from lack of vision, lack of patience, and a knee-jerk reaction to the client's attempt to solve problems you should be solving yourself. Sometimes inexperienced project managers foment this knee-jerk reaction pattern, spinning the project out of control.
In explaining how he addresses the iterations problem, Zeldman says, "We let the client talk a lot. The client may have a hundred issues with a preliminary or secondary iteration. We listen to all the issues, discuss only those that are relevant, address those concerns only very briefly, and let a little time pass while we think about everything that's been said.
"Later, we re-open the comp and begin changing it, guided equally by aesthetics, general usability issues we've noticed ourselves, and an unconscious memory of the client's chief concerns. We may address the client's problems literally but more likely will simply solve them visually, regardless of what may have been discussed."
Happy Cogs works to show its solutions rather than sell them. As Hillman Curtis says, "Clients understand graphic design. They've been living with it all their lives. When we've finally nailed it to our own satisfaction, we know the client will recognize that it works."
Again, establishing mutual trust and respect at the beginning of a project is the only way that kind of iterative process can work. It helps avoid unnecessarily overwrought deadlines and multi-tiered iterative phases tied to punitive rules that can encourage hostility between client and designer.
A key to a successful project that avoids an out-of-control iterative process is to ensure the contractors work with one key decision-maker at the start of the project. The client may have to answer to a committee, but contractors don't. The process of selecting one contact evades the situation of being obligated to twenty people on the client side, each with a different vision for the site.
In sharing an experience, Zeldman says, "We collaborated on a project with another agency, whose process differed greatly from ours. They made themselves answerable to everyone on the client side. The client's Brand Manager wanted a blown-out, design-intensive look and feel on a site driven by an aging content management system (CMS) incapable of delivering such a product. The client's IT Director sought a simple site her CMS could handle, and was unwilling to even consider upgrading the system, possibly for reasons of budget, possibly because she disliked the Brand Manager."
He continues, "Both clients had equal say. The agency was placed in the unenviable position of creating a design its client could not produce, or presenting work the client could handle but the Brand Manager would never buy. We escaped unharmed, but last I heard, the other agency was still presenting revisions."
Happy Cog avoids this problem by stating clearly in its proposal that it'll work with one client who's ultimately responsible for the site's success. Any potential client who is uncomfortable with this stipulation will choose a different agency, and sometimes you have to let that happen otherwise the project is heading for a train wreck. Answering to committees invites chaotic working relationships with mediocre end-results.
Modular Design Phase (Templating)
It's unavoidable that the design will change during the modular design (templating) phase. Having this in the proposal and contract is a reminder to the client throughout the design and development process, so they're never unpleasantly surprised. Design shops remind them why the design will change: to accommodate the technologies that drive the site, and more importantly, to address unforeseen circumstances and deliver the best possible product.
As the design experts, you know what technologies you'll work with as you've designed comps accordingly, and changes will be minimal and as expected. But naturally, as you move from flat comp to working prototype, there will be changes because the Web is not print.
Something is always missing no matter how carefully the project is planned and how many times site's architecture is discussed. When developing templates, it's inevitable that you discover something is missing, and you need to solve design problems specific to a particular sub-page.
Many agencies deliver Photoshop comps of every sub-page, seeking design approval before going to the prototype phase for that page. In some cases, where the design varies from page to page, that may be the right approach. "But if your design is fairly consistent throughout, the extra comps are a waste of time and money. Just build the templates. Clients like seeing working prototypes. They feel they're getting somewhere, and they're right," explains Zeldman.
Needless to say, long before you get to this stage, particularly when re-designing an existing site, know all about the client's server and platform, and any "kinks" you may be forced to work around. These kinds of things happen, and the client may lack time or budget to facilitate more rational implementations, so know before you go.
Handling "Wrong Direction" Feedback from Clients
Clients who approach Happy Cog know that it'll put forward compatibility across current and future browsers, platforms, and devices ahead of pixel-perfect renderings in buggy, non-compliant, outdated browsers. Despite this, the shop discusses Web standards with the client in advance of any work, includes it in the Proposal, and restates it in the contract.
With general use of 4.0 browsers falling well below 2% at this time, it's easy to make the case for coding with standards or steering away from outdated design techniques. As long as visitors receive all content, it doesn't matter that the site will look better in compliant browsers than it does in old ones. He offers the analogy, a black and white TV can display a movie, but naturally it won't look exactly the same as it does on color sets, or on wide-screen, high-definition TVs, or in the theater.
His company's emphasis on forward compatibility via Web standards doesn't mean that it uses CSS layout in all projects. Often, it takes a transitional approach that looks good in any visual browser, but of course looks better in compliant ones. Many institutional clients are stuck with 4.0 browsers. The client is thinking in terms of long-term viability, and that means designing and building with Web standards. But the IT department is still installing Netscape 4 point whatever on hundreds or thousands of desktops.
Happy Cog's solution may involve using XHTML table layouts, but not crazily nested ones, just basic table layouts. It may include a two-tiered approach to CSS: one style sheet for all CSS-aware browsers even the cheesy ones that get CSS1 wrong, and a more advanced style sheet for newer browsers supporting CSS1 and CSS2. Link to the advanced style sheet via the @import method, effectively hiding it from old browsers that can't handle it.
The New York Public Library's online Style Guide describes the approach, and it's how the NYPL has been able to bridge the gap an installed base of ancient browsers and the goal of long-term viability. "Many of our clients buy into that kind of transitional approach, because it supports legacy browser concerns without mortgaging the future health of the site," he says.
Jeffrey Zeldman Bio:
Jeffrey Zeldman is a New York-based Web designer and Principal of Happy Cog Studios. He's the author of Taking Your Talent to the Web and Designing with Web Standards. Zeldman is the Creative Director of A List Apart, a magazine for people who make Web sites.