Web project planning & preparation; doesn’t matter how you do it, as long as you do
In case you didn’t already know, I’m all about planning. I’m a big planner, regardless of the situation or project. Not in a stifling way, but just so that I know what to expect and what’s coming up over the horizon. My day, my week, my finances, I could be going on vacation and I’d still need to plan it all out. If I’m going on a road trip, I’ll need to strategically plan the loading of the luggage in the trunk, making sure it’s stowed as efficiently as possible, while still being able to reach back and get things if and when necessary. The navigation will have been set days before and double checked, and the car will have had fluid changes and tire pressure checks long before the departure day. If by air, I’ll carefully plan the packing of handheld luggage so that things like passports are easily accessible yet secure and that things like inflight entertainment are also packed in order of what-I-might-want-to-do-first.
Clients are from Earth, designer and developers are from anywhere else
For web/design projects I take part in, it’s absolutely no different. Whether you use everything from UML’s, flowcharts, wireframes, storyboards, persona descriptions and cases, SWOT, functional and technical designs; what it comes down to is doing that 80% that makes the remaining 20% (design and development) much smoother and clearer. And I’ll be honest, it’s not even that I’ll insist on performing this level of preparation to make the project run smoother, or because I’ll understand the client’s/end user’s needs that much better (even though it really does). It’s about covering your ass as a designer and a developer. Because as a designer and developer, you are basically speaking a foreign language when it comes to web design and development projects.
Whereas your client or end user sees mere navigation, text, images and probably dollar signs, you see structure, strategic CTA placement, information enforcing visuals and conversion funnels. And because of this communication’s barrier, it’s important that you and client understand EACH OTHER. You obviously need to understand the client and end-user’s requirements and wishes, but the client also needs to understand why you’re making certain decisions. This way you can backup everything you’ve done, so when your client tells you they insist on having a picture of their cousin’s cute puppy with a speech-bubble saying ‘welcome to my website, tee hee’ you have enough technical information and research to bitch-slap them back to reality (not encouraged).
Along side the communication issue, you have probably long thought about the possible problems, solutions and ideas that this project might and will encounter. The client will probably only think of these things halfway through the project. Back-tracking costs time and money only frustrates both parties and proper preparation prevents this, keeping your client happy and tushy safe.
It doesn’t matter how you prepare that initial 80%
Whether you do a few or all of the above or more doesn’t really matter, as long as you do what’s necessary and helpful for attaining success in your project. You’ll rarely find designers, developers and agencies performing these tasks in exactly the same way, and that’s why it’s great to learn and find out how other people go about the initial stages of their projects.
Concept7 is an example that takes their planning seriously but in a sort of pen-on-paper, old-skool manner, which not only simplifies the process, but keeps it interesting at the same time. For starters, there are no corrupt or lost file issues, or which tool do I use for which diagram. It’s all out in the open and it’s easy to reference and look back at what decisions where made and what solutions where chosen. It also makes for a colorful and inspiring way to work on a project.
Fantasy Interactive shows that even though methods and techniques can be similar, they’re approach is one that is very different from that of Concept7. FI’s choice to go for digital documentation of storyboards, wireframes, and functionality allows for versioning of ideas, documented archiving and not having to worry that someone can’t read your handwriting.
There are some whom might think FI’s approach is more professional than that of Concept7’s, but I think that’s only slightly true when it comes to presenting your findings to the client. I guess it would be difficult to justify a bitch-slap with a felt tip drawn, multi-colored document.