We’ve come a long way since websites were magnolia coloured pages with Comic Sans or Times New Roman type and the greatest amount of interactivity were the animated gifs and scrolling text. Building a good site might seem a lot more complex now but it’s really quite simple. Here are a few things to bear in mind.
Have an end point.
Building a site, however small, should be treated as a project and projects have a start as well as an end. If you don’t give yourself a target how can you hit it? Most designers, (first use of that word in this post) would tell you how difficult it is to complete their websites, including yours truly, my advice (which I obviously haven’t followed) is treat your site as you would your client’s and if that doesn’t work, you really should question your vocation.
Who do you want to reach?
This question is important and needs to be answered before you start thinking about design and functionality. You’ve probably heard it before and it’s important so no harm in repeating it. If you are trying to reach a demographic your site needs to look and act like it was meant for them; a site for a nursery should look fun and colourful, while a site for prospective customers of a law firm would be less inclined to use colourful figures and have downloadable colouring sheets.
What do you want the site to do?
Er, “everything” is not a feasible option, but “I’m not really sure ” is a good start. You need to know what the site should do so you can use the appropriate design, factor in the right functionality to get the result you’re looking for.
Important stuff out of the way, it’s now time to start the actual process. By now you might have figured out that it would be a great idea to document things and there are a few good reasons for this. Writing out your plan gives you a means of tracking your progress, so you know if you’ve bitten off more than you can chew, or if anyone might need a well placed foot up their nether regions as a gentle reminder. It helps you stick to what you’ve decided and stops you doing that Puss in Boots impression where he starts chasing a spot of light that suddenly appears on the ground instead of taking out the bad guys at the bar. If you’ve ever thought halfway through your web build “I know! We’ll add that funky JQuery banner to the home page” and a week later “love that new metro Windows 8 effect, maybe we’ll do that”, then you’re doing the Puss in Boots. Stop it.
So here’s what you will need:
A brief. This should describe what the site is intended to do, how it will look and how it should function. If you’re putting a large site together this would be required as standard and would most likely be three separate documents; requirements document, design brief and functional specifications document.
Your project plan – we’ve covered this already but I would add that you should make the time you allot for tasks realistic; be generous and if someone else needs to approve the work, factor in even more time for getting that approval. It’s most likely they have other things they do that don’t involve websites, they might have holidays for instance or just get nervous around techies and avoid them whenever they can. Your project plan doesn’t have to be in MSProject or anything fancy you can use a simple checklist in Word or a spreadsheet in Excel if you like.
Aren’t we forgetting something?
I could write a post about this all on its own and maybe I will someday but for now it gets an <h3> tag. Smaller websites often get built by smaller outfits with a designer and developer (often in the same body) for a small business owner who doesn’t do much by way of writing. The result is often a great looking website that doesn’t have much to offer as no one thought to create compelling content, or indeed weren’t able to. Content is probably the most overlooked part of the web building process (second only to user experience) and it makes all that hard work put into the site worthless. Doesn’t matter how good the site looks, if there’s nothing compelling your bounce rate goes up. That’s where you need a good copywriter.
Chances are you’re a freelancer, ‘a one man band’ just starting out or part of a small design outfit, you will need to have the right skills to do the job. You may know a bit about everything but not a lot about more than one thing, if that ‘s the case and the brief gets modified and all of a sudden you need a PHP programmer or a database expert then your beautiful plan might hit the buffers (I was going to put a joke in here about Ruby on Rails but… nah). You should allow for things like this and factor the time and money into your budget, don’t be afraid to do an Oliver Twist if need be.
Oh yeah, don’t forget the copywriter.
Every workman has a different set of these so I’m not going to get all prescriptive on what you should use, I’ll just give you a few ideas.
MS Project is my preferred choice for planning a project if it looks like the job might go on for more than a month and involve people from different departments and organisations. If you’re not a project management professional you might find it intimidating because of all the features and what it can do, but Gantt Charts aside, think of it as a spreadsheet on steroids and all of a sudden it looks less daunting. List all your tasks as you would in a spreadsheet but have the added functionality of when a task starts and ends, who or what will be required to carry it out, what task on the list needs to be completed before another starts and you have yourself a project plan.
Basecamp (www.basecamp.com) is my stand-out favourite tool for managing projects where people involved have different email address endings. It allows you to have group discussions, share documents, create and assign tasks on a to-do list and share calendars with most tasks being carried out using your email without having to log on to the site. As everything is in one place and there’s a search facility, it makes it easier to track down files or discussions made earlier in the project – always a useful thing if one of the project team or sponsors develops selective amnesia.
Balsamiq is a wireframing tool which makes mocking up a website nice and easy (no hair care jokes) allowing you to share your ideas with the group from layout to final look of the site and content. Like other web based wireframing tools you can discuss designs or even allow others to edit your layouts. Other wireframing tools out there are Axure, Mockflow (another favourite of mine) and one that I thought was a positive gem before Adobe pulled the plug on it is Proto which was one of the TouchApps family that worked beautifully on iPad.
This post is not about designing a website, it’s about building one, which is why I made little mention of design software other than that needed for planning the site. This will take more than one person to complete for the website to really be a useful product and I hope it will get people thinking about working collaboratively and not be afraid to seek other professionals out who can add value to your next project.
Hope it works.