Nowadays a significant number of people surf the Web using tablets or smartphones. Responsive websites have become the standard, not only to provide (...)Read more
Project Brief Story: Start Point to a Perfect Website
Some time ago I began my story about the merits and benefits of a well-briefed project with a dark, quasi-cinematic vision of a poor developer fighting impossible odds when working on an inadequately briefed design. I promise to refrain from such dirty, guilt-inducing tactics today. In fact, I'll go completely the other way and talk about the ideal scenario.
There's more than one way to write a design brief so I'll just base today's post on a review of one of my favourite examples - a project brief format usually delivered to us by one of our regular customers. We've built a lot of websites based on it and it certainly ranks high among the resources we've used.
It might be worth noting that it comes in the form of a single PDF which is a complete and self-contained resource nicely fitting within the sometimes very restrictive confines of most email programs.
Meet the project brief heroes
Now, since I wouldn't be myself just giving you a dry description of what's what, I will compare using this project brief to watching a movie. And what comes first in a movie? Well, it usually is the title followed by the names of the cast. It is a bit like this here as well. The name of the project is most certainly unmissable, but what is directly below is even more important. And these are links to layered files and fonts - the two most needed resources when web development is to commence. Putting them into the PDF like that makes it easier to maintain order as far as all of the assets are concerned. The developer has this single "go to" point for whatever need that might arise. An addition of framework/cms info is also a nice touch that helps to eliminate any potential for doubt in this area.
Heads and tails
So, once we're done with the opening credits, it's time to get the plot going a little bit. In the case of a design project brief, this comes in the form of descriptions for elements that repeat themselves the most over the course of a website - the header and the footer. This order of business lines up nicely with the way the site is built as these two most used elements are the first things the developer becomes interested in. Lack of such preliminary information can delay a project! At the very beginning, a developer cannot move onto styling of any content areas without having the above-mentioned building blocks in place first.
The story arch
This is where the plot thickens. With the background and some preliminary rules set, attention can be directed towards the minute. Each individual page gets a part and is painstakingly detailed. So, all the sliders, blocks and other features take centre stage. We get glimpses into the intimate aspects of every element. So, for example, we learn about that hero image slider and all of its story. We get to know how the images should change, what kind of navigation it should have and every other personal detail of its as yet uncreated life in the web. However, unlike in a Hollywood blockbuster, here all actors get an equal share of the spotlight. Every, even minor, the function gets a piece of prime time, regardless if it takes up half of your laptop's screen or if it's a tiny button at the bottom which hardly anyone will ever click.
The plot twists
Finally, remaining true to my fancy movie analogy, I must mention the unsung heroes of the backend. At the end of a film, you get to see the names of all of the people who contribute to a given picture, down to the most mundane jobs. In the project brief I have in front of my eyes you get to see something like this, too. It's all the backend functions you designers care for despite them not being represented visually on the frontend.
It really helps when you give the developer an insight into what hides behind that beautifully orchestrated graphics and content. Otherwise, some things might not work exactly they way you'd like them to. Potential consequences can be trivial. For example, addition or deletion of a single field in WP backend is unlikely to cause significant delays. But changing a regular post into a Custom Post Type might take the better part of a day, if not longer in extreme cases.
This probably looks like a fair amount of work and I'm sure it is. However, as I mentioned in my previous post, it will be an investment that will return itself in droves. If you provide a well-thought-out script to an award-winning crew (I mean us, Chop-Choppers here – real smooth, ain't I?), you'll be on track to put your future site on the blockbuster list!