COM271, week 10

The Business of Web Design / Redesign

Syllabus | Table of Pages | Assignments | References and Useful Links

Being a web developer isn't all about knowing HTML, CSS, JavaScript, or server-side scripting and database languages (COM372). It also requires a sense of design and clarity about business. After all, the web is a form of writing, and writing means nothing if we do not focus on readers and purposes. A good web developer constantly focuses on target audiences (the users who come to our site) and the purpose of the site once users visit. That is, does the site exist to inform users, sell to them, attract them to our position, etc.? We must be very clear on both audience and purpose—and the clients for whom we work must be equally clear (and in mutual agreement)—before we begin to write a single line of code.

Web development is also about gainful employment. Here, business sense includes learning how to deal with a client (getting them to also think about audience and purpose). A developer also needs to know how to schedule the time (and in business, time is money) needed to get work done.

All projects that you do for any client should follow a few minimal steps. That is, each project should include planning documents, written before the project gets underway, as part of the normal operations of a web development business.

The material here includes a few exercises garnered from Web ReDesign: Workflow That Works, by Kelly Goto and Emily Cotler (Peachpit Press. 2nd edition. 2004. 296 p.)

What follows is a simplified version, using only 4 of the many helpful planning documents suggested by Goto and Cotler. I have found these to be useful in communicating with a new client; I wouldn't undertake a project without working through at least this much process. The scope here is for a small project that you take on as an individual. Such projects take 4-10 weeks or so for one person, working many hours, to complete.

Before you start work on a new project, including projects where your main focus is redesigning an old site—before you write a single line of code—you will do a lot of work. In some cases, this work will go nowhere, and you will get paid nothing because you and your client will not come to terms suitable to begin working under a paid contract. This is a normal part and cost of doing business. Accept it. (And never agree to do any work, except for friends or lovers, without a contract). But if you engage a client with a focus on the business needs (and in this I include sites for academia and social networking, etc.) and work to create a clear set of documents outlining the project in some initial detail, you will have a better chance of being hired and of completing the project to the client's satisfaction and for a reasonable financial return for your efforts. Consider these steps to be, then, the minimum that you would do for any web project in which you engage as the professional web developer.

I strongly urge you to obtain a copy of Goto and Cotler's Web ReDesign. The second edition lists for $44, but Amazon sells it for $0.01 (+$3.99 shipping) used. The book is supported by a website, www.web-redesign.com/, from which you can read more and from which I downloaded these documents:

• The Client Survey (pdf)
• Communication Brief Worksheet (pdf)
• Budget Time Tracker (excel)
• Budget Estimate by Task (pdf)

I suggest that you download copies of these and assume that you have them in front of you for the following discussion.

Getting to know your client, and getting your client to focus on target audience and purpose for the web development work.

The Client Survey: In developing a working relation with a client, you need a conversation about the client's business, understanding of needs, and expectations. The client also needs to get a sense of how you do business. It is a time to begin building trust and a working relation. It takes time. The process is a necessary investment and perhaps the most critical part of a web business. The investment does not always lead to being hired. Sometimes, the client decides against going ahead; sometimes, you make that decision. Negotation is vital, in love and business; shortchanging the getting-to-know you phase is a recipe for potential disaster down the road.

The client survey is a guide for thinking about several questions. It is up to you whether you actually ask someone to write out answers to its many questions, or whether you gather information through a meeting and verbal exchanges. The important thing is to give due consideration to gathering of critical information.

