A step-by-step guide to creating a great website
From the Web and UX Design Accidental Encyclopedia – BUY IT HERE
So you want a website! Maybe you already have one and want to improve it, or are just starting out. Maybe you want to sell something, have a site for your business, show a portfolio or blog your thoughts and feelings. No matter what you do, creating and maintaining a website can be very easy – some lines of code on a server will do it – but a successful website is a whole different kettle of fish. Simply putting a website on a server will not attract visitors. I once had a basic site, meant for testing, with a little content and the site would get one or two drifters a month who accidentally stumbled upon it. I even know of some web designers who develop live on a server, and when somebody drops by, they are gone as quickly as they came in.
So let me take you through the process of designing, building and exploiting a website. Whether you are a website owner, designer, developer or UX specialist, you will want to make sure that your website is optimized at all levels to achieve the best results.
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 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.
A great place to start is to create a document called in the trade a BRD – a business requirements document. This is a document, and could be just a few sentences, that lays 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 on 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 more of that back in sales. 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 that will have 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 there will be more than one stakeholder) should all “sign off” on the BRD before anything else.
Some things to remember when you do research are:
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 cafeterias 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” – that is, 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. Through due diligence, I changed from deleting a page to spending more time on it. 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.
Great – BRD in hand, the stakeholders are on board, you should be able to start wireframing. Wireframing is a way of sketching out the website without getting bogged down in 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.
So this is the place where you make all your mistakes because you just screw up the paper into a paper ball, shoot it in the waste paper basket (and it bounces off the rim onto the floor) and you start again.
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 onboard 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 wire-frames 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 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 wire-frames with is the User Experience (UX) guy. This guy (and for a small site, it could be you) will check the wire frames against the UX mantra. Is it SSCC, that is – Simple, Structured, Clear, Consistent.
Your UX guy will look at:
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 wire-frames and see what they say (see the section on user testing).
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?
I once had a meeting that lasted two hours, with twenty people, while they discussed whether a menu label should be “library” or “archive”. This is ridiculous of course, but attention to detail is important and clarity is the rule of thumb in web design.
People skim the 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 length a user is on a page is less than 2 seconds. They make their judgment and click away.
Great! – Now you have your BRD AND your basic wire-frames 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 your 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.
You have already started this process by doing your research and setting this out in wire-frames. 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. You will see this in a lot of the sites mentioned in this book, but Chase, Jetblue, and Quicken loans are good examples.
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 of 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 where everybody wanted to impress, but in the end, wow factor delivered no ROI and in fact usually got in the way. No flashy intro pages, no complex animations, don’t overload in content. Keep it SSCC.
A design is subjective. Some people like orange, 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 about the design, that’s fine. Ask them to give an objective evaluation of why the design is not good. 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”, well, 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 at every point of the website the user knows what he needs to do next. 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, 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 had 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 a 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 does and do nots are often added. For example, how to crop a photo and 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 business have invested heavily just in getting 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.
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. This is by far in my experience the hard part. 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) .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 as 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.
Don’t forget to include social media in your content. Even if you don’t tweet or use Facebook, you should always make sure the user has the opportunity to give feedback about your site.
Phew! – We have the style-guide and we have wandered through the mine-field of content aggregation without a scratch. Let’s dump all this on the developer and sit back and relax.
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 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 two things – 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 ISP’s (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.
In my world, there are two types of site –
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 a 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 there are many packages 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, in fact, it can be quite easy. The major ISPs usually install these packages for free on request, and you can give your developer access to building within your CMS. These sites are great when you have a lot of content and especially when several people will be working on the website, or if the website is dynamic, changing on a regular basis. 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, and 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 the 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, there are some tricks that might help you at this stage.
First is the concept of KPI’s – and this can be done at all stages of any project. KPI’s 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 it as having been done. For example, you could state in the BRD that the website domain name should be registered in your name and web space 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.
Whenever there is a point in the development that needs to be achieved, especially when future progress depends on it, then a KPI should be defined. 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 BRD, you do the work, and you finish. Agile development is for complex projects that need a BRD, but because of its complexity, and the volatility of the market, 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 of 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, 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-tune.
The fine-tune is when you revisit your website and tweak. 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 in your calendar, 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 of user investment. They are investing 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!
A step-by-step guide to creating a great website
From the Web and UX Design Accidental Encyclopedia – BUY IT HERE