Needs Analysis for Business Websites

Questions to ask your client before building their website.

This article is most relevant to people who develop standard websites (e.g. a business’ web presence). If your main focus is web-based applications, this paper may have limited appeal.

Client input is the foundation upon which successful web sites are built. It’s absolutely vital that you get your client to articulate their goals in order for you to successfully deliver their project . To help facilitate this process, a number of questions can be asked relating to areas such as target audience, desired look and feel, and what interactive functionality is required.

A good way to tease out your client’s requirements is to use a Needs Analysis document. This is basically a 2-3 page fill in form, full of questions which prompt the client to think about not just the visual elements of their site, but what they are trying to achieve in concrete business terms.

Using a Needs Analysis form provides many benefits. It often acts as the basis for developing a fee proposal or tender (see Writing Fee Proposals). Unless you know what it is your client wants, you wont be able to cost it with any degree of accuracy. Another advantage of a Needs Analysis form is it can present ideas to the client which they hadn’t previously thought of. This isn’t just a boon in terms of up-selling, it also means features aren’t added mid-way or at the end of a project (e.g. client: “I know you’ve finished my website, but can you just quickly add a photo gallery page?”).

The Needs Analysis form I use is broken up into five sections; Company Details, Graphic Design, Business Related, Technical Requirements, and Programmed Features. I will cover some of the questions contained in each section along with the over-all structure of the form.

I always start documents with a short description of what the document is. This is for the benefit of anyone seeing it for the first time (e.g. Document Purpose: this form is used to gather client requirements...).

Company Details â€" this section is pretty straight-forward, you record information such as the company name, who the main contact is, address, phone numbers, the client’s position within the organisation, etc. It’s also a good idea to note down any other stake-holders that will be involved in the project, and if the primary contact is able to give approval for the work to begin.

The information gathered in the Company Details section will most likely be needed for producing a quote. It will be especially useful if a sales consultant or business development manager is gathering requirements to hand over to a project manager. From this, the project manager will be able to figure out who's who on a project.

Graphic Design â€" this section is meant to capture details relating to the website’s visual appearance. It is not so much concerned with layout and colour, but rather communication. The information gathered in this section will be most useful to a graphic designer. Good questions to ask the client include; ‘what image are you trying to portray?’ (e.g. friendly, corporate, innovative, etc), ‘what phrase would best describe your website once it’s launched?’ (e.g. ‘these guys look really professional’), ‘what’s the main goal of your website?’ (e.g. sell products online), ‘what else are you trying to achieve with your website?’ (e.g. promote skin cancer awareness amongst young people), ‘what would you like users to do at your website?’ (e.g. register, buy products, etc).

You also want to ask if the client’s logo and branding material is ready. Your graphic designer will want to get his hands on any digital files as soon as possible (e.g. logos, product photographs, etc). Connected to this, you may want to ask the client if they have a style guide. The topic of Flash vs. static HTML also needs to be discussed since there may be SEO and cost implications.

Another important subject is the intended audience of the website. Questions you could ask include; who is your intended audience? what’s their typical occupation?, what is their age range?, is it mostly male or female?, how often do they use the Internet?

You can ask the client to show you some websites they like and have them explain what it is about each site that appeals to them (e.g. client: “I like the clean layout of the site”, “the animated banner is really cool”, etc). If you know that your client likes a particular style of navigation, it makes sense to use that style for their website.

Notice that none of these questions have to do with layout or color schemes (e.g. where the navigation should be, what font should be use, etc). These considerations should be left to the graphic designer, after-all, they are the expert.

Business Related â€" these questions aren’t directly connected to the visual appearance or functionality of the website, but they may have an impact on the project itself. For instance, you would want to ask questions like: is your content ready?, how are you planning to market your website once it launches?, are you open to developing in stages to manage costs?, do you require an SEO strategy?, are there time constraints (e.g. client: “we need it ready before we go to a trade show in November”, or “we are printing a brochure next month and want to refer to the website”)?

You may wish to ask a few questions about the client’s competitors, such as; do your competitors have websites? what do you like about your competitor’s websites?, what do you dislike about your competitor’s website? Sometimes finding out what someone doesn’t like can be a great help in determining what they do want.

