As the demand for websites grows, budgets shrink, and ambiguity reigns, the value of a comprehensive digital division within an in-house studio is continually rising. Yet delivering websites comes with its own unique types of challenges, not least of which is how to talk about websites. All too often we've heard a client preemptively abdicate their responsibility for a development project with a cavalier, "I don't understand computers," or the opposite, prescribing a solution without any context, effectively eliminating any opportunity we have to offer expertise.
Neither of these scenarios positions your studio for success. If you accept the willfully ignorant client, you're opening up your studio to complaints should the solution you provide fall short of the business need. If you merely take orders, you're inadvertently accepting responsibility for filling in your own details without being given the background to make sound decisions. If you do this on enough projects, you are guaranteed to run into a deeply dissatisfied customer and a team that's pointing fingers in every direction.
One way to stay out of this situation is to avoid being in it in the first place. With every website engagement, our studio makes a point of taking the time to explain what we need in order to be successful. Fortunately, when considered at a high level, the list of what is needed isn't all that long or hard to understand. Here's what we do broken out by six phases (we'll discuss phases 3-6 in the next two parts):
Phase One: Discovery
At project onset the client is really only responsible for a few things. One is to describe the business need for the website. Your team of digital professionals such as business analysts, user experience designers, and information architects, need to have the methodologies necessary to turn that information into discovery deliverables you can validate with your client. What documents you deliver (such as project briefs, experience briefs, and business requirement documents) from project to project may vary greatly, but the deliverables generated in this phase will govern the scope of the project, describe a vision of success for all the project stakeholders and set your team up for success.
There are some common mistakes that are easy to make while in discovery. Here are a few you'll want to avoid:
Don't allow your client to punt with the excuse that they don't understand this sort of stuff. To help your client, avoid loading up your documents with technical jargon. This sort of detail is better left for functional specifications that only developers read. Your discovery documents need to describe in plain English what you intend to build.
Don't skimp on the business case. Have a rationale for everything you recommend and make sure it maps to a business need. It's okay to debate the value of recommended functionality with your client so long as you can demonstrate how your recommendation helps achieve objectives. Your client may have a better idea or your client may choose to change the vision or objectives slightly. Both of these are fine outcomes, but be sure to revise documentation to reflect any changes.
Don't assume your point of contact has sole ownership of the project. Ask your client if anyone else needs the opportunity to review your discovery documentation. Too often clients assume that their superiors won't be interested at such an early stage and don't understand how discovery affects everything that follows. Tell them a project can spin out of control if the vision is off and how it's important all key stakeholders are aligned on the plan from the start.
Phase Two: Design
Every website has a personality and your client is responsible for telling you the desired personality of their finished project. Think of this in terms of, "Within two seconds of seeing this new site, your visitor will be thinking, what?" Document the answer, and make sure all client stakeholders agree.
From that point forward, use this as a framework for critiquing design. If someone doesn't like a design decision have that person explain how it misses the intent, referring to the design documentation.
There are also some common mistakes that can occur in design phase. Here are some to avoid:
Don't assume you understand the adjectives being used to describe aesthetic objectives. "Engaging" means different things to different people (so essentially, "engaging" is a meaningless descriptor). What we want to do is describe a personality and what the user instantly feels when first seeing the site.
Don't allow your designers to default to personal preference when creating the site. Make your designers present their own work by demonstrating how it meets the documented objectives (at least internally). If designers know they'll need to defend their decisions within this framework they'll make fewer decisions based on personal preference.
Discovery sets up your team for success, defines project scope and establishes roles for all the stakeholders. Design brings the project vision into view, revealing the desired personality. Speaking of these phases in these terms will demystify the website project for everyone. In the next installment, I'll describe some ways to communicate the objectives of the development and quality assurance phases.
