Web

Image

Client expectation management must be done at all points along the way in the long webdev process. Content and functionality provide two potential friction points. To head them off, a sitemap needs to be developed based on client input. This is usually part of the wireframing process. The client needs to specify any specific functionality required at the outset, before the sitemap is completed, since some of that functionality may affect how pages are built and linked.

One of the stickiest points in the webdev process, responsible for much client dissatisfaction, is the lack of clear understanding by both parties about how content will be created. Clearly, content basic points should be supplied by the client—the expert in their field—in a form that can be easily used. But the devil is in the details from there on.

To begin with, you must get the client to supply all text, photographs and video in electronic format. If they can’t or don’t know how to do that, have your project manager work with their liaison to find a resource to help them.

To make things clearer for everyone, you’ll need to ascertain and make all parties involved aware of:

Text Content

• Who is supplying the text?
• In what Web-ready format?
• How will it get to your copywriter?

Image & Video Content

• Who is supplying the images?
• In what Web-ready format?
• Will they require any editing?
• If so, who will be responsible for that?

What method or tool do you have to capture and track these assets? 

Image

One difficulty in managing client expectations of a webdev project is not knowing the level of experience, understanding and sophistication the client has around how websites are actually built, and—most importantly—what can realistically be expected from a CMS tool and Internet technology itself.

A specific point of friction may be the fact that it’s prohibitively expensive to create a site that will look the same in all browsers. Most clients are likely not aware of this limitation of browser and display technology.

Aside from simply making them aware of it before development begins, there are a few tactics that can be used to minimize the difference in site appearance from one browser to the next:

• Ensure that the client is aware websites look different than on paper, as well.
• Specify which resolution / screen size the website should be designed to.
• Specify a fixed width or responsive layout.
• Inform the client which browser versions you support.
• Ensure that the client is aware of website font restrictions or recommendations, and web page download considerations.

Image

Now let’s take a look at “hard” costs of a webdev project. These are the most easily controlled and understood pricing concepts. 

• Web Design Costs. These are dependent on how many hours are spent working on a design, and how many times the client asks for changes to it. Take the time up front to explain to the best of your ability all the things that can affect this.  

• Show the client your portfolio. These are the types of sites you build. Do they like them? 

• What do they want? Has the client supplied examples of the sort of site they are looking for? 

• GIGO – Ensure the client knows you can quote for a job only on the information you have available to you at the time. 

• Estimate a cost for the project, based on reviewed client requirements.  

• Valued, but appropriately. Ensure the client knows you are costing the job by hours worked, and remind them that you do have other clients. 

• Keep that “paper trail.” Ask the client to send you an email notifying his acceptance of the project scope and cost. Make sure all your costs are approved before starting a job (remember VAT for overseas clients). 

• Half & Half – Get 50% of total job costs before project start, and the balance on completion.  

Image

Last time, we acknowledged the essential disconnect between the way most folks expect a webdev process to go, and the way it actually ends up going. Here are the components that cause this schism: 

• Waterfall: How purchasing departments do things. In this straightforward, pragmatic worldview (held by most business people), they say, “Here’s what we want. Here’s the budget and the timeline. Make something.” But nearly limitless creative options and shifting priorities over the course of the project upend that approach almost immediately.  

• AGILE: Iterate and optimize. This is how most creative people work. We try one thing, find it doesn’t work as well as we’d like, so we try something else based on what we’ve already learned. It’s probably the least efficient and cost-effective approach, but it’s consistently the one that creates the best results because it gets tested against reality the moment its results exist. 

• Self-Awareness: If you're better at the Agile approach—and most creatives are—you’ll do well working in two-week sprints, then having the client review and request revisions on what you've done. Meanwhile, you’re building the first iteration of what started from the sitemap and wireframe. 

Image

Continuing to look at the “soft” considerations of webdev project pricing, we must acknowledge that most people don’t have the first idea about how a site dev process works: 

• Creative Variables. By their nature, software projects are unique. You can’t receive a creative brief, go away for six months and come back with a good finished product. That's just not how it works. Make sure the client realizes this and is in it for the long haul as an engaged partner in the site development.  

• All engineers are optimists. Site developers are engineers of a sort. They are inclined to say, regardless of what they’re asked, “Oh, yeah. We can knock this out in a few days.” Then suddenly, you can end up with six months of development work based on what gets discovered in those first few days. 

• Essential disconnect. The fact is that there is an essential schism between the way most folks expect the webdev process to go, and the way it actually ends up going. We’ll discuss that in more depth in the next post. 

Image

Because business clients have websites built for them about as often as regular people buy houses, there’s always a learning curve on their part about what to expect in the course of a webdev project. 

