Strategy and Web design: staying on track

As big a question as defining and performing strategy is the matter of designing to it.

Think of strategy as the football. One of the major goals of your design process is to carry the football into the end zone, that being live on the Web. Even if you’ve done a flawless strategy, is your delivery process aligned to carry through on this to the final product? Unless this is part of an established process for your company, the answer to this question is probably no.

The key to the solution is documentation: you need enough and the right kind of this to make sure you’re passing the strategy down the line through each successive phase of design. These documentation stages should act like a stepped waterfall, flowing from one level to the next to ensure nothing falls between on any level. If you started out saying that educating your users was a critical imperative due to your complex offering, you had better be certain that your sitemap shows where this content will live and that your page wireframes highlight the links to “learn more” next to product information.

Leading Web agencies, for the most part, have this down pat, as they have to be process-focused. Among internal organizations, though, there can be a wide range of sophistication in this critical success dependency. Documentation forms need to represent every set of hands on the project and every stage of development through requirements, design and functional build.

Assuming, in either case, that you have established a good documentation trail, does this mean your strategy will automatically be carried through? Nope, there’s still the issue of making certain the strategy is reflected and accounted for at each stage. When we’re given something to respond to, we react to it. When I get a sitemap, wireframe, spec or comp, my first instinct is to read through it and identify things that don’t seem right. This is one important part of document acceptance. But what about things that aren’t there?

It’s much harder to see what isn’t there than to respond to what is. When you lose the strategy’s thread, it’s usually because it dropped off from one stage to the next. Somehow, the imperatives you identified haven’t been carried through. They may also be altered or distorted in such a way that isn’t immediately apparent unless you conduct a strategic review of each document stage. Do this by going back to your strategy, remind yourself what it calls for, and then scrutinize the docs to make sure everything is present and accounted for.

In the harem scarem of development, it’s easy to let something like this slip through the cracks. Even if you catch it, at best you have expanded scope and jeopardized launch date. At worst, it’s too late to change anything and your success metrics performance will reflect the gap.

Remember, it’s easy to solve for almost any strategic imperative during the design process when structure is fluid. Once your structure “dries”, however, it is no longer quite so accommodating and you may find yourself unable to achieve critical functions effectively until the next time around – and who knows when that will be?