In my previous article on the cost of building a web site, I mention that with a larger budget you can afford to hire a professional or a team of professionals to build your web site. But what do these people do? What are the steps involved to produce a web site?
Here I describe some of the most common steps taken to produce a web site. That is not to say that every web site build requires all of these steps. Depending on the project some of these steps may not be necessary. The client may also wish to skip some of the steps in an effort to drive down cost. It’s true that skipping a step will lower the cost, but usually not by much. Because each step lends itself to the next, skipping one step often just adds extra effort to the next. For example, if you were to skip wireframing and get right into designing the mockups, it would most likely take longer to produce the mockups. All the considerations that would have been sorted out in the wireframing would have to be considered while doing the mockups.
Project Brief
First, the project needs to be defined. Sometimes the details are nicely laid out in a project brief document, other times it’s a few scribbles on a dirty napkin. I often receive emails to the tune of, “I’d like to build a web site similar to abcxyz.com ASAP. How much would that cost?” It’s difficult to take these requests seriously. On the flip side, when a designer or agency contacts me, they’ve almost always already helped the client hash out a detailed project brief.
A project brief saves time and money for both parties involved. And anyone can write it. You don’t need to know the technical details. And it doesn’t need to have an executive summary and appendix. A project brief consists of a description of the business, organization, product, or whatever the web site will be about. It details why the web site is being built, the goals it is meant to achieve. It points out similar web sites and basic descriptions of important features (for example, maybe a blog is required).
Depending on the project, sometimes a project brief still isn’t enough detail. If the project involves a lot of programming and some complex workflows, a requirements analysis may also be necessary.
Requirements Analysis
The product of a requirements analysis is a detailed document explaining precisely what needs to be built and how it works. It’s sort of a blue print of the site’s functionality and how users will interact with it. The document may contain “use case” analysis, describing what users with different roles can do in the system. For example, an auction site may allow an Administrator user to cancel any auctions but a Subscriber user can only cancel auctions they create.
Complex web sites (auction sites like eBay or social networking sites like Facebook) are referred to as web applications, or web apps for short. If you’re developing a complex web site or a web app, you should definitely go through the process of defining the requirements. A requirements analysis will help you identify the essential features and discard those not needed (or push them to a later phase of the project). Without this exercise now, you will undoubtedly be wasting time during design and programming working on features you will discover aren’t necessary for launch.
Content Strategy
So you have a bunch of content. That’s good enough, right? Wrong. Someone needs to sort through it and separate the useful stuff from the junk. If you were putting together slides for a presentation, you wouldn’t just throw in everything you have, would you? What if it was a 5-minute presentation? Content needs to be chosen. You need to constantly ask the question, “Why?” Why should this content be presented? This is content strategy.
Information Architecture
It is vital to the user experience that you take the time to organize your content, decide which pages are most important and how each page is related. Done properly, it ensures that users will easily be able to find what you want them to find. The product of this exercise, a graph showing a hierarchy of content and their relationship is called an Information Architecture (IA).
Of course, if the site is small and simple the IA should be quick and easy to do. Large web sites that were built without any forethought of the IA are almost always poorly structured and organized and can be very frustrating to use. Developing an IA shapes the way your web site flows, helps navigation and shows how your users will find content on your site. Many university and college web sites could benefit from a proper IA during their next redesign.
Copywriting
Are you a good speller? Why not write your own copy then, right? No. There are other things to consider when it comes to copy and the web, number one being Search Engine Optimization (SEO). Professional copywriters who specialize in writing for the web have an understanding of SEO practices and will make special efforts to write copy that targets the keywords your intended visitors will be searching for. Search engines love to snack on these keywords, especially when they are titles. Coming up with titles that contain search keywords but are still readable and relevant can be a challenge. If your copy doesn’t contain the right keywords people won’t find your site but if your copy contains too many keywords people won’t read it (and search engines may figure out it’s just a dump of keywords and ignore it). Writing good copy for the web is a bit of a dark art.
Branding
Branding can be complex when you start getting into evoking emotions, brand associations, etc. In its basic form branding involves designing a logo, choosing/developing typography, selecting colours, and coming up with different treatments. Typically you might have a black and white treatment and a colour treatment for your logo. Maybe also a treatment where the logo sits above the company name and one where it sits to the left of the company name. In Canada, we often require different treatments for French and English.
A brand guide document is often a product of branding. It details all of the different treatments and provides a reference document for anyone who works with the brand. This helps maintain consistency across print, television, web and other media.
The large companies and organizations I’ve worked with have always outsourced their branding to an agency who specializes in brand development. When Future Shop rebranded they had a typographer develop a special font just for their brand. Many companies get their branding done with the design of their other print materials before the web site is built, but others do ask for branding with the building of their web site.
If you’re interested in branding, check out Brand New, an excellent critique of brand designs.
Wireframes
Some web designers like to do detailed sketches with paper and pencil. Others like to use thick markers to ensure minimal detail. Others again like to start in a vector drawing program like Visio or Omnigraffle. No matter what the method, wireframes set the structure of pages and how your users will interact with them without the distraction of colours, shadows, and other aesthetic elements.
Currently I use Omnigraffle to trace the layout of pages, header, footer, navigation, sidebars, tables, forms, and other elements. I also describe how users will interact with the pages, for instance what happens when a form is submitted or a button is clicked (see example).
Having a solid set of wireframes to work from not only saves designers and developers time in subsequent phases of the project, it allows them to better focus and produce a product of the best possible quality. Wireframes gets you involved early, allowing you to provide feedback before design and development get started.
Mockups
Usually web designers work in some Adobe product (Photoshop, Illustrator, Fireworks, InDesign, etc) or some other graphic software. They craft an image of each page (or each distinct page template) approximately how it will look in a web browser. These images are often called mockups (though I’ve heard them called comps, screens and designs as well).
There has recently been a small movement of designers who are skipping this step and doing mockups right in the browser with HTML and CSS. The advantage being that you (the client) view the mockup in your web browser of choice and are not aware of any features that a different browser might have. For example, if the client is viewing the page in Internet Explorer 8 they would see square corners, unaware that in Firefox, Chrome, and Safari users see subtle rounded corners on certain elements.
Frontend Development
When we say ‘frontend’, we are really talking about the web browser. It’s the technologies that the web browser uses to display a web page and allow you to interact with it: HTML, CSS, and Javascript. However, a frontend developer also needs to understand semantics, SEO, and accessibility issues. Designers are often frontend developers as well, so your designer may be the one doing this work.
The frontend developer uses the previously produced mockups as a guide for dimensions, colours, typography, etc. When necessary they will “cut” out a piece of the mockup and create an image that will be loaded into the page. For example, a grainy texture that sits behind the content would be cut out of a mockup and saved for use as a background image in the web page.
Sometimes the HTML and CSS is done by one frontend developer and another who is better at programming handles the Javascript coding. The backend developer may actually do the Javascript work.
Backend Development
Also referred to as “coding” or “programming”, backend development involves writing code to handle processing of actions taken by someone using the web site. For example, when you submit a contact form the submission is checked for validity, and if valid, emailed to the site owner. If invalid, an error message is shown. The validating and emailing is done on the backend. Another example of backend development would be writing a new plugin for WordPress or another CMS.
Coding can be quite simple (like the form example above) or very complex and challenging. I recently completed a project that involved development of a recommendation engine (a simpler version of Amazon’s “You may also like…” feature). This involved research and implementation of an algorithm that guesses what you might like based on your previous ratings and other users’ ratings. In addition to a tough implementation, there were performance issues that also had to be resolved. (This type of recommendation algorithm is actually an area of study in Computer Science know as collaborative filtering. There was even a competition called the Netflix Prize awarding $1M to anyone that bested their algorithm by 10%.)
Quality Assurance & Testing
When building the site is done, it is necessary to go through all the components, test them, and fix any bugs that crop up. For example, if the site contains a form, you would submit it empty to see if all the validation works, fill it with non-typical information to see how it handles it, and see if the email message is sent after submission and is properly formatted. If someone finds a bug, they need to submit a bug report describing what is happening, what is supposed to happen, and the steps to take to reproduce the bug.
For a small project, the QA team may just be the client and a designer and/or developer. With larger, more complex projects, the QA team may be a dedicated group whose sole responsibility is to test the site for bugs and report them to the designers and developers.
Documentation
Very few developers will produce documentation unless you explicitly request it. Most developers see documentation as a waste of time because they don’t need it. They already know how everything works. You don’t.
Some developers do not enjoy writing documentation, so they avoid it like the plague. They don’t mention it and may even try to talk you out of it. They may be right however. If you’re developing a small site, just taking notes during a training session would probably be enough documentation. If you’re developing a large, complex web site or web application, documentation is absolutely necessary. Especially if it’s only one developer working on it. (“We need documentation in case you get hit by a bus.”) Unfortunately, of the many times I’ve heard clients express legitimate concern for a lack of documentation, there are very few times that the resources were committed to producing it.
Ideally, get on this right from the beginning. Work documentation into your budget and ensure that it is a project deliverable that you can ask for in the end.
Training
Unless this is a simple site built on a CMS you’re already familiar with, some kind of training is going to be necessary. Generally, training involves walking through the site, exposing you to all the features, and teaching you how to manage it. Many developers use WordPress or some other CMS which has standard features that many people are already familiar with. If they aren’t familiar with the CMS, there’s usually lots of tutorials and help readily available.
