- Phase 0
- Phase 1
- Phase 2
- Phase 3
- Phase 4
- Phase 5
- Phase 6
Before getting started, there are a few questions we need to ask. For example, it’s important to understand why this website or application is being built. Is it a new site or a redesign? What kind of feedback has the company received from its audience on its existing site? What are the key issues facing the company at this point in time?
Another important consideration is what the competition is doing. Are they doing something different or winning over customers because of something the client’s company is not doing?
A key ingredient to a successful project is to design for the customers, not for a company itself. The website/application needs to be usable and accessible, and supported by user testing.
We need to remember too that web design is not print design! What works for brochures or print campaigns will not necessarily work on the web. Having said that however, it’s also equally important to maintain a consistent brand across the client’s different media platforms.
Scope defines the expectations of the project. Scope helps to define what is involved in the project, and also helps to define what is not involved.
There are five general questions that can be asked of the client to help identify scope:
- Product – What do you want?
- Quality – How good do you want it to be?
- Time – When do you want it?
- Cost – How much are you willing to pay for it?
- Resources – What resources are you willing/able to bring to the table?
Part of the scope negotiation process is to determine which devices and browsers the client is expecting the website or application to run on. For example, if the client would like a website to be viewable on mobile devices, we need to identify which mobile devices and models are part of the scope (e.g. iPhone 3GS, Android OS, etc.). Likewise, with all the different Internet browsers available, we also need to determine which browsers the site will be optimized for (e.g. IE8+, Firefox 3+, Safari 5+, etc.).
The result of the scope negotiation process is typically a statement of work, or a document describing the work that will be performed by Pop Digital.
1. Statement of work.
Phase 1: Definition
Working with you, the client, Pop Digital will attempt to gather as much information as possible about the company/product/promotion. We will ask you to provide us with any text, graphic assets, logos, videos, etc. that will either go into the final product, or which can help us learn more about your company’s brand and objectives.
If a website already exists, we will put together a site map of the current site and discuss if this structure will be changing. We will also discuss what works with the current site, as well as what doesn’t.
Ah, everyone’s favourite – filling out a questionnaire! We know that answering questionnaires is not the most exciting part of the project, but it’s a vital part of the process, and will save time in the long run. In addition to helping us understand a company’s background, it helps to make sure that we are all on the same page going forward, and ensures that we have a clear picture of your business objectives and intended project outcomes. It helps us measure what you will consider to be a successful project.
View our standard client questionnaire (PDF format).
At Pop Digital we are all about user-centered design. Therefore, who is the target audience for this project? What is the primary age group, gender, ethnicity, financial status, technical knowledge?
It is often useful to document some personas, and/or use-case scenarios.
Setting goals for the project helps us establish success criteria. The most important consideration is why are we building this website or doing this project?
Some common goals for building or redesigning a website:
- Support the current business with a strong online presence. An extension of the brand.
- Building online resources for clients.
- Online sales (e-commerce).
- Increase website traffic.
- Improve purchase conversion.
- Improve usability.
- Add existing functionality or application to website.
Requirements Analysis Document:
Based on all the information that has been gathered up until this point, a Requirements Analysis document can be put together for review by the client. If everything looks in order, we get the client to sign-off on the document.
The Requirements Analysis document is essentially a summary of we have learned so far about the client’s business requirements and objectives. This is a “what” not “how”, meaning we are describing what the finished project will do rather than how it will do it (i.e. we avoid describing technical solutions). If possible we also try to prioritize the requirements.
In addition to the Pop Digital team members, are there any other people that will be contributing to the completion of this project? And the client is, of course, our most important team member!
At this early stage, tasks identify the work to be done from a high level. For example, if we are building a website we know from experience that we will, at the minimum, have the following tasks: i) Gather information about the client and their audience, ii) Create a project plan, iii) Create a sitemap, iv) Create wireframes, v) Create visual design mockups, vi) Create prototypes, vii) Build the website and populate with content, and viii) Test the site. Additional tasks can, and probably will, be added as the project continues.
Here we need to identify the critical milestone dates for the project. Are there any critical launch factors that are date-dependent? Are there project dependencies, perhaps from external sources or contractors, that can potentially affect our timelines?
Part of this step is to break down the project into tasks, assign team members to each task, and estimate how much time is needed to complete it. We also need to identify task-interdependencies (e.g. does a certain task need to be finished before another one can begin?).
Based on the scope of the project established so far, with timelines set up and roles defined, a budget can be defined. Potential additional charges are outlined, such as domain name registration, hosting fees, stock photo purchases, etc.
Project Plan Document:
Components of the Project Plan document:
- Overview: The executive summary.
- Audience. Include the personas/use-case scenarios created previously.
- Testing Plan.
- Details and Assumptions.
1. Requirements analysis document
2. Project plan document
Phase 2: Information Architecture
At Pop Digital we believe that “Content is King”! Even the most beautiful looking site won’t be successful without quality content. Fancy layouts and cutting edge design matter for only the smallest percentage of sites. The rest require compelling content.
Using existing content (text, images, videos, diagrams, etc.) and any additional information provided by the client, we begin to sort our content into logical categories. Do we have enough content or does a writer need to be hired?
Sitemapping (Logical Design):
Based on the information gathered in Phase 1, main content categories usually begin to emerge as natural navigation points. A sitemap document is started, but this will often be an evolving and changing document over the life of the project as sub-pages are added and removed. Ideally though we would like to decide on the main navigation categories based on our content categorization performed in the previous step.
Even microsites and online applications still need a sitemap.
Wireframing (Logical Design):
Wireframing helps us to determine what kind of information will go on our pages/screens, and where the elements will be roughly positioned. From multiple wireframes we can begin to establish flow, and evaluate how our audience will interact and navigate around our site/application. Some wireframing applications allow you to build basic interactivity (e.g. links, window overlays, etc.) into the wireframes to allow for simple prototyping.
Modeling (Logical Design):
If the project requires, here is where we model our data and processes using data-flow diagrams (process modeling), entity-relationship diagrams (database modeling), and/or UML models (for class definitions, activity diagrams, use-case models, etc).
Prototyping (Logical Design):
During this step our front-end developers take the wireframes and data models and begin to turn them into a functioning website/application. We aren’t worried about programming languages, server-side scripting, dynamic content generation, or database integration at this stage – we are simply turning the design into a minimally working prototype to make sure we are on the right track. For websites, we focus on prototyping different page categories, such as the homepage, content page, search page, contact page, etc.
In the prototyping phase we concentrate on the navigation, flows, images, media, etc., and don’t worry about adding any copy (text).
For less complex projects the prototyping can often be implemented concurrently with the wireframing step (3-3) if the wireframing software being used has interactivity features.
Labeling the Site:
A label in the context of information architecture is a word or short phrase that provides an efficient way of describing a topic or action. For example, the label ‘About us’ is often used, in the context of website navigation, as shorthand for “Content that describes the people/organization that owns/operates this website”. A correctly labeled site is key to usability, SEO, and design.
In the context of web communication, labels are used to:
- Describe and navigate content.
- Set expectations or prompt for input.
- Enable interaction, e.g. send, cancel, process, open.
- Provide tone or establish an overall voice.
Phase 3: Design & Technology
Visual design often begins with some experimentation. Here is where we work to identify our colour schemes, graphical layouts, metaphors, and overall style. Sketches, Photoshop mock-ups, and examples of other sites are useful tools for this process.
After an initial design is created it is presented to the client under the assumption that this first pass is preliminary, and suggestions and changes are welcomed. Some questions to answer are:
- Does the design answer the project’s goals and business objectives?
- Does the navigation make sense and is it intuitive?
- Is the layout logical and does the position of the visual elements make sense?
From these suggestions, further design mock-ups can be created. The number of design iterations allowed before additional costs are incurred is agreed to beforehand. The reason for this is that design tends to be subjective, and it’s possible to get stuck in an endless loop of changes and tweaks.
Style Guides and Standards:
After reviewing the prototypes with the client, and integrating any change requests, we can begin to hammer down a style guide for the project. The style guide helps us to be consistent by outlining:
- Filename standards
- Directory standards
- Image standards (jpg, png, gif, transparencies, compression level, max filesize, etc.)
- Colours (HEX #, etc.).
Technical Analysis (Decision Analysis):
After identifying a visual design that the client is happy with, and upon successfully implementing some prototypes, it is time to make a decision on what technology will best support the final product.
The purpose of this stage is to identify candidate technology solutions, analyze those solutions, and recommend a target system for use in the construction and implementation of our project. For example, if one of the business requirements was for the client to be able to update parts of a website themselves, then a Content Management System (CMS) will need to be implemented. In this case, we must decide if a pre-existing framework can be used, such as WordPress or Drupal, or if a completely new, custom CMS needs to be built.
1. Visual mockups
Phase 4: Production and Testing
This is the “get it done” phase. Coders, application developers, designers, and the client all work together to build the final product. The phase begins with a review of the project goals (have they changed?), and project scope (are we on track? Have we had scope creep?).
For websites, a file structure is set based on the wireframes and architecture that was developed in Phase 2. We want to make sure that our architecture is scalable, meaning that the site/application can easily grow if needed.
The individual pages are coded based on the prototypes and templates established in Phase 3, using the technology decided upon in the Technical Analysis stage (4-4). Client-side scripting, server-side scripting, and database integration are developed and implemented. Copy is added to each page/screen.
- From the labels established previously (3-4), ensure the proper use of keywords as the site is being developed. Strive for a keyword density of 3-7% in document text. A density of over 10% can look suspicious to search engines.
- Use keyword synonyms.
- It’s also important to know where the competition ranks in popular search engines for key terms related to the client’s industry.
- Create a sitemap.
- Ensure proper and descriptive page titles and meta tags.
- Build the site using semantic html.
- Use the “title” attribute in all links.
- Specify “alt” tags for images.
- Use header tags (h2, h3, etc.) for prominent content titles.
- Use text links that include keywords that point to pages on the site.
- Build a custom error message page.
- Have quality backlinks.
- Split up longer content. Better rankings can be achieved with 3 shorter pages rather than 1 longer page.
- Avoid invisible text.
- Avoid using frames.
- Use Flash conservatively. Remember that search engine spiders cannot index Flash files.
- Hyphens between words in a URL increase readability and help with SEO rankings.
If the project was to build or redesign a website, there are a number of website optimization techniques to take into account:
- Minimize HTTP requests by combining files, using CSS sprites, and using image maps.
- Use a Content Delivery Network (CDN) where appropriate (e.g. images, scripts, etc.).
- Add an Expires or Cache-Control Header:
- For static components: implement a “Never expire” policy by setting a far future Expires header.
- For dynamic components: use an appropriate Cache-Control header to help the browser with conditional requests.
- Gzip components.
- Put links to stylesheets at the top of the page in the header.
- Avoid CSS expressions.
- Configure ETags. Entity Tags (ETags) are a mechanism that web servers and browsers use to determine whether the component in the browser’s cache matches the one on the origin server.
- Use GET for AJAX requests.
- Minimize the use of iframes.
- Choose <link> over @import.
- Optimize images and CSS sprites.
- Don’t scale images in HTML.
The Quality Assurance (QA) Plan: From our Phase 1 documentation we can determine the most important areas of the site/application, and can build test-case scenarios that are likely for users coming to our site or using our application. We begin by testing at a high level (main navigation, headers, footers, etc.) and gradually work our way to the more granular items.
There are three levels of QA testing that can be implemented:
- Informal QA: We make a checklist of features, tools and pages to make sure that nothing was missed.
- Semi-formal QA: In addition to a checklist, we test our site’s/application’s content, features, and functionality from a user’s point of view. A number of use-case scenarios are defined based on the system requirements (we should already have some of these from Phase 1) and followed. Errors are reported and submitted for correction.
- Formal QA: This level expands on the previous testing levels and adds extended documentation and possibly bug tracking software to the process. Each task and subtask for the project is mapped out and tested, accompanied by notation of expected behaviour and experienced behaviour.
The level of QA testing that we recommend depends on the size and complexity of the project, but we have found that for most projects, informal and/or semi-formal QA testing is sufficient.
1. Completed website or application
2. QA Report
Phase 5: Launch
This step involves handing off the project to the client. The site/application has been tested and is ready for prime-time. A post-mortem meeting with the client is recommended to help evaluate success. Sessions can also be scheduled for CMS and maintenance training. If we have built a website, the site is registered with search engines.
We’ve made it. Very exciting. Our site/application is launched for all to enjoy. Time to celebrate.
Phase 6: Maintaining the Site/Application
Websites and applications are rarely static, and often require periodic updates. In this final stage we develop a maintenance plan.
A maintenance plan typically involves the following:
- Define the maintenance activities.
- Define the support roles and responsibilities.
- Monitor the system for continued performance and perform any necessary system modifications.
- Provide information and training on the procedures necessary for the client to maintain the system.