A step-by-step guide to creating a great website

It’s a six-step process that will get all your ducks in a row and help you reduce risks and optimize your website so that it works for you. Not all the things below might be relevant to what you want to achieve, a simple portfolio site will not need all the steps; it’s up to you to decide what you feel is relevant.

The Research, The Sketch, The Design, The Content, The Development, and the Fine-tune.

The Research. 

A great place to start is creating a BRD document – a business requirements document. This is a document and could be just a few sentences that lay down exactly what you want to achieve with your website. It explains clearly the scope of what you want. Unless you are a hard-core hobbyist who is just playing around, most people are creating a website for a reason. Whether it’s to sell a product, connect members of a club, express your opinions in a blog or show a portfolio of work, there is a reason for all that hard work. In the trade, it’s called a ROI – a return on investment. If you invest $1000 in developing a website to sell your product, you want to make $1000 of that back in sales just to break even. Using a BRD to keep your focus on your ROI is a useful tool as it keeps you on the right track. And it’s very easy to lose focus when developing a site. Even the most jaded web designer or developer will often be tempted to add stuff (especially if they are charging by the hour) that may not be necessary to your end goal. This is called scope creep. The scope is detailed in the BRD; the creep is adding that cool video-editing chat function that nobody will use but will add $500 to the final bill. Also, other people might suddenly “remember” that they also need something else to be added after the development and design have started, adding tension among the team and extra costs. Get everybody to agree to the BRD at the start of the project. The people involved in the project (and if it’s for small businesses and larger ones, there will be more than one stakeholder) should all “sign off” on the BRD before anything else.

Have you done any previous research that could be useful, even research you did for other sites?

If you have an old site, can you get any statistics – sometimes called metrics – that show what users do on your site, how long they stay, and what they don’t do. As an example, I once had a site for a large company, and the cafeteria’s menu was on one of the pages. It was a pain to get the daily menu up, so I decided to drop the page, but before that, I did my due diligence and looked at the statistics. To my surprise, over 90% of the visitors came to the site just for the menu. The menu page was a major “landing page” – the page where people enter my site. Using this, I changed the menu page to include links to other parts of the site, and that increased traffic to the rest of the site. I changed from deleting a page to spending more time on it through due diligence. See the SEO section in this book.

Look at trends to see what is new in the market. Look at the competition, are they doing something cool, better and interesting? Or better yet, are they doing something wrong that you can learn from? Don’t be tempted to add stuff unless you are sure it will give you a good ROI, and resist the temptation to use unproven technology. New technology needs to be – well – tested. And often, it is so new that the majority of users are unfamiliar with it and will tend to leave it unused, no matter how cool it is.

The Sketch

Great – BRD in hand, the stakeholders are on board, and you should be able to start wire-framing. Wire-framing is a way of sketching out the website without getting bogged down in very expensive designs and coding. It’s often done on paper and is only meant as a brainstorming tool. Often no images are used (which can be a distraction) but simply blocks of gray to represent text and crossed boxes that represent images. At this stage, you can get a great idea about how big your website will be and what content is needed. There are great software tools available that not only simulate the sketched look but come with different templates and can be saved as code as a kickstart for the developer. 

The more you get down in this stage, the less heartache and expense you have at a later date. You may even want to do this exploratory stage without the designers and developers on board yet. They don’t know your business as well as you do, and may “muddy the waters” with their suggestions. It may be useful to get the designers in before the wireframes are finalized for their input, but this is dependent on many factors and is a judgment call. However, do get all the stakeholders in at some stage before you start making any decisions that will later have to be re-examined or changed. Change is bad, it’s costly, confusing, and can cause you to drift away from the essence of the BRD you worked so hard to get put down. 

Here I want to introduce the concept of due diligence. Due diligence is when you have an assumption that something is great for your new site (or not going to work), but you test it out anyway. You can overdo it, but testing an assumption is always a healthy way to eliminate risk. I have always been amazed by the kind of insights I have gotten from due diligence, either proving myself wrong, confirming that I was right, or making a discovery that helped me adjust or adapt the final website. An example could be as simple as showing the wireframes to some family or friends and asking for comments.

One person you need to check the wireframes with is the User Experience (UX) guy. This guy (and for a small site, it could be you) will check the wireframes against the UX mantra.
Is it SSCC, that is – Simple, Structured, Clear, and Consistent?

Your UX guy will look at:

Simple – 

Can I find my way around this site without being lost, and does it make sense? 

