Documentos de Académico
Documentos de Profesional
Documentos de Cultura
No one says building a website is easy. But when it is often the largest single project in the yearly budget, why do so many companies make the same mistakes and end up with less return on their investment? This document highlights the 5 commonest errors, so we can all avoid making them.
Einsteins definition of insanity: doing the same thing over and again but expecting different results.
It is a definition that will resonate with many digital planners. During the process of website development, the same issues and mistakes seem to crop up over and over again. But what can we do to stop the madness?
Most website re-design projects by their very nature arise because the site is not working as it should. So over the years, we have seen a lot of them, in different industry sectors, geographies and company cultures. Yet it seems like the same reasons and excuses crop up time and time again for the reasons why it got to where it is, why its not working as well as it should, and why they need to redevelop. And amazingly enough, sometimes the redesign process simply leads to the same thing happening, requiring a further redesign two years later. The fact is, most of the mistakes are not down to technology, but happen behind the website and are a function of client and/or the agency. Let me quickly point out, however, that the aim of this whitepaper is not to suggest that we are right and everyone else is wrong. Nor is it to suggest that any particular person is to blame (client or agency) for web projects that fail to fulfil their potential. Over the years weve made some pretty big mistakes too. But we hope weve learned something during the process, because we dont make those mistakes any more and our work is better as a result. This document is all about sharing those learnings with you.
A huge challenge
First though, we should acknowledge the challenge of building a website. Creating an effective site that successfully positions and differentiates your business is not easy, of course. The length and complexity of the process brings in enormous margin for error and if you ask those involved to say what the main problems are, youll get a wide variety of answers. Many are personal opinions: designers, developers and project managers will always have their own take on things. But for me, there are more fundamental issues that will derail a sites effectiveness, which well discuss below. View the following items as a compendium for avoidance: successfully navigate the issues and youre going to have a pretty good platform for success and a competitive advantage too as you can pretty much guarantee your competitors will have failed on at least one of these points. As a quick side note, Im not going to cover things like project management issues that cause a site to be late, for example. Its a fact that most sites are unrealistically scheduled. These faults are widespread, but the end result may be a great and effective site just late. Similarly an on-time website doesnt mean a good one. In fact, often the opposite: rushed, bug-ridden, incomplete. A site may involve a longer-than-expected design process. (Design scheduled for 1 week? Youre kidding right?) Coding may have taken many late nights. Testing may have taken a lot longer. But its OK, its good. You have an effective site and in any case, the agency is usually happy to take the hit on the extra few hours. So lets look at whats really behind the bigger issues. In no particular order I rate the top five reasons behind the lack of website effectiveness as follows:.
You can pretty much guarantee your competitors will have failed on at least one of these points.
If your site doesnt involve complex transactional process, Im less convinced of the need to usability test on early wireframes or prototypes. I am a BDUF kind of guy (Big Design Up Front) meaning that you get your initial design done and then refine it over time with usability. The BDUF mantra is: usability wont get you the right design, but will help you get the design right. Have solid user insight, a good IA process, then lets give the design team enough rope to explore the optimum route, rather than a wireframe to colour in. Then test.
Usability wont get you the right design, but it will help you get the design right.
In fact, for businesses who need to develop on a budget, Id argue that testing is better done later once you have a working site. The results will more often than not involve a series of simple tweaks that you can implement that will dramatically improve effectiveness - be it first impressions, reducing bounce rate, competitor benchmarking, improving form attrition, boosting conversions, or just knowing if people actually understand your site. User testing can give you huge insight and firm direction into what you should do next. Just make sure you do it. Usability testing can also be employed earlier to help you circumvent our next issue
And of course there is the political dimension. Probably the main curveball that gets thrown at the web development team is the need to accommodate the needs of those higher in the organization who are not close to the project. Theres nothing wrong with this in principle; its often their business after all. And sometimes you get reasonable demands. But, sometimes these come a little too late, often they can be a little strange, and occasionally they are out-right bizarre. Such requests might include the one to change the colour of the site (blue) because it looked a bit too green on the CEOs (faulty) monitor. Or the subsequent re-design to please the boss in Japan (instead of his audience). Or even the complete u-turns ordered from above just one week before launch. Thankfully, such instance are rare but they do happen.
Last-minute requests include changing the colour of the site because it looked green on the bosss faulty monitor.
IT teams provide another challenge. We find most are good partners, though sometimes unsuitable IT policy, often hidden around a veil of jargon and technobabble, causes unnecessary and costly delays, such as in the selection of a technology platform. Also, internal structures may create diverging interests, for example when web teams are departmentally separate to marketing, or in different regions. So how to get around the political requests? The truth is that this is the hardest of all, as every organization is different and no one wants to lose their job by ignoring ingrained management hierarchies. In our experience it works most effectively when you can get a clear vision and measurable objectives established early on, then to find a way to drum this in. The key is to get everyone involved early, for example by ensuring all key players are present at (or at least invited to) the workshops held at the outset.
Other ways round the political problem include: - to allow a decent time for concept sign off, and get consensus then, not later - if its a design consensus you need, try some user firstimpression testing, whether by group or individually. This can be fairly ad-hoc in nature and therefore inexpensive. - to present and agree as a group. Using the upwards-chain presenting method is no better than Chinese whispers - to get properly framed feedback, ask Does it work for our stated objectives? rather than Do you like it? - to have a clear explanation and rationale for designs within the presentation its amazing how often designs are just presented without any context. Once again, the key lies in getting a clear vision and alignment, although this takes time and may seem an unnecessary luxury when faced with the harsh realities of a set budget.
Often a sites effectiveness can be compromised by the technical platforms its built upon, or the teams availability. One business I encountered had a bespoke system written by one developer, and when the poor soul had a heart-attack the site pretty much froze. No one else knew how it worked. The more bespoke it is, the fewer people know about how it really works. Also there is a tendency for agencies to be guilty of impenetrable specifications that no one can really understand and therefore no one reads properly, leading to later issues such as but i thought it was going do to.... A human-readable requirements and/or functional spec should clearly describe the site - if you cant understand them then they shouldnt be signed off. And the devil is in the detail. Our other pet hate is poor production values that just compromise the overall quality and feel of a site. This is (generally) the responsibility of the agency. If the site produced doesnt look like the designs due to the coding only approximating the design, or is difficult to evolve, or manage, or very costly to make changes to, then your effectiveness is compromised. Thankfully this is getting less frequent, but we still hear it costs me 500 whenever I need to make a change for some things that should take 5 minutes for non-technical staff. When planning a site, be clear on what is going to be easy or difficult to change, and when assessing a design, spend time to find out how much its going to change once its coded (hopefully very little!).
Conclusion
When youre highlighting pitfalls in a document like this, its easy to paint a picture of gloom. Of course its not all this bad. In the B2B world, there are many shining examples of great web usability, of careful digital planning, and stunning on-line design and superb agency relationships. But my point remains that when a site slips below the standard expected of it, you can usually put it down to one of the above. And I hope that, having read this paper, it is your competitors who fall into those traps and not you...
Harlequin House, 7 High Street, Teddington, TW11 8EE Tel: 020 8943 9999 Fax: 020 8943 8222 www.baseonegroup.co.uk info@baseonegroup.co.uk
Hope that helps. If youd like us to help you build better B2B sites or just to discuss anything raised here please feel free to get in touch.Email us or call and ask for Paul or Ann-Maria. Thanks.