Probably the most significant of the business related questions is about content. Lack of content can be a real killer. A wonderful website may be developed, but if the content isn’t ready, the site is effectively in limbo. One way to help reduce the risk of this happening is to recommend early on that the client engage a content publisher.

Technical Requirements â€" these questions are mostly system administration related. For instance; you want to find out if the client already has a hosting provider organised. You also need to know if the client has registered their domain name or if they want you to register additional web addresses on their behalf.

Programmed Features â€" this section covers the interactive elements of the website. Probably the most important goal of this section is to establish the information architecture of the site. This can be done by asking the client what sections their website should have (e.g. press releases, our work, testimonials, etc). The client may also have a need for interactive pages which require custom coding (e.g. sign-up form, news articles, member’s login, photo gallery, etc).

Other significant questions would include; are you planning to sell anything online?, do you require a CMS?, does your site need to work with an existing database?



You’ll generally find that only about 80% of the form’s questions are relevant to any particular project. That being the case, it makes sense to remove or cross-out irrelevant questions before meeting with your client (e.g. you would probably know before-hand if any e-commerce facilities are needed).

Another idea is to pre-fill as much of the form as possible. Besides the obvious benefit of saving time in the face-to-face meeting, it demonstrates you’ve paid attention to verbal requirements which may have already been discussed.

One Minute Goal Settings

Getting quality work from your team members

Most arguments people have with each other are a result of misalignment of expectations (e.g. Bob: “you said you were going to do this...”, Tony: “I never said that!”. Jane: “You promised this...”, Greg: “I never promised that!”).

- Brian Tracey

A common problem encountered in the workplace is when a team member thinks their responsibility or task is one thing, but their manager has a completely different idea about what they should be doing.

This is where One Minute Goal Settings come to the rescue (or Goal Settings for short). Simply put, its just a one page document which is split into two parts; the first part describes the task to be undertaken, and the second part details the level of quality that is required.

This strategy was developed by Kenneth Blanchard and Spencer Johnson and is contained in their classic book The One Minute Manager. At its core, the idea is that people working together should know what is expected from beginning to end, there should be no surprises.



What’s that I hear you saying? “just fire off an email or put a Post-it note on their desk telling them what you want them to do.” Well, a goal setting document is different in two very important ways; for starters, its a mutual agreement, and secondly, it specifically sets out the level of quality you have in mind.

These are two very powerful things which should not be underestimated. It’s well known that people are more inclined to do something if you ask them rather then tell them. Giving people a say on how they work is very empowering. Getting a person to happily agree to the parameters of a task has so many benefits its simply beyond the scope of this article to discuss them all, lets just say the chances of success go up dramatically.

The second major aspect of a goal setting document is the level of quality expected. Why is this important? Because people can have vastly different ideas about what constitutes quality. A programmer may not even notice a button is misaligned by a few pixels, but to a usability expert, this could send them right over the edge. There’s an added bonus to openly discussing how well things should be done, over time it can actually lift peoples’ quality of work as they are exposed to a higher ideal.



This is a typical scenario of how a goal setting session with me would go:

Louis: “John, when you’re ready, I’d like to go over your goal setting for system testing”

John: “No problem, I’ll just finish writing this email. Say 10 minutes?”

Louis: “Sounds good”

[we go off to the boardroom - goal settings shouldn’t be done around other team members]

Louis: “OK John, I’ve written up your goal setting for conducting system testing on the Widgets Project. I’ll read through it and you can tell me if it all sounds reasonable, if you’re not happy with anything in it, I’ll go change it”