Is the information architecture (IA) logical and easy to follow? The IA needs to be tested (don’t go overboard here, just get 4 or 5 people to walk through the wireframes and see what they say (see the section on user testing).

Structured – 

Are there sections that include other sections that should logically have their own menu? 

Are some items given more importance only because the Sales guy makes more noise at meetings than the Help Desk guy?

Clear –
I once had a meeting that lasted two hours with twenty people while they discussed whether a menu label should be “library” or “archive.” Of course, this is ridiculous, but attention to detail is important, and clarity is a rule of thumb in web design.
People skim text, so ambiguity is your worst enemy. Avoid double negatives – “Are you not going to do this? YES – NO”. At the wireframing stage, this should only be about the labels and menu structures, but this is also important in the content that gets put into the website at a later date.

Consistent – An example is the labeling: if one menu item is called “Women’s apparel,” why is it called “Ladies clothing” elsewhere? Also, if the design changes in different parts of the site –how does this affect the branding and the perception that the user is still on the same site? Remember, people scan and skim web pages. The average time a user scopes a page is less than 2 seconds. They make their judgment and click away.

Great! – Now you have your BRD AND your basic wireframes in hand. You have done some due diligence and some user testing. Stakeholders have signed off, and the third party people (freelance designers, programmers, etc.) can give their estimates for the work. If there is no scope creep, you can budget accordingly. 

Basically, you have listened to the stakeholders, and you have aggregated all the information. For example, if this new site is replacing an old site, what was wrong with the old site (and what was good). You analyzed the information and, without making assumptions, developed a BRD and made a good first attempt at a website structure in wire-frames.

This is also a good time to do some user testing. Just show five people, who have no prior knowledge of you site, the wire-frames and ask for their feedback. Anything turns up; you have caught it before the expensive part begins.

Done? Now you should be able to move to the next stage. 

The Design

You have already started this process by doing your research and setting this out in wireframes. But now this gets serious. And fun! 

Something to be aware of is branding – does your website conform to the style of the business, club or organization it’s representing? This may not be relevant for a small hobby site, but a business should pay attention to this. Designers love to design, so they may be tempted to stray away from that expensive branding that took so long to get past the marketing department. 

A great tool in keeping a website consistent is to use the colors of your branding (often stated clearly in the branding style guide). A site that focuses on a few colors, and uses these in user interface elements (such as buttons, hyperlinks, borders, and lines), gives a professional and consistent look to the whole site.

A designer will take your BRD and your rough wireframes and start designing. It is helpful for the designer to have some content to play with, so he can get an idea about what will be the main meat and potatoes of the site. As a designer, I often made three designs for my clients – a wild one, an average one, and a conservative one. This always worked very well as it created a discussion that either resulted in one being picked, or there was enough material to inform a second iteration that was the crowd-pleaser. Clients often don’t know what they want, but they always know what they don’t want.  Giving too many choices can be dangerous. By giving these three designs within those parameters, I have always managed to present a design that was accepted. 

Here are five essentials in the design stage that you should be aware of:

Avoid the wow factor. This was prevalent in the early stages of the Internet when everybody wanted to impress, but in the end, the wow factor delivered no ROI and, in fact, usually got in the way. No flashy intro pages, no complex animations, don’t overload content. Keep it SSCC.

Design is subjective. Some people like orange, and some people hate it. Don’t ask everybody’s opinion about the design because you will get everybody’s opinion about the design. It’s OK if some people don’t like it. It happens to all the sites. If somebody is vocal about their dislike of the design, that’s fine. Ask them to evaluate why the design is not good objectively. If it’s because they think the colors clash and affect the readability, you can work with that. If they “Just don’t like it”, that’s tough.

You have to see the design in context. A subtle, sublime design populated with flashy-colored photos might become garish or look cluttered. A multi-colored site that is a portfolio for subtle black and white photos might clash. 

Always check to see that the user knows what he needs to do next at every point of the website. Is the “Continue” button below the fold?  Does the user need to fill in a form? Does he need to register to get more content? He needs to know this within seconds, or he is bored and gone!

Make sure the user sees the CTA – the Call to Action. You want the user to do something, so make sure he knows how and what. This is usually a button or link or a form. Make it more prominent than the rest of the content, clear and functional. You’d be surprised to know how many sites don’t have this in a very clear position, clearly labeled, or even above the fold. The CTA is the most important element on your site because it gets the user to do what you want and hopefully what he wants to do, too.  Here is a good example:  Don’t call a button “Submit.”  Instead, call it by its function and what it does.  For example, “Download the book” or “Subscribe to the newsletter.” Submit is vague and open to misinterpretation.

Once the design has been finalized, make sure you have stakeholder buy-in at every stage of the design process. You don’t want someone who has some investment in the website to have a nasty surprise – or worse still – insist that things be changed after the developer has finished. The nice word for this is regression, but I have heard it called other things as well.

So everyone is happy, now it’s the task of the designer to create a style guide that can be given to the developers. The style guide should include the BRD, the fonts and colors used, the logo, a reference to any brand guidelines, and the pixel specifications of the layout. Other information such as do’s and don’ts are often added. For example, how to crop a photo and the maximum length of text for headings and body text. Other elements like graphs and tables might be specified here. This style guide is the bible and will help keep everybody focused on what they are doing.

Fantastic! Great job! However, the reality is that all we have is a document of about twenty pages that has been a lot of work, but no website! You lucky people who are making a simple portfolio site all on your own would probably have skipped over most of this, but the small to medium-sized businesses have invested heavily just to get this far. However, it’s a good investment. You have a document that reflects exactly what you need to create a great website, and it preempts repeated regression, delayed deadlines, extended budgets, and bad feelings.

The Content 

This is something that can run parallel to the previous steps, and that is aggregating the content that will be on your website. This is web-written, error-free, relevant, approved text. This is always the biggest hurdle in building a site. Nobody likes doing this; it’s boring, it’s labor-intensive, and it usually has to come from different sources and be approved by several stakeholders – which means several iterations of many documents. Start this process as early in the game as you can. It’s a silent killer. This is tedious work, and a good workflow is essential. Too often, I have had people working on a document at the same time, making changes, and then I end up with two versions. Which is the right one? How do I merge these changes? Tread carefully; this is a minefield.

Writing for the web is an art form. A well-known saying is, “I had no time to write a short article, so I wrote a long one.” It is very difficult to write clear, concise text. People also have the tendency to write a lot just to show the boss that they have been working hard. Long-winded sentences with corporate jargon send every user bouncing away like rabbits. Keep it simple, keep it to the point and keep it short. Split the text up into short paragraphs, write clear headings and subheadings, and if the text goes below the fold (so that the user needs to scroll), you are probably writing too much. Consider bullet-pointing the main topics.

Also, make sure that the content can be delivered to the developer or webmaster as unformatted text and web-ready graphics. Developers will often charge (heavily) to reformat files. The safest file format for text is anything with a .txt extension. For graphics, the graphic file should be either .gif (use if you want a simple animation) or .jpg (best for photos) .png (if the image is not a square or rectangular shape and its background is transparent – like a round logo). The graphic should be 72 dpi and be the size specified in the style guide. Always make sure that you have an agreement with the developer on how he wants the content. Some are easy about converting files; others will use it as an excuse for anything that goes wrong. 

As if!

The Development 

This is the biggest cost and can produce the biggest headache, but it doesn’t have to be like that. Just as designers in the wild love to change everything, free-range developers hate change. Developers want to make tight code that does its job neatly, efficiently, and as stable as possible. The thing that throws them out of kilter is changes after they have started coding. This is when the true value of the BRD and the style guide kicks in. This has focused on the client (you and any stakeholders) so that you won’t need to make any expensive changes afterward. The developer accepts the BRD and style guide, gives a price, and delivers a product. 

To have a website, you need a domain name and a server. These days it’s very easy to get both, as providers like godaddy.com (also reviewed in this book) give excellent deals. There are lots out there. You can also ask your developer to do this, but make sure you have control of your domain name. Some developers charge a lot for this service and are sometimes reluctant to let go, binding you to their services whether you like it or not. Worse still, they might be the owners of your domain name, something you never want under any circumstances.  I would advise you to buy the domain name and give the developer access to your server space that you rent at any of the many ISPs (Internet service providers) on the market. This is as simple as going online and buying a package. The costs are minimal; I pay my ISP less than $300 a year for hosting several sites. I have bought many domain names for $14 that I have only used as placeholders for project sites.

An HTML site and a CMS site. 

The HTML site is just HTML code that anyone can write and is downloaded from the server as is and shown in the browser. It’s the old school way of doing it. Often when the site gets larger than a few pages, the site is linked to a CSS file which basically defines the style of the site. Change color in the CSS, the color changes on the whole site. I would use this for simple sites with little content.

The CMS site (content management system) site is created with free software packages that manage your content.  Some examples are WordPress, Joomla, and Drupal, but many packages are out there. They do this by putting everything in a database and generating HTML pages when a user enters your website. This sounds complicated, and it is.  But it doesn’t have to be for the site owner; it can be quite easy. The major ISPs usually install these packages for free on request, and you can give your developer access to build within your CMS.  These sites are great when you have a lot of content, especially when several people will be working on the website or if the website is dynamic, changing regularly. See more about CMS in this book. 

I highly recommend that you use WordPress or Joomla or even HTML above any proprietary software that a developer might recommend. Once your site is developed in code that only your developer can understand, you are committed to him forever. I might be a bit skeptical, and there are a lot of great developers doing excellent work out there, but be very aware of the pitfalls of proprietary software. One argument is that free open source software like WordPress is too dependent on volunteers and goodwill to be a risk-free investment. This was true five years ago. But now the user base for such CMS packages is so large, the community so invested, and the software so fine-tuned, such arguments are no longer valid. 

Always remember, to reach a large audience, your site needs to be responsive, meaning that it’s compatible and viewable on multiple browsers and devices. This is a big problem as browsers are being updated all the time, and people are viewing on all sorts of devices, from huge displays to small Smartphones. They all expect a good user experience. 

Make sure the website loads fast enough. You might have a blistering broadband connection at home or the office, but if the site takes longer than 3 seconds to load, the users will start to drop off in droves.

So the developer has got her stuff and is coding away. Shhh! – let her work; you should not disturb. Coding needs concentration and focus, more now than at any point in its development. But don’t worry, you have done a great job with the BRD and the style guide and delivered all the content clearly marked, nothing to worry about. Is there? Really? It does seem to be taking a long time. Should I call? 

Before management slips into micro-management, some tricks might help you at this stage. 

First is the concept of KPIs – and this can be done at all stages of any project. KPIs or Key Performance Indicators are often established in the BRD as important things that need to be done, when they need to be done, and what defines them as having been done. For example, you could state in the BRD that the website domain name should be registered in your name and webspace rented, and the developer should have access to the site by a specific date. This is a KPI. If the KPI has not been achieved for any reason, that means emails must start flying, meetings arranged, and heads must start rolling.

A KPI should be defined whenever there is a point in the development that needs to be achieved, especially when future progress depends on it. Again, this is as simple or complicated as you want it to be, a single sentence or a three pager. Just make sure the parameters of the KPI are defined so that it’s clear when the performance has been achieved and what happens when it has not.

Secondly, and this is only for complicated, multi-personal websites, the concept of waterfall and agile. Most people work in a waterfall type of project. You start, you progress, and you finish. You define the Business Requirements Document, do the work, and finish. Agile development is for complex projects that need a BRD, but because of its complexity and the volatility of the market, it needs some agility to change as the project develops. Writing about this, I’m making myself guilty of scope creep, but if you are involved in a large project, some research into Agile development might be a great investment in project management.

The developer calls (at 3 o’clock on a Sunday morning) and announces that the website is finished. Great. Don’t be afraid to do a “soft launch.” This is when the site is live but not yet announced. You tell the stakeholders, a few friends, and your mother that they can go take a look. These “friendlies” will give you feedback and point out any gotchas – (“no, that’s not how you spell Phuket”).

This is a good time to do some user testing. After the soft launch – PROMOTE!!!! This is the hardest part off all. You are now out there with a billion other voices, so shout hard and loud. You are the owner of a great new website. Put the URL on your business card, buy AdWords, have a launch party, and market it (thank God you got the marketing department on your side with the BRD!). Pay attention to discoverability – can the search engines find you and find what you want them to find on your website. All that’s left is the fine-tuning.

The Fine-tune
The fine-tune is when you revisit your website and tweak it. You should be able to do this without going through your developer or designer. Keep your site fresh, relevant, and trending. Stale content is the best way to keep users away.  Fine-tune on a regular basis, put it in your calendar, and make it a routine.

The best way to do this is to look at the metrics. See where your visitors are going and how long they stay there. Ask for comments from users, push traffic, engage your users and adapt to their needs. You have an ROI – a return on investment – they have an ROUI – a return on user investment. They are investing in something that some people find more important than money, their free time. They want to be engaged and get what they want. Judge your website on their participation. If their ROUI is high, so is yours. Congratulations, you did a great job and have a great site! 

Good luck!