Pre-production is the phase where the blueprints for the site are developed. Heavy in documentation, it seeks to define
the structural foundation for the site in suffient detail to make the work of visual designers easier.
Note: this is an incredibly wide ranging subject. As such, the descriptions below are simplified and used to
illustrate the steps involved and provide a starting point for further exploration.
- Functional Requirements
The web site must do certain things to support the business objectives. The functional requirements document defines the feature set of the site and the requested behavior of each feature. More detail
will be required depending on the complexitiy of the problem. Examples are:
- Customization and personalization functions
- Ecommerce and other transactional functions
- Security functions
- Login & Registration etc.
Each requirement will be explored in full in the next phase as it's applied to real working scenarios to develop use cases.
- Scenario and Use Case Development
As a precursor to the interaction design stage, scenarios and use cases for all functional and complex
elements of the site should be described, a task often performed by a Business Analyst. Detailed
accounts of each scenario of use should be created, documenting all desired paths for the users of the system.
These can be rigid step by step process lists or more documentary style scenarios that tell the story of how
the site's functionality will perform and react to use and misuse.
- Content Requirements
It's important to specify all of the types of content the site will provide/use. For each type of content, a matrix entry can be produced describing:
- What is the purpose of the content?
- Does it already exist? And in what format? (web copy, Word, Excel, PDF, printed brochure)
- Who owns it?
- Who maintains it?
- Who is the audience for the content?
- How often is it updated?
- Is the content dynamic or static? Time dependent?
- Is the site multilingual? How is it translated?
The output from the content requirements gathering process will be a content stategy document (see sidebar).
- Information Architecture & Site Structure Diagram
This phase is concerned with defining the structure of a website. What goes into the navigation? How are the sections
of the site named? Which page does it take you to? Answers to these questions will help create a fully fleshed out
map of the site.
Later when the page level wireframes are developed and templates have been identified, they can be marked (color-coded) on the global site structure
diagram to help show from a birds eye view, where the content and structural commonalities lie.
- Interaction Design & User Flow
Interaction Design is concerned with defining the behaviour of your product (application or website) and how a user will interact with it in
the context of natural use. This interaction with your product will be governed by the motivations and desires of your users. As such, it's
important to not only get the strict physics of the interaction correct, but to be able to establish a higher level of communication via emotion
and experience. It's rare to be able to define a product that doesn't have an attributable and important experience; whether this experience is to be
one of clinical businesslike confidence as in a banking application, or the shock value emotional resonance obtained by visiting the home of a rock band.
At the end of the day, interaction design should be guided by a singular vision and purpose - to make the lives of the visitor (albeit a brief partition of their life)
better during their time spent with you.
To imagine that customers will spend the time on your site or with your online product, for long enough to "understand you" and appreciate your value is to be increasingly naive
given the impatience of today's societal traits. This makes it more critical than ever to establish a tone, purpose and ultimately an experience during every step taken on your property.
To achieve this, I like to mix interaction, emotional and experience design together to create reaction design: that is, first define the reaction you want to the experience you are
designing and work backwards from there.
- Wireframe Development (Page Level Schematics & Template Identification)
Wireframes define the physical structure and content layout of a web page. They take the navigation design from the Information Architecture phase, the content requirements and interaction guidelines
and form them into a template. Information design and storytelling are oft-ignored yet critical elements of this process, helping to shape what can be a fairly sterile series of boxes designed to fit
everything onto the page, into a layout that inspires readability and exploration. Take care to position elements of a page according to some basic principles:
- Hierarchy and flow of information - what order do you want to incur participation
- Areas of primary focus - what's the singlular focus of the page
- Secondary elements - the supporting cast, what else do they need to know
- Primary calls to action - desired next step
- Standard placement of global elements
- Positive transition routes - lateral exploration and relatedness via tagging and associations
The content model defined earlier will help to define the core elements that will comprise your site, and should be carefully adhered to to ensure consistency. This helps to reduce
development time and the effort required for management of content. After several iterations, you should be able to define a series of templates that collectively describe the site.
The most felixible systems encourage the use of a set of high-level layouts that encompass a library of content components positioned in a variety of ways to achieve the goals of each page.
- High Level Visual Design
This should be an exercise in communicating visual direction, while showing the intended structure based on the wireframes. The goal here is to have something visual
that can be rpesented to stakeholders for sign off on the direction. Only a selection of the more important templates should be considered and designers ned to be cogniscent of not delving too deeply into
the finer details (the 20% that takes 80% of the time and effort).
There will always be revisions and change requests at this stage, so the focus should be on delivering something that's good
enough to show "where we're going with this". Often at this point, you will need to provide more than one direction to allow stakeholders to have a point of balance for their commentary.
Just showing up with one direction can cause an awkward "love or hate" scenario where you are essentially betting on red at a roulette table. To give yourself the best chance of success, provide options
that allow the client to chose the direction they like best, rather than a devastating decalration of failure should your sole option not be on target.
|
Deliverables & Documentation
Meetings, Check-In's
& Sign Off
|
