Later this week, I’ll be presenting at Wordcamp in New York on the documents and processes that can help ensure your web development project runs smoothly and produces your desired results.
As I’ve prepared I’ve realized that as important as the process is, that process will only be as good as the thinking that goes into it. In other words, garbage in, garbage out.
That old programmer’s saying is apt for non-geeks, too. Certainly, it’s important to put basic planning documents, like these, into place.
- Strategy Brief
- Site Map
- Functional Specification
- Design Brief
You must also pay attention to the content of these documents you produce and the goals you have for the site. Let’s take a look at each document to see what I mean.
This is perhaps the document most focused on results rather than process. When well written, it should make clear to all involved in the process, what the desired results are and how you plan on achieving them.
Importantly, it should lay out reasoning and the thinking behind the goals you’ve set so that your team can expand on the brief, fill in the inevitable gaps, and create not only planning documents that support your goals, but a finished website.
The site map seems quite straightforward, whether you’re thinking about it for process purposes or outcomes. From an outcomes standpoint, it’s important that we are building our site from the perspective of our prospects. Throw out your org chart and resist thinking about the site in the way you think about your products and services internally. Create “content hubs” and other tools that gather all of the information on a topic or service that is likely to interest a prospect.
Your wireframes are a page-by-page guide to the elements that are present throughout the site and how your audience interacts with those elements. You’ll likely also find some references to the functionality underlying all content elements. (That information will be expanded upon in the functional specification.)
You’ll want to be sure that your wireframes remain as non-visual as possible. A tall order, of course. Impossible, actually. But keeping things simple visually will help you keep the focus on what needs to be on the page, and not what it should look like. That’s a separate step in the process.
Simple line drawings and black and white or grayscale schematics typically work best.
As mentioned above, the functional spec takes your wireframes one step further, fully outlining how your audience can interact with the website, how your administrative team can edit and update the site, and what the site coding will do for you automatically.
How simple or complex your functional spec is will, not surprisingly, depend on how simple or complex your site is. Regardless of complexity, your goal is to define in as much detail as possible the features and functionality of the site. Answer the questions here and you won’t have the time and expense of answering them after designs and coding are already in place.
Speaking of design, your design brief is an important part of the process. It gives your graphics team the direction they need to create visuals that support your message and that are likely to resonate with your audience. It can include branding guidelines if those are already in place, but it should not be a brand book.
Don’t forget about content! I haven’t included a content map above, but we do talk a lot about content during a typical discovery and planning process. Ignoring content until the end – “we can always populate content right before launch, right?” – almost always means there is not enough content to populate some areas of the site and too much to fit in others. This is again an area that is cheaper to address in advance.
(If you’d like to learn more about the planning process we use at Andigo and how to adapt it to your own needs, join me at Wordcamp in NYC where I’ll be presenting on this topic. And if you won’t be in NYC on September 15th, contact me and I’ll send you a link to a recording of the presentation.)