By Kevin McGillivray
Every website I make is different, and the process is often informal and improvisational for personal projects. But when I’m working on a site for a client or in a collaborative environment, the process is a bit more consistent and predictable while still remaining flexible. For those curious about a look behind the scenes of how websites get made, here is the typical process.
Especially when working with a client or on a team, it’s important to make sure everyone is on the same page with the purpose, goals, and functional requirements of the site. During this phase the client or team answers a lot of questions to get all initial expecations and ideas out in the open. At the end, everyone has a good understanding of the purpose of the site, and can use that as a guideline for making decisions throughout the whole process.
This phase doesn’t have to be crazy. In an informal setting it doesn’t have to be anything more than “I want to have a portfolio site for my work” or “I want a blog for my bee-keeping hobby.” It’s important not to get stuck on this step and to not spend time making complicated documentation. This phase is complete when everyone feels like they’ve had enough questions answered to move on, keeping in mind that many questions can’t be answered until later on when the site in a rough draft state and experiments can be done to explore uncertain areas.
If this is a paid project, people tend to want to know how much it will cost and how long it will take. There are a lot of different ways to estimate this, which I won’t go into detail on here. One common approach is a basic estimate of how many hours it will take and a cost per hour. A different approach that I like is to estimate how many “sprints” (one to two weeks of work) it will take, and giving a flat rate per sprint.
Now that the information has been gathered and the paperwork is out of the way, it’s time to start giving shape to the site itself. The first step to doing that is to determine how all of the content of the site will be organized. The content itself is determined by the goals of the site, and it’s up to the designer to plan the best way to organize and present that content.
The end result of this step is an organized list of all of the content of the site including a description of the purpose of each page, and a basic interactive outline of the site. This means actual HTML and CSS that you can click through and interact with to see a real, live outline of the site. Seeing and experiencing the real thing in a browser is much better than seeing it only as a list on paper. It gives a much more accurate impression of what the site will actually look and feel like.
During this phase, I expand on the outline from the previous step and work on page layouts and styling for the site. This is done with sketches on paper and designing “in the browser” rather than making mockups in Photoshop or other graphics applications. Again, the idea behind this is that it’s better to see the real thing than a mockup or simulation of the real thing. Feedback is more accurate and helpful, and you only have to build everything once in your text editor rather than twice, in Photoshop and your text editor.
I also add any rough text and other content that has been written for the site so far, so that by the end of this phase there is a complete rough draft of the entire site.
After the rough draft is complete, each section can then be improved in terms of layout, style, functionality, and revising markup and code to make it more maintainable and easy to understand. Iterating means making adjustments, making improvements, and testing out new ideas. The benefit of this approach is that you can easily try something out, and if it doesn’t work, it wasn’t a waste of time and it’s easy to change it back. And if it does work, you discovered a great new design idea to make the site even better. Repeat this process throughout the site, and you end up with a much better result than if you couldn’t easily test out experimental ideas.
Clients love this approach as well because they can see adjustments being made to the site in real time. They don’t have to wait weeks to see progress. They already have a sense of the whole site from the rough draft, and now they can just watch it grow and improve.
Eventually through the iteration process the site will reach a state where all of the main requirements and goals of the project have been met, the design is unique, beautiful, and easy to use, and it’s ready to be made public. At this point, any last minute details are taken care of, I get the server ready for launch, and then I make the site live, a process which depends on how the site was built.
Inevitably there are more changes after a site has been launched, and that’s a good thing. Most websites shouldn’t be a set-it-and-forget-it thing. The iterations phase shouldn’t end just because the site has been launched. Not only do clients tend to have some adjustments they didn’t think of before once they start to actually use it, but a site can always be adjusted and improved in relation to its overall purpose. The focus and purpose of a site can shift over time, and the way people want to use the site can change over time, so the site should grow and shift with the people who use it and the people who create it.
The most important thing to note is that this is an iterative process. In the past, I’ve used a process in which I would completely design two or three site designs before starting to actually build it, and I’ve found that that process doesn’t work very well. It takes too much time, and the end result isn’t as good as it could be because once the designs are finalized there’s less room for experimenting and changing things as you go.
This new approach is more like writing a book or an essay. You start by getting a sense of direction (research). Then you make an outline. Then you get a rough draft down. And then you make improvements and edits from there. The result is a process that is simple and flexible, and one that leads to a much better site design.
Published 14 February 2015
Kevin McGillivray is a teacher and web developer from Wisconsin. He writes about creativity, mindfulness, code, and tea. He tweets and tumbles.