[read through the document â€" this takes only a minute or two]

Louis: “How’s that sound, does it all make sense?”

John: “You said you need it done by this Thursday, but I’ve got a dentist’s appointment in the morning. Can we make it Friday instead?”

Louis: “Done, I’ll update it and re-print it”

[I adjust the document, re-print it, and come back â€" this rarely happens by the way]

Louis: “OK, updated, Friday it is now. So you are happy with everything I’m getting you to do, ‘cause you are making a commitment to me on this task”

John: “Yep, all sounds fine to me”

Louis: “Cool, we’re all done. Oh, keep in mind John, before you come to me to say you’ve finished, just be sure to re-read the document at least once to make sure you really are finished, OK?”

John: “Yeah, make’s sense”

[Friday passes and John reports the work has been completed]

Louis: “The system test went well. I saw you logged 43 bugs. Do you know how badly you saved our ass? Imagine if 43 bugs went through to the client. Good stuff John.”

And that’s it, it really is that simple. Assuming you are working with competent and passionate individuals, things will rarely go wrong. If you want to know what the course of action is should things go wrong, I recommend getting the book as it covers the topic in the required detail. When things go right, just be sure to let the person know you are happy with their work.

Do goal setting documents always work? The simple answer is no, there are rare occasions when it’s actually counter-productive to enforce a goal setting agreement. Let me relay an instance when just such a situation occurred.

I was working with a number of programmers at a small web development company where resources where quite tight. I had been using goal settings with success amongst the junior programmers, but a time came when I negotiated a goal setting with the senior programmer to have him produce a coding style guide. Even though I could of produced the guide myself, it was too far outside of my dominion. The style guide was more likely to be accepted and adhered to if it was championed by ‘one of their own’ (i.e. written by a programmer for other programmers).



At the time, the senior developer was under a lot of pressure to deliver on a number of client projects. The agreed date was missed and no style guide materialised. Even though there was a pretext to say “hey, didn’t you say you were going to produce the style guide by the 18th?” in this situation, the value of doing such a thing would have been counter-productive.

I could obviously see that he had been working exceptionally hard to keep other commitments he had made. Also the fact that he was in a senior position in some ways gave him mandate to drop tasks as he saw fit, he is after all a professional with many years of experience, he knows what he is doing.

Bare Minimum On-Page SEO

A checklist of basic Search Engine Optimization considerations

In 2004 I was part of a team that developed a shopping website complete with credit card payment facilities. The site allowed people to trade-in their old Xbox or Playstation 2 games as well as buy new ones.

Fast forward to 2007. The client we produced the shopping site for contacts us and says the website has serious SEO issues. Three years had passed since I worked on the site, so I needed to go back and have a look at it again. Sure enough, the site did in fact suffer from a number of SEO short-comings. For example, it didn’t show the product’s name in the browser title.

Because so much time had passed, there was no obligation to go back and fix it (I wasn’t even at that company anymore). The result; the site closed down since it had no chance of challenging its competitors in terms of search engine ranking. The client was not willing to pay to have the site upgraded either.

An unfortunate chain of events, but in the client’s mind, we had drop-the-ball on this one. At the time, a SEO checklist would of been handy. Just a basic list of the bare minimum on-page SEO we needed to do in order to call ourselves professionals. In the last few years, I have developed just such a list. I periodically update it to keep current with SEO trends.

I should quickly explain what is meant by On-page Optimisation. Basically, these are things a programmer can do in code to improve a site’s chances of ranking high on search engines. Off-page Optimisation would be strategies like negotiating reciprocal linking with another popular website that is complimentary to what you do (e.g. website A sells posters, website B sells frames, both companies could improve their search engine ranking by promoting each other).

I don’t claim to be an expert in SEO, I have however been lucky enough to work with one, so I know what the real thing looks like. The list I use is quite simple and only takes about 10-15 minutes to run through.



Obviously there is no shortage of SEO articles on the web, but I’ve found that they are often prescriptive; in that they tell you what you should do, but not why you should do it. So I will attempt to explain the reasoning behind the various SEO safeguards on the checklist.

HTML frames aren’t used - other then being very old school (circa 1997), search engines don’t crawl frame-based sites very well (some like AltaVista ignore the site completely). There are also usability issues with frames (i.e. screen readers may have trouble interpreting them).

There's no significant content contained inside Flash â€" obviously, if you have text embedded inside a Flash animation, search engines wont be able to get to it.

The navigation mechanism doesn't use JavaScript - search engines have trouble traversing navigation mechanisms which employ JavaScript, the result is most of the site wont be spidered (HTML lists formatted with CSS are commonly used instaed).

A sitemap is available if JavaScript or Flash navigation are present â€" if you really must use Flash or JavaScript-based navigation, then a hyperlink to a sitemap will help search engines successfully complete their mission.

There is minimal redundant HTML tags - if you want a good example of this, just take a look at what Microsoft FrontPage produces, it does things like encase images in bold tags (e.g. <b><img src.../></b>). Proper use of CSS will also help minimise the amount of HTML tags needed.

If there's a lot of JavaScript, it’s kept in an external include file - this is because search engines give more weight to content appearing towards the top of the page. By moving JavaScript, or CSS for that matter, to external files, you are increasing the prominence of your content.

The amount of text content exceeds the amount of HTML code â€" if a website is bloated with loads of HTML code, it becomes difficult for a search engine to figure out what a page is all about. In fact, a search engine will actually give up and move on if it finds a page is to difficult to traverse.

Each page has a unique browser page title â€" this is considered one of the most important factors for high page ranking. There is also a connection between the title and the content of the page (e.g. if the page title is ‘The Simpsons - Season 1 DVD’ then the page should actually focus on that topic).

Page titles aren't longer then 6-10 words - a web page title that is too long is almost as bad as no title at all. Overly long titles don’t help readability. I have also seen material which says search engines truncate long titles. Keyword density also comes into play here (i.e. having keywords amongst lots of other non-keywords results in lower keyword density) .

Page titles are keyword rich - keyword density is a measure of page relevance. Keywords appearing in page titles have a greater weighting then those appearing further down the page (as a rule of thumb, 5-10 keywords should be concentrated on).

Standard HTML heading tags are used (i.e. H1, H2, H3) â€" using heading elements is a method for giving prominence to keywords. They help make it clear to search engines what the topic of a section is meant to be.

Images have short yet descriptive ALT tags - as a rule of thumb, the ALT tag should describe the image in a way that would make sense to a visitor using a voice-based browser. Sensible ALT tags also help a search engine understand the structure and content of your site (e.g. a search engine can’t ‘see’ a picture of a balloon, you have to tell it what it is).

URLs aren't overly long (i.e. under 100 characters) - some say short URLs have no impact on page ranking, and that it’s more important to have keyword rich URLs. But, according to Matt Cutts of Google, if there are more then 5 words in a URL, “[Google] algorithms typically will just weight those words less and just not give you as much credit.” Short URLs also tend to get about twice as many click-throughs on search result pages.

Hyphens are used in page file names rather then underscores â€" there is no penalty for using underscores, but Google interprets hyphens as separating words. For example, if you have a page called ‘posters_frames.aspx’ then it can only be found if a person searches for ‘posters_frames’, if you have a page called ‘posters-frames.aspx’, then it can be found by searching for either ‘posters’ or ‘frames’.

The domain name is relevant to the business/website â€" a website about posters should have the word posters somewhere in the domain name (e.g. www.posters.com). Having a number of major keywords in the URL is even better (e.g. www.poster-framing.com).

Physical page file names are short, descriptive, and keyword rich â€" search engines often give ranking preference to pages with keyword rich file names (e.g. www.../post-frames-pricing.aspx is much better then www.../article.aspx?id=19).

Metatags are used - the general consensus among SEO experts is that metatags are dead with regard to their role in page ranking (i.e. <meta name="keywords"... and <meta name="description"...). However, they still appear as a little snippet of text below the clickable title link on search engine result pages.

Hyperlinks make use of the title tag - the title attribute can inform a search engine about the connection between a link and a relevant phrase (e.g. <a href="poster-frames.asp" title=”Online Frames Superstore”...).

No pages are more then four clicks deep (max. 4 tier-navigation) â€" as far as search engines are concerned, less clicks means higher importance (i.e. important information is easier to reach). On a related topic, having files deep within the directory structure can also be detrimental.

Page file size does not exceed 150 kilobytes â€" web pages greater then 150 KB are generally not cached. Search engines do this in an effort to reduce index size, bandwidth requirements and server utilization. Also consider that small file size means faster downloads for visitors.



Are there other significant SEO checks you could do? Definitely. For instance; directory naming, keyword rich hyperlinks, keyword prominence (i.e. the order in which keywords appear), time-stamping content, HTML/CSS validity, and the list goes on. There is nothing to stop you from expanding my list.

If you really want to get deep into the topic, grab yourself a big cup of coffee and take a look at SEOmoz’s article Beginner’s Guide to SEO, its a good place to start.