Differing approaches to getting started with a website…

By January 27, 2009Web Development

Most webshops worth their pixels engage in some form of pre-production on all projects. This is the planning phase. Building analogies are often used to describe the value of this stage of a project. ‘Would you break ground on a house without a blueprint?’ And it’s a fair point. Websites are complex collaborations between project managers, graphic designers, information architects, developers, QA specialists, account managers, and, of course, a client. In general, it’s a process requiring systematic diligence on the part of an experienced team. Traditionally, the blueprint consists of a combination of a site map, written specification documents, photoshop files, content (copy, photos, multimedia, etc.) and possibly even UI prototypes. These deliverables form the basis of agreement between the client and the webshop as to what is to be produced. They also provide a comprehensive blueprint that an engineer should be able to follow without a lot of additional input. It’s a time-tested and reliable process that the haphazard ignore at their own peril. Once the client signs off on these documents they form the groundwork for the contract to produce the actual website.

This form of pre-production is not without it’s flaws, however. In general, human beings are not particularly good at predicting the future whether its time-line expectations, design comps or functional prototypes. Marketing assistants are not always good at intuiting their boss’s aesthetic. The type of documents web companies and their engineers desire and assiduously produce–invitingly titled tomes such as ‘Functional Requirements v3.1’, ‘Technical Solution Definition’, ‘Service Level Agreement’–are given a cursory glance by the client and signed with all the careful attention one might afford the ‘Terms of Service’ for their computer’s Operating System. Clients, in general, spend more of their energy responding to the photoshop documents, but these  mock-ups too often overlook important user interface considerations and omit the back-end all together. In addition, they are expensive to produce.

So, while the traditional approach–the “blueprint”–described above gets the job done and trumps the alternative of no plan at all, there are often points of frustration.

  • The client is constantly trying to change the requirements, content and design after the blueprint is finished. ‘Let me get you that change order document,’ is not a happy-making response to this desire.
  • The pre-production process can be time-consuming, expensive, and frustrating to the client. ‘Is my site done yet?’ ‘Well…yeah…we haven’t actually started it, per se.’
  • People don’t read, especially when a document is outside their domain of knowledge. The client may sign off on the functional requirements and then express surprise when they find a precious feature lacking after the fact.
  • Photoshop documents aren’t working models and cannot be tested. Often the graphic designer’s solution is neither practical, functional, or the best from a usability standpoint.

So is there a better way? Sort of. It won’t work for all clients or projects, but we’ve found a dash of agile methodology combined with a good content management system like Drupal offers an interesting alternative. With the client’s participation and active involvement, it’s possible to take an iterative approach to starting a website project. Instead of producing  blueprints, the project manager, information architect and client collaborate on a living breathing Drupal site to build out the information architecture and menus, prototype the content types (these are database objects with specific fields–for example…listings, testimonials, events, people), create sortable views of these content types, add page content and other assets like photos or virtual tours, comment back and forth, enable and test modules, and place persistent elements such as sidebar blocks, ads, etc. in their likely eventual locations. The nice part is that a content management system like Drupal is flexible, decisions can be easily reversed. Time spent on these endeavors results in measurable progress toward the final product. One of the primary differences in this method is that the graphic designer (assuming the basic brand is done) can stand aside for this part of the development. When it comes time for them to create the theme or design for the site, they will have a much more concrete picture to work from and it will be clear where their time and expertise is most needed.

But what about the blueprint, you say, what fool would break ground without one? A CMS, like Drupal, provides enough of a framework for building a site that many critical technology and functionality questions are effectively answered. Think of it as a bleeding-edge, environmentally-friendly, factory-made, stick-built modular home that lowers cost without affecting quality or sophistication.

There are challenges, of course, with this method, and it requires a certain type of client. It takes a client with both faith and imagination who’s willing to proceed on an hourly basis secure in the knowledge that the overall cost of the project will be lower, the timeline will be shorter and, at any moment, the iterative work-in-progress can go live. As the ancient Chinese proverb states, the best kind of marketing is the kind that exists. (Websites, unlike print work, will never be either perfect or done.) The client must also be available and able to make decisions for their organization. The frequency of meetings increases, but the meetings are shorter, informal and more focused. In return for these concessions, the client enjoys the satisfaction of participating in an iterative process that unfolds before their eyes.

At Blue Tent, we believe both methods of pre-production are essential and it comes down to the nature of the client and the project as to which is best suited. If you’re interested in a more iterative, less formal approach to pre-production, call us or do some further reading…

Leave a Reply