Identifying your needs in an alien world….

One of the hardest things to work out when producing a brief, or telling someone your requirements, is being able to differentiate between what you want, what you need and not picking out a solution by mistake thinking it’s what you need.

If I were to put this into terms easier to understand, let us imagine an alien has landed on earth and his space ship is broken. He needs transport to travel around looking for parts to help fix his ship, but he doesn’t speak the language very well and doesn’t know what is available. (This is often surprisingly similar to how people feel when they first think about building a website!)
The first thing the alien sees go past is a horse and cart and so he thinks that he needs a horse and cart. This is not strictly true, he needs a vehicle and a horse and cart may meet his needs but if he wants to carry heavy parts a long distance then a van or a car & trailer may be better suited to the job. However because he doesn’t know there are alternatives to the horse and cart, and he has seen the horse and cart, then when trying to explain to someone what he needs he is likely to go and draw a picture of a horse and cart and say that is what he wants. This is a very common problem for all sorts of projects and can be the cause of many misunderstandings when suppliers are sought to build websites.

The trick to stopping this from happening is to break your list of requirements into a set of functions; and then checking you can answer yes or no to the question ‘does it do this?’ or ‘does it have this?’ for each function. Also try to ensure the function/question cannot be misinterpreted and is not ambiguous in anyway.

In our above scenario if the alien were to forget he saw the horse and cart and try thinking about the functions he needs his transport to fulfill, then the list of his requirements for transport could be:

  • economical to run
  • easy to load single handedly
  • able to carry large and heavy parts such as a spaceship exhaust (detailing where possible likely sizes, weights and shapes)
  • comfortable to sit in for someone of an alien shape and size
  • capable of transporting baby aliens safely
  • able to get fuel in remote places
  • possible to resell once he has finished and flies away home
  • low initial cost in Alien Currency

In this example it is important to say ‘comfortable to sit in for someone of an alien shape & size’ as it may be that in the opinion of a human that one vehicle is comfortable but for an alien with extra arms or legs they cannot squeeze them into the space! In the same way if you can set boundaries or a scale rather than only using a word like ‘heavy’ ‘large’ or ‘lots’ which can be interpreted in different ways then it is good to do so.

Another good way to check you haven’t accidentally put down a solution rather than a requirement is to see if your list can be read without someone asking ‘why do you want this?’. So for the requirement ‘easy to load single handedly’ it is clear that they need someone to load it single handedly. However if the requirement had been written as ‘needs a low access’ then it wouldn’t be clear why this was needed and it could be assumed that for some reason they needed a vehicle low to the ground when other solutions may meet the real core need (e.g. a lift, or a ramp)

Once the alien has created his list, if he were to take it to someone to help him out then they would be much better placed to do so as they will have more information about the sorts of things the vehicle needs to do. It may also be possible for the alien to prioritise the items in the list to help him and his advisors make a decision e.g. it may be that it is more important to have something that is easy to load than it is to be comfortable or the ability to carry large parts may be more important thus suggesting that a van with poor suspension would be better than a comfortable estate car of the same price. Prioritising the list will help ensure that the best overall solution is found.

space alien spaceship from clipartheaven.comThe digital world can be a very confusing place with new exciting technology appearing all the time. It is very easy for even the most experienced of digital users to get carried away with the buzz of this new technology and think that they really need this new tool or application to make their business run better. Sometimes this is the case, and sometimes even if you have a system in place it’s possible to take the most appropriate bits of a new technology and integrate or merge it with your existing systems to get their benefits. However the key to doing this successfully, whether you are enhancing an existing application or building something new from scratch, is to pinpoint exactly what it is that you want something to do and then use this information like a checklist for any new technology or solution provider you are looking at. This helps ensure that the work you are doing helps you achieve your goals in the best possible way, and will help keep you on the right track in a an often seemingly alien world.

Where to begin

For most web projects, whatever their size, they start with a ‘brief’. The brief comes into play at the point where a decision is made to go forward with an idea and someone is sought to help deliver it. It doesn’t matter if the provider is internal or external but some form of communication is needed to make the idea happen and this is where the brief comes in. The brief can be called many things depending on the organisation; examples include “invitation to tender”, “request for quote”, “design brief”, “website brief”. However in essence they all do the same thing: they inform the potential service provider(s) of what the customer wants so that they can provide a quote or an estimate as required.

question mark over a blank briefOne of the most common concerns I come across working with both agencies and with end clients is the question around what should go into a brief. It is possibly one of the most important documents that is produced, as it sets out high level expectations and will inevitably be referred to further down the line; but it is often one of the weakest documents because of lack of understanding or knowledge of the people producing them at this point in the proceeding. When a brief doesn’t have enough (or the right) information then agencies and service providers find this frustrating because their quote will inevitably be wrong to some degree and a sacrifice on time or money is likely to have to be made at some point during the project. This isn’t good for anyone.

So, in summary, a good brief saves money and keeps good relationships! With this in mind, I have put together a checklist you can use to help ensure that the key information has been covered in your brief. This is not a suggested format, but rather a list of areas which should be covered within the document. The format and how this is interpreted will be different for every piece of work e.g. a brief for a new design for an e-newsletter doesn’t need to be as comprehensive as a brief for a new website, but the salient points remain the same.

Checklist of information to put in your brief

  1. Who are you? Include some background information on the organisation/group/company commissioning the work.
  2. What is the purpose? Give details of what are you trying to achieve and why are you looking for work to be done. By thinking about the purpose of what you are trying to achieve it is easier to break down what you need. This is an area I will go further into on a future blog.
  3. Who is your audience? It is important to think of all the potential types of audience for the concept: who is likely to use it, and who you want to target to use it; and if there are several types of users then it may be appropriate to prioritise them.
  4. Who are your content providers? Provide information on whether or not the content is likely to be static or change frequently, who is going to provide the content and if there is any authorisation process required before it can go live. This all helps ensure a fit for purpose solution that need not incur large ongoing maintenance costs.
  5. What types of content will your web site/application have? Intranets often are used as places where documents and templates are stored for employees e.g. HR forms; however external applications may be less about documents and more about words, video and/or sound.
  6. What support level do you require? Considerations here could be if a website needs to be hosted then do you need backups or a guarantee that the site will be up over 99.95% of time, or maybe you have a requirement for an application to be built for a time specific event and there is likely to be heavy usage during that time, in which case you may wish for extra support.
  7. Have you any branding/logo/legal requirements? These may be dictated by the source of funding e.g. a need to meet certain high accessibility standards, or there may be  corporate brand guidelines that need to be adhered to.
  8. What marketing and user interactive elements do you intend to have at launch/in future? This may not be applicable for all solutions however if you intend to capture user data, or if you are likely to link into Social Media applications then knowing this up front can save you alot of time and money.
  9. Are there any future requirements or technical constraints which should be considered? Considerations here could be the technical platform that your website is sitting on e.g. is it operating on Microsoft or Linux; or it could be that you know in the future you are going to do a large TV advertising campaign and therefore the application needs to be able to support an increase in visitors at that time.
  10. What information do you want to receive back from the companies tendering? If your organisation needs references, prices broken down by various elements, or would like to receive information back from companies in a particular format (word/presentation/hard copies) then informing them up front can save time and confusion later.

Finally: remember the brief produced should give enough information to potential providers that they can return a realistic quote and some potential solutions for your needs. However, the brief should not dictate design or solutions. By working on design and solutions as a collaborative process with the chosen provider (internal or external), you can make use of their expertise to find the best end result.