Both in terms of what they expect from you, and what is expected of them, you need to establish clarity up front so neither party is left feeling frustrated, deceived or resentful. Because Webdev projects can and usually do range over more significant time periods than most other types of marketing projects, this rule is doubly important.  

The first considerations, of course, revolve around cost. Let’s look first at the “soft” considerations: 

• Quality, price, schedule: Pick two. The client needs to understand that you can be flexible with your work, but they have to be flexible about the time, effort and money it takes to reach their goals. They can be given any two of those three variants, but any two will preclude the third being in their favor. 
• Clear objectives. There’s an unstated assumption that the client knows what they want. But realistically, most people are not good at visualizing something that does not yet exist. The client will think best about this once they have something concrete to start from. 
• Best guess. This reality means that up front, unless the client has agreed to pay for some sample work, you have to say, “Here’s what we think it might be,” when they ask for a price. But be clear that your conjecture is simply an estimate based on the best available information from them. End pricing will depend on what actually gets done, as the client sees the start and then asks for whatever they want. 

Image

There are inherent technical minefields in every site dev project, but you may also have to deal with industry- or company-specific difficulties. These may include (but alas, are not limited to): 

• Wonky Web browsers – It’s nearly impossible to create a site that will appear consistent across all of them  

• Previous web developers, third-party IT people or uncooperative domain name registrars who’ve lost their clients to you, and spitefully cause a difficult transition 

• Clients who believe the website you built on a CMS comes with free lifetime CMS training or telephone support from you. Boundaries (made concrete in the work agreement) are your friends. 

• Clients whose staff, tapped to be their ongoing web maintenance people, are not the least bit tech-savvy. 

• Clients who want you to build them a blog, but don’t want to resource someone to write anything for it. You need to make them aware of this ongoing need. 

• Clients who don’t supply content on time…or at all; then don’t turn around draft reviews in time, but still want the website launched on schedule. 

Though we hope it doesn’t happen this way, all these issues and more are ones you must be prepared to deal with. Be very clear about your policy on these types of issues before the project begins. 

Image

Tie up loose ends by ensuring that your good work will be properly maintained by the client (or your firm, or a contracted IT vendor, as the case may be).

Maintenance & Optimization 

• If the client discovers that part of the site isn’t working, you need to fix it as quickly as possible. Original planning and budgeting needs to provide for this possibility, as well as for some amount of ongoing feature tweaks. 
• One important (yet often overlooked) developer duty is to provide the functionality for a continual feedback loop with your client’s internal back-end users. Be prepared to answer questions such as, “I want to post a video, how do we do that?”
• Consult Website Pulse's best practices to establish your own.

Back-End Management 

• Another critical functionality is allowing new site owners to see all their content and make any necessary changes. 
• This should be planned for when choosing the site CMS, according to the particular needs of the client, and the idiosyncrasies of its staff.
• Try to anticipate these needs when creating training documentation, but don’t view questions outside of that coverage as annoyances. View them as learning situations for creation of the next site documentation, and as opportunities to provide a higher level of billable service.

Image

Once you’re ready to publicly launch the new site, be sure that beforehand, you’ve communicated to clients that, by their nature, websites are never “finished.” Remind them that this is a good thing: It makes a site more sustainable because it grows with their organization; and changes are usually less costly than print and broadcast.

The whole point of a website is that it’s not static, but a living entity. Again, emphasize the positive: Fresh content is bait for web spiders to crawl their sites, potentially bumping their rankings.

Now is the time to pay attention to the myriad tiny development details that will leave the best client impression.

Then it’s the Marketing department’s turn to have done their thing:

• scheduling live or online launch events to tout the new Web presence
• generating and distributing press releases (and posting them on the site's newsroom)
• finding creative ways to tie in the site launch to timely current events

Though launch parties are always fun, they’re not only costly, they’re also bad form in the era of COVID, so use your imagination in creating fresh new approaches to launch announcements.

Image

The Final Countdown
Your initial site go-live will be a “soft launch,” known only to those working on the project. First-round testing was for internal users to give the site a first run-through. But now, developers have seen the site too many times, and fresh eyes are needed. 

Unleash the Gremlins!
Second-round testing is done by those who might actually use the site “in the wild.” You want to unleash the gremlins before the general public has access. As military generals have always known: “No battle plan survives contact with the enemy.” People will find ways to break stuff. Let them do it before it really matters. This is the last stress test before the paying client sees it, and—more importantly—sees potential customers use it.

How To Do It
If you haven't run usability testing before, or you have but found it to be a vague process without actionable outcomes, you need a firm process in place. There are many places to find established processes, but one we recommend is Just In Mind. Just over a year ago, they published their Complete Guide to User Testing, with a dozen chapters of in-depth suggestions to address and set up all facets of usability testing.