This is the process I typically go through when taking on a new Web project, including the questions I ask in order to produce a comprehensive website brief. Too often projects are doomed at the very start due to poor requirements gathering, causing them to run over-budget and far exceed the proposed time frame. I don’t yet profess to be an expert in managing such projects, but honing this process over the last few years has provided a methodical foundation, which I will continue to fine-tune.
Project Governance
Assuming that you’ve already agreed to take on the Web project (and hence a cost has been agreed), the most important factors to consider when kicking off are:
- The client’s intended go-live date
- Who’s involved in the project?
- Who’s managing the project (on your side and on the client’s)?
- Who’s responsible for sign-off and decision making?
Tip: In my experience, unexpected external factors always occur, causing projects to take longer, so schedule in some slack when designing your project plan. Make sure that the people required on the client’s side (such as for sign-off) are available around major milestones. And don’t forget to include enough time for testing!
Functional Specification
It’s obvious that you shouldn’t spec a site without knowing the purpose of it. This goes hand-in-hand with Information Architecture, but knowing whether the site should integrate particular functionality is vital when considering design and cost. Hopefully you’ll already have a rough idea if a cost has been agreed! This also affects what platform you ultimately propose as some of these functions will be built in, some will be available as plugins, whilst others may have to be developed on a bespoke basis. This is by no means a complete list, but here’s what I’d regard as the most common feature requests in projects I’ve worked on:
- Should the client be able to manage the content via a CMS (Content Management System)?
- Is the site a blog, or have a blog as part of it?
- Are forms required? Can they be hard-coded or should the client be able to create and edit forms?
- Is e-commerce required? Define the scope of this, e.g. simple online payments or a shop with multiple products and a basket?
- Does the site require forum functionality?
- Social network integration (e.g. Twitter feeds, Facebook ‘Like’ buttons, etc.)
- Will adverts be displayed on the site? How will these be managed?
- Membership areas or secure content
- Interactive tools such as Google Maps
- Accessibility features
There are standard levels of accessibility defined by the WCAG (Web Content Accessibility Guidelines) for which you can aim, the latest being WCAG 2.0 A, AA or AAA – see http://www.w3.org/TR/WCAG20/ for more info. Remember that these are just check-lists and that evaluating accessibility accurately can only really be achieved with comprehensive user testing.
Features that could assist accessibility are:
- On-page text resizer (many users aren’t aware of how to change the text-size using their browser’s built-in features)
- Alternate colour schemes for users with visual impairment
- Screen-reader friendly versions (if the core version isn’t)
- Mobile device versions (if the core version isn’t responsive)
Tip: Public sector organisations in the UK have very strict requirements on the level of accessibility required by their websites, and may also need to meet standards set out by bodies such as the RNIB or the Shaw Trust. It’s very common for private sector companies not to have thought about accessibility; hence I always suggest aiming for WCAG 2.0 A or AA. Limitations set out in the additional requirements for level AAA are impractical for entire websites – see http://www.w3.org/TR/WCAG20/#conformance-reqs. Note however that WCAG 2.0 AA is fairly limiting regarding colour contrast, so offering alternative high-contrast colour schemes might be worthwhile – see 1.4.3 Contrast (Minimum).
Information Architecture
Content drives design – so considering Information Architecture at an early stage is integral to the design and development of a website.
Asking the following questions will assist in defining Information Architecture deliverables, such as wireframes, process flows, content strategy and Site Maps:
- What’s the organisation’s background?
- What are its goals?
- Who are its competitors?
- How does it want to be seen? What are its values?
- What is the site’s target audience?
- What are the site’s main objectives?
And if there’s an existing site:
- What reasons are there for wanting to redevelop the site?
- What visitors does it currently attract?
- What does it do well?
- What does it do badly?
Wireframes are great because they allow you to focus on how components are positioned on a page, removing the distraction of site aesthetic. These should ultimately define a composition for each page, although this doesn’t mean that tweaks can’t be made at the visual design stage. Process flows are useful when proposing how a user might get to a particular page or use a piece of functionality – these could be visualised in a flow diagram, or a storyboard of low-def wireframes. Site Maps could be simply proposed in a spreadsheet format (I find this preferable as clients can easily make changes), or in a more visually impressive schematic.
Tip: There’s a lot of debate as to whether wireframes and process flows are a valued part of the process; I think it depends on the project and its scale. Small Web projects, with only a few pages and a tight deadline, may not benefit significantly from this step.
Site Aesthetic
Now we can start to talk about the client’s requirements for the site’s aesthetic, which will no doubt be the bit they’re most excited about. This will assist you to put together visual concepts based on the agreed wireframe layouts. Through asking the client various questions, you ultimately need to establish the following:
- Communication – How should the site’s message be portrayed? How should the design make a visitor feel?
- Style – What should be the overall look-and-feel and art direction?
- Colour – How will the site make use of a particular colour scheme?
These items may already be partly defined by the organisation’s brand. Make sure you get hold of hi-res logos and brand guidelines (if they exist), which should include colour palettes, typefaces and guidelines on use of graphical imagery and photography. Any other marketing collateral that may assist in portraying how the brand should be applied online is useful.
Also ask:
- Which websites does the client like the look of?
- Which websites successfully carry a message similar to the client’s?
If the client struggles here, you could try pointing the client in the direction of design showcase sites such as www.bestwebgallery.com and ask them to highlight a handful of sites they like the look of, whether it be in terms of communication, style or colour.
Tip: It’s up to you how you format your questions in order to get the most out of this consultation, but ask the client to provide adjectives (such as corporate, modern, innovative, professional, approachable and friendly) to support their ideas. These should be in line with their organisation’s values and it’s up to you to derive more design-related adjectives in order to visualise their ideas e.g. bright, dark, clean, curvy, square, sketchy, bold, minimalist and so on.
Summary
Systematically going through this process should help you to get a comprehensive design brief, hence greatly influencing the success of your project. In my experience it’s preferential to consult with the client in person, but you could also ask the client to complete a questionnaire to supplement your discussions. However, it’s important to get a good balance between asking enough relevant questions and boring the client with pointless ones.