• General Information: I suggest that you attempt to narrow the contacts you will make with a client as much as possible. In identifying (General Information) primary contacts, I'd try to get one person named as contact person. You do not want to have to answer to several people or to a committee, putting yourself in the frustrating middle of internal wrangling. The client is going to direct things; you are going to produce. You need a single set of directions, and the client should work internally to make those clear and consistent. Be certain to get the name, email, phone, etc. of this person. Also, know from the start what the intended budget for this project is. Some clients will have no idea how much time (money) it takes to develop a site. You are going to make this clear, and explain why, but know from the start whether the client is realistic in matching funds to wants.
• Current Site: If you are redesigning, be clear what it is that the client likes and dislikes about the current site. Do they know of a competitor or other site that is "better," and what is it that enforms their concept of "better"? Some clients may have a great deal invested in branding (closets full of company stationary with the founder's original brand mark) and colors and icons may need to be carried forward.
• Reasons for Redesign: The client has signaled that they want some work done, so they are aware of a need. Try to understand the basis of this need, and use this discussion to orient the client toward meeting the needs of the sites target audience.
• Target Audience: You must be certain that both you and the client are mindful of the users of the site, and that you agree on the primary purpose for the site. That is, work until you agree on characteristics of the site user, what you believe they know, why they are coming to the site, and how they will be different as a result of visiting the site (e.g., likelihood to make a purchase, probability of being persuaded to accept an idea/candidate, etc.). Are you selling, orienting, informing? What is it that you want the target audience to do?
• Perception: Users get information not only from the words and images on a site, but also from the way it looks and works. What perception do you want users to come away with as a result of visiting the site?
• Content: Where will the words and images on the site come from? Will you use old text and images? Who will write, shoot pictures, do the art or photoshop production. (If you will do these things, do you have the equipment? Have you included these services in your budget?
• Technology: Where will the site be hosted (existing ISP)? What are the needs from the host (database, server technology, email capacity, etc.)?

Here is a working example of a client survey, drawn up as I worked with the A&S Dean's Office on redesign of the College website in 2005 (MSWord document).

Getting on the same page (literally) with a project concept.

The Communication Brief Worksheet (a.k.a. in edition 1 of ReDesign as "Creative Brief") can be thought of as "the page" you and your client are both on. This is a single page summary of the purpose of the site, a clear and concise statement of the target audience and purpose, etc. Here, emphasis should be balanced between being concise (1 page!) and clear. Use non-technical language (no web-ese), focusing on the user and client business.

Here is a working example of a creative brief, one I wrote before agreeing (5 years ago) to serve as the interim (hint: remember to set an end date for your contracts!) college webmaster (MSWord document).

Coming to terms with your client about the scope and schedule for work to be performed

Your client needs to be clear about two matters of logistics: Just when will you be working (and what will you be doing) and exactly how much work will be done in the end.

Schedule: Your client does not need a day-to-day breakdown of your work. You will, of course, keep detailed accounting records adequate to justify hourly charges for component services, but as you plan a job your most important task is to make it clear at the beginning that the client should have realistic ideas of what they will see as the project develops. Most clients, for example, have no idea that so much time and work goes into thinking and planning before any code actually gets written. Perhaps a third of a project schedule involves up-front work before even a single line of code is written; during this time, the client should understand that there is not going to be anything tangible to indicate progress!

As work gets underway, you will be setting up basic page structures and navigation, often using "dummy" pages as placeholders for words and images that come later. Even as content gets assembled (the writer and photographer and graphic artists must have time to produce), you will still have pages that lack the full impact of your elegant CSS magic; visuals will be one of the final steps, in the last weeks or days of most projects. Your client has to be prepared for these typical production schedules, lest they unnecessarily begin to believe that you aren't doing anything!

An overview schedule is an effective way to alert your client about what to expect and when. Goto and Cotler illustrate this with a 10 week project, divided in to 5 blocks of 10 weeks, with a column describing what is going on and a column for deliverables. What follows is a greatly simplified version:

The client should be presented a version of the simplified production schedule. This should make clear when visible deliverables such as a beta site and visual design will occur. It should also clarify when you expect to be paid, for what, and how much!

Details and Assumptions: Before you sit with the client to sign a contract, you must also present a detailed list of just what it is you are producing. This is intended to make clear to the client that you have a fixed amount of product to deliver, and a planned schedule. This is essential to avoid the primary pitfall of the web production business, scope creep, under which the client feels free to alter the schedule or the amount of work of the project. A Details and Assumptions specifies things like

• number of pages the site will contain
• the time when the site will be launched
• the burden of producing site content (text, images) in usuable format and on time belong to the client and are not part of the contract
• additions to the original scope of the project are subject to additional costs

The outline presented here is less than the planning process suggested by Goto and Cotler, and for real-world projects, again I urge students to acquire and study this or other books on web design workflow (there are other products out there, but I feel safe in suggesting that this is a good starting guide).

A project proposal at minimum consists of a letter to provide a project overview, a Schedule of Deliverables, a Budget, the creative brief, analysis of the target audience and audience technical capabilities) (from the client survey) and a statement of Details and Assumptions. Documentation should also be clear about followup maintenance and issues such as training of personnel who may be involved in managing the site in the future (adding images, writing fresh text), if any.

This sketch is intended to get students thinking about how to plan and present individual project proposals. Again, it is minimalist, and in most real projects the scope and complexity of producing a site may well mandate more elaborate and detailed organizational devices. Again, Goto and Cotler provide a very adquate starting point for such training.