Developing a website and building a house aren't really so different.
Both cases start with nothing, yet through the methodical, strategic placement of different materials, and labor, a new even cooler product is created. If a general contractor brought a team of experienced builders, roofers and electricians on site with ample materials and instructed them to just start building, they would likely think him crazy, jump back into their pickups and drive off as fast as possible.
Yet many pre-development teams fall into the temptation of doing just that, often armed with only the equivalent of exterior concept sketches. In small projects this is acceptable or even advisable. There would be no need to draw a blueprint or to map out the electrical for a backyard playhouse. However, buildings such as a new symphony auditorium may undergo years of planning before the first shovel ever hits the dirt.
In the web development world, the shovel breaking ground is the first lines of code being put to a text editor. Experienced IT managers understand that writing code is paramount to nailing in rafters or installing insulation, and in some instances just as immovable as the concrete foundation. 'Measure twice, cut once' is a fundamental wisdom amongst builders and a philosophy also adopted by successful web developers. Going back and changing features or functionality within software is eerily similar to tearing back the plaster because someone forgot to add a pipe to the kitchen sink. You are going to have to replace the plaster, you just made a big mess on the carpet – and it's unlikely that pipe will be installed in the ideal manner.
That's probably enough convincing and metaphors.
Presuming a job is big enough to warrant diligent planning, where does one start?
There are numerous techniques that break the ice.
- User case flows
- Features matrix
- Wire framing
- Composite mockups
- Style guide
While a developer or project manager might loosely follow this order, he or she is really working on all of them at once. It is common to fall back and update one document as a later one illuminates some new thought, idea or most often a requirement. In fact, every recommendation in this article can be done in parallel to some degree.
Let's explore these documents more closely.
Creating an initial user case flow can serve as a great brainstorming session. Start with a single square, usually labeled "Homepage" and from there begin asking, 'Where can the user go from here?' Continue asking that question until satisfied that every page, no matter how inconsequential, has at least been noted on your case flow. A finished user case flow can become a very sophisticated document that identifies not only what pages exist but profiles the types of users and the various paths user types will use. From this user analysis the functionality required to satisfy such usage starts becoming apparent. What becomes crystal clear is the number of distinct pages a project will consist of – a handy thing to know.
This exercise sets us up for creating a soft list of site features, written out in outline format and organized by page. The more minute detail the better, as writing text into a word processor is much less expensive for the team than writing code into a code editor. This is the document both the client and the team should become extremely familiar with. Rather than revising functionality once the site is developed, it's preferable to argue, discuss and modify within this outline. Eventually the goal of project manager and account executive is to freeze this list.
Only two documents in and we have all ready learned a great deal about the project. For an enterprise scaled project, mocking the site up would still be premature. Instead, start simply with wire frames. It is quite literally a basic mockup of every page that contains functionality. Graphic assets, such as a logo, would likely be represented by just a box with the word "LOGO" in it. However, it's dimensions should be to scale with the rest of the page and all graphical elements noted in the same manner. Input fields, links or any page element offering interaction should be expressed. It is important to compare the feature set list with the wire frames and verify that everything from the list has been addressed by these basic illustrations.
Once wire framing is complete we not only see a roadmap beginning to develop, but can derive a list of graphic assets needed based on the previous analysis. A team that has come this far has reached a valuable milestone, creating a technical blueprint of the website. This blueprint can be communicated with the client and discussed in depth, focusing on the feature set. Do you have any additional suggestions for formulating a development strategy? Perhaps other useful types of documentation or any cool team exercises?