Tag Archives: Battle

Battle of the Brit Agencies

Posted in News on by Paul Boag

On show 187 of Boagworld, Clearleft will be joining Headscape to record a special show. We want you to direct proceedings!

On Tuesday the 13th October the guys at Clearleft are coming up to the Headscape offices to record a special episode of the Boagworld podcast. Marcus, myself, Rich Rutter, Andy Budd and Jeremy Keith are going to have a round table discussion on all things web related.

Spy Vs Spy Image

However, just to make things interesting we want you to pick the topics to discuss.

To suggest a topic simply tweet your suggestion followed by the hash tag #bw187 or add a comment below.

The show will then be released on Wednesday 14th. The transcript will follow later.

We look forward to seeing your suggestions!

10 ways to Battle Site Bureaucracy

Posted in Web strategy on by Paul Boag

Running a large institutional website is frustrating. Your site is often held back by internal politics and bureaucracy. Let me show you 10 ways to cut through the crap and get results.

My recent post ‘10 harsh truths about corporate websites‘ generated a huge number of comments both on my own blog and on Smashing Magazine. I seemed to tap into an undercurrent of frustration that exists within the industry.

However, although there was a lot of agreement about the points I raised, there was also resignation. There was a feeling that little could be done to overcome these problems because institutional websites are too entrenched in bureaucracy and politics.

Although I can sympathise with this position and have myself suffered from the problem, I am not one to give up! Over the last decade of working on these sites, I have developed a number of techniques which (sometimes) help to smooth their evolution. Hopefully they will help you too.

1. Educate and inform

At the heart of any technique for dealing with politics and bureaucracy has to be education.

Although there are occasions when people are just ‘trying to be difficult’, in most cases their objections are based on ignorance.

You cannot expect people to be as knowledgeable as you about the web. If you want people to make informed, sensible decisions you must educate them.

Education is also not just about giving them the background to a specific decision so they understand ‘why you are right’. It is about increasing your organisations general understanding of the web.

Run workshops, publish email newsletters, do anything that informs people about the latest web innovations. Increasingly I am invited into organisations to run short seminars on everything from accessibility to facebook! This kind of ongoing education means people are better informed when tough decisions need to be made.

2. Hold stakeholder interviews

One technique that we find very effective at Headscape are stakeholder interviews.

Stakeholder interviews involves meeting individually with anybody who has a ‘stake’ (interest) in the website. This is typically members of the marketing and IT teams, as well as departmental heads and senior management. However it should also include suppliers, customers and users of your website.

These one-to-one meetings provide two opportunities…

  • Requirements gathering – It is easy for website owners to live in isolated bubbles, separate from the rest of the organisation. These meetings provide an opportunity to understand the real needs and objectives of others within the business. It will highlight ways that your website can help, which you might not have previously considered.
  • To be inclusive – Stakeholder interviews offer a ‘political benefit’ as well. By meeting with people individually they feel included in the process. They feel their opinions are valued and listened to (which they should be!). People are much less likely to object if they have been consulted before a decision is reached.

People often complain about the website in stakeholder interviews. Allow them to do this and avoid becoming defensive. They will feel more favourably towards you and your website, if you listen to their concerns. We all like to be heard.

3. Avoid group committee meetings

The key to stakeholder interviews is their one-to-one nature. Group meetings can be very destructive. This is for a number of reasons…

  • The need to defend – In large organisations that have internal politics, everybody feels the need to defend their own ‘turf’. If somebody criticise the website, you are forced to defend it to ‘save face’ in front of others. Equally others feel the need to defend their own positions for the same reason.
  • A tendency to compromise - When two individuals in a group reach an impasse, the others try to find a compromise. This kind of ‘design on the fly’ inevitably leads to a bland solution. It will neither offend or inspire anybody. Unfortunately, to create a successful website you need to make tough choices that some will not like. A group approach does not lend itself to this.
  • A loss of control – It is easy for you to loss control in a group meeting. One-to-one meetings work better because you can divide and conquer. Only you know what the other stakeholders said. This puts you in charge and allows you to ‘cheery pick’ the feedback you receive. In a group meeting things can easily get out of hand and decisions are made without your buy-in.
  • The dominant individual - Every group has one or two dominant individuals. These are the people who bounce the rest of the group into agreeing with them, forcing their agenda through. A dominant individual drowns out quieter members, who become resentful later that nobody listened to them. Meeting with people individually prevents this because the dominant individuals cannot force their point of view on others or overwhelm quieter ones.

One cannot expect a larger organisation to run its website without some form of committee. However, there is no reason why that committee needs to meet as a group.

4. Target your influencers

Talking of dominant individuals, another successful tactic is to target influencers.

An influencer is somebody that others respect and follow. Their opinion is incredibly valuable and if you can sway them to your cause, others will fall into line. However, be careful not to confuse dominant people with influencers. A dominant person will ‘bully’ others into publicly agreeing with them. An influencer will fundamentally alter somebody’s attitude.

Identify who influences your decision makers and speak to them personally. This person might not even be a decision maker themselves, but they carry enough clout to make them worth your time.

When you meet with your influencers, really listen to what they have to say. They often have valuable insights which may change your strategy significantly. Do not go into a meeting with an influencer simply intent on pushing your own agenda. Instead try and shape your approach around their perspective.

If you get an influencer enthusiastic about your project it can make a huge difference.

5. Use third party experts

A variation on the influencers technique is to back up your ideas with third party expert opinion. This can be done in two ways…

  • Reference the work of a third party expert – For example, if you wish to discourage internal stakeholders from overwhelming users with options on the homepage, you might refer them to Steve Krug or Jakob Nielsen who have both written on the subject.
  • Hire a third party expert - I often find myself brought into companies simply to confirm what in-house staff have already been saying. Unfortunately, decision makers often doubt the opinion of their web team because they either undervalue them or feel they are pushing a hidden agenda. An independent expert can add creditability to your opinions.

Of course, for this approach to work the stakeholders need to respect the expert. There is no point referencing Steve Krug or hiring Jakob Nielsen, if the decision makers have never heard of them. It is often necessary to sell the credibility of your expert first.

6. Rely on evidence, not opinion

Sometimes it is better to avoid personal opinion entirely (even if that is the opinion of an expert). In such cases statistics can be your friend.

Nothing is more powerful for driving home a point than referring decision makers to Google Analytics. However web stats are not the only evidence you can draw upon. Others include…

  • Surveys and polls are an excellent way of getting feedback from your users that can then be presented to decision makers.
  • Twitter search and Google Alerts can be used to gauge how people view your site and brand. These can be powerful testimonials to present decision makers.
  • Heat maps can be used to take some of the subjectivity out of design.

Of course one of the most powerful evidence you can present is the results of usability testing.

7. Focus on the user

As website owners we know that a successful website is user focused. However, not all our decision makers will understand this and even those who do may get ‘distracted’ sometimes.

It is therefore important to constantly move our decision makers away from their own personal preferences and back on the needs of users.

User testing is one way of doing this. Being able to show decision makers how real users interact with your website is incredibly powerful. It helps them empathise with the needs of users rather than thinking only about their own agenda. Play them video clips of users interacting with your site or at the very least quote them the feedback of users.

However, even if you involve decision makers in user testing, they can still get caught up in their own agendas. One gentle way of preventing this is to word your questions carefully. When you need a decision makers response to something don’t ask…

What do you think?

Instead ask them…

How do you think users will respond to this?

This will keep them focused on the needs of users.

8. Control the feedback

As well as wording questions carefully there is also a need to control the feedback you receive. This is important if you want the decision makers to make considered decisions.

Take for example design sign off – never ask a decision marker if they like a design. It is too broad a question that will lead to a plethora of uninformed and ill considered responses. Instead ask them more specific questions such as…

  • Does the design conform to the brand guidelines?
  • Does the design meet the needs of our users?
  • Does the design emphasis the right content?
  • Does the design have a clear call to action?
  • Does the design fulfil our business objectives?

This prevents the decision maker from falling back on their gut reaction (i like it / I dislike it). It forces them to focus on the issues that define whether the design is successful or not and ignore personal preference for specific colours or layout.

Of course, sometimes you will not like the answer to these specific questions. When that happens you need to ask why.

9. Ask why

This is probably the most powerful of all the techniques I have listed here and yet by far the simplest.

When you face opposition to your plans, always ask why. Too often we switch to defensive mode and focus on better communicating our own position rather than understanding the opinion of the person opposing us. This is a mistake.

The question why is powerful for three reasons…

  • It informs – Often the objection raised initially is not the true underlying issue. By asking why you get to the root of the problem and that allows you to offer alternative solutions. Asking why ensures you have all the information required to deal with the issue.
  • It can confound – Most of us make decisions based on an intuitive leap. We do not always think through our decisions and so find it hard to articulate the underlying reason. By asking why you force people to stop and consider their logic. When they struggle to express the underlying reasons, they weaken their position.
  • It shows interest – By asking why you allow them to have their say. You demonstrate an interest in their opinion and establish empathy with their point of view.

    • Ultimately asking why avoids the disagreement from turning into an argument with entrenched position.

    10. Avoid confrontation

    I avoid confrontation at all costs. Going head-to-head with somebody especially in front of their colleagues achieves nothing. You can rarely get somebody to shift their position through confrontation.

    Once a disagreement escalates into a confrontation, nobody can afford to ‘lose face’ by backing down. It becomes a matter of ego, where pride dictates the outcome. Your website will almost certainly be caught in the cross fire.

    A better approach is to agree. The word yes can be immensely powerful. Whenever somebody suggests something to me, no matter how stupid, I will do the following…

    • Acknowledge and thank them for their input.
    • Say yes we could do that.
    • Go on to explain the consequences if we did.
    • Offer an alternative which could achieve the same aims.

    In short I tend to go around problems rather than bashing my head against them. I always look to work with others rather than against them.

    Conclusions

    So there you go, 10 techniques for battling site bureaucracy. I do not claim these techniques are foolproof. Neither do I suggest they are always appropriate. However, they are useful techniques in your arsenal which you may want to call upon from time to time.

    Finally, this is not a definitive list. I could have written more but then it wouldn’t have been a ‘top ten list!’ However, I would be interested to hear what works for you. Post your techniques in the comments.

    10 harsh truths about corporate websites

    Posted in Web strategy on by Paul Boag

    We all make mistakes running our websites. However the nature of those mistakes varies. As your site and organisation grow, the mistakes begin to change. This post addresses common mistakes in larger organisations.

    Most of the clients I work with at Headscape are larger organisations – Universities, large charities, public sector institutions and large companies.

    Over the last 7 years I have noticed certain reassuring misconceptions within these organisations. The idea of this post is to dispel these illusions and encourage people to face the harsh reality.

    The problem is that if you are reading this post you are probably already aware of these things. However, hopefully this article will be a useful tool for convincing others within your organisation.

    Anyway, here are my 10 harsh truths about larger websites.

    1. You need a separate web division

    In most organisations I work with the website is managed by either the marketing or IT department. However, this inevitably leads to a turf war and the site becoming the victim of internal politics.

    In reality running a web strategy is not particularly suited to either group. IT maybe excellent at rolling out complex systems but they are not suited to developing a friendly users experience or establishing an online brand.

    Marketing on the other hand is little better. As Jeffrey Zeldman puts it in his article ‘Let there be web divisions‘:

    The web is a conversation. Marketing, by contrast, is a monologue… And then there’s all that messy business with semantic markup, CSS, unobtrusive scripting, card-sorting exercises, HTML run-throughs, involving users in accessibility, and the rest of the skills and experience that don’t fall under Marketing’s purview.

    Instead the website should be managed by a single unified team. Again Zeldman sums it up when he writes:

    Put them in a division that recognizes that your site is not a bastard of your brochures, nor a natural outgrowth of your group calendar. Let there be web divisions.

    Screenshot of Zeldman's website

    2. Managing your website is a full time job

    Not only is the website often split between marketing and IT, it is also normally under resourced. Instead of having a dedicated web team, those responsible for the website are often expected to run it alongside their ‘day job’.

    Where a web team is in place they are often over stretched. The vast majority of their time is spent on day to day maintenance rather than longer term strategic thinking.

    This situation is further exaggerated because the people hired to ‘maintain’ the website are junior members of staff. They do not have the experience or authority to push the website forward.

    It is time for organisations to seriously investing in their websites by hiring full time senior web managers to move their web strategies forward.

    3. Periodic redesign is not enough

    Because corporate websites are under resourced they are often neglected for long periods of time. They slowly become out of date both in terms of content, design and technology.

    Eventually the site becomes such an embarrassment that management step in and demand it is sorted. This inevitably leads to a complete redesign at considerable expense.

    As I point out in the website owners manual this a flawed approach. It is a waste of money because when the old site is replaced the investment put into it is lost. It is also tough on cash flow with a large expenditure happening every few years.

    A better way is continual investment in your site, so allowing it to evolve over time. Not only is this less wasteful it is also better for the users as is pointed out in Cameron Moll’s post ‘Good Designers Redesign, Great Designers Realign‘.

    Screenshot of Cameron Molls Article

    4. Your site cannot appeal to everyone

    One of the first questions I ask our clients is ‘who is your target audience?’ I am regularly shocked at the length of the reply. Too often it includes a long and detailed list of diverse people.

    Inevitably my next question is which of those many demographic groups are most important. Depressingly the answer is that they are all equally important.

    The harsh truth is that if you build a site for everybody it will appeal to nobody. It is important to be extremely focused in your audience and cater your design and content around them.

    Does this mean you have to ignore your other users? Not at all. Your site should be accessible by all and should not offend or exclude anybody. However, it does need to have a clearly defined audience that the site is primarily aimed at.

    5. Your site is not all about you

    Where some website managers want their websites to appeal to everybody, others want it to appeal to themselves and their colleagues.

    A surprising number of organisations choose to ignore their users entirely and build their websites entirely around an organisational perspective. This typically manifests itself in inappropriate design that caters to the managing directors personal preferences and content full of internal terminology and jargon.

    A website should not be about pandering to the preferences of staff but about meeting the needs of users. Too many designs are rejected because the boss doesn’t like green. Equally too much website copy uses acronyms and terms that are only used internally within an organisation.

    6. Design by committee brings death

    Illustration showing why design by committee fails

    The ultimate expression of a larger organisations approach to website management is the committee. A committee is formed to tackle the website because internal politics demand everybody has their say and all considerations are taken into account.

    To say that all committees are a bad idea is naive and to suggest that a large corporate website could be developed without consultation is fanciful. However when it comes to design, committees are often the kiss of death.

    Design is subjective. The way we respond to a design can be influenced by culture, gender, age, childhood experience or even physical conditions (such as colour blindness). What one person considers great design another could hate. This is why it is so important that design decisions are informed by user testing rather than personal experience. Unfortunately this approach is rarely followed when a committee is involved in design decisions.

    Instead, design by committee becomes about compromise. Because different committee members have different opinions about the design, they looks for ways to find common ground. One person hates the blue colour palette while another loves it. This leads to design on the fly when the committee instructs the designer to ‘try a different blue’ in the hopes of finding a middle ground. Unfortunately this can only leads to bland design which neither appeals to, or excites, anybody.

    7. You’re not getting value from your web team

    Whether they have an in-house web team or use an external agency many organisations fail to get the most from their web designers.

    Web designers are much more than pixel pushers. They have a wealth of knowledge about the web and how users interact with it. They also understand design techniques including grid systems, white space, colour theory and much more.

    Post from Twitter complaining about being a pixel pusher

    It is therefore wasteful to micro manage them by asking for ‘the logo to be made bigger’ or to ‘move that 3 pixels to the left’. By doing so you are reducing their role to that of software operator and wasting the wealth of experience they have.

    If you want to get the maximum return from your web team present them with problems not solutions. For example, if you have a site aimed at teenage girls and the designer goes for corporate blue, suggest that the audience might not respond well to the colour. Do not tell them to change it to pink. That way the designer has the freedom to find a solution which might be even better than your choice of pink. You allow them to solve the problem you have presented.

    8. A CMS is not a silver bullet

    Many of the clients I work with have amazingly unrealistic expectations about content management systems. Those without one think it will solve all of their content woes, while those who do have one moan about it because it hasn’t!

    It is certainly true that a content management system can bring a lot of benefits. They…

    • reduce the technical barriers of adding content,
    • all more people to edit and add content,
    • facilitate faster updates,
    • allow greater control.

    However, many content management systems are less flexible than their owners wish. They fail to meet the changing demands of the websites they manage.

    Website managers also complain that their CMS is hard to use. However, in many cases this is because those using them have not been given adequate training or are not using it regularly enough.

    Finally, a content management system may allow for the easy updating of content, but that does not ensure it will be updated or even that the quality of copy will be maintained. Many content managed websites still have out of date content or are filled with poor quality copy. This is because the internal processes have not been put in place to support the content contributors.

    If you are looking to a content management system to solve your site maintenance issues you will be disappointed.

    9. You have too much content

    Part of the problem with content maintenance on larger corporate websites is that there is too much content in the first place. Most of these sites have ‘evolved’ over years with more and more content being added. At no stage has anybody ever reviewed that content and asked what can be taken away.

    Many website managers fill their sites with copy nobody will read. This happens because of:

    • A fear of missing something – By putting everything online they believe users will be able to find whatever they want. Unfortunately, with so much information being made available, it is hard to find anything.
    • A fear users will not understand – Whether it is a lack of confidence in their site or in their audience, many website managers feel the need to provide endless instructions to users. Unfortunately, users never read this copy.
    • A desperate desire to convince - Many website managers are desperate to sell their product or communicate their message. Text becomes bloated with sales copy which actually conveys little valuable information.

    Steve Krug in his book ‘Don’t make me think’ encourages website managers to ‘Get rid of half the words on each page, then get rid of half of what’s left’. This will reduce the noise level of each page and make useful content more prominent.

    10. You are wasting money on social networking

    I have been encouraged that increasingly website managers are recognising that a web strategy is about more than running a website. They are using tools like Twitter, Facebook and YouTube to increase their reach and engage with new audiences.

    However, although they are using these tools, too often they are doing so ineffectively. Corporate twitter accounts and posting sales demonstrations to YouTube miss the essence of social networking.

    Social networking is about people engaging with people. Individuals do not want to build relationships with brands or corporations. They want to talk with other people. Too many organisations are throwing millions into facebook apps and viral videos when could be spending that money on engaging with people in a transparent and open away.

    Instead of having a corporate twitter account or indeed even a corporate blog, encourage your employees to start tweeting and blogging themselves. Provide guildelines on acceptable behaviour and the tools they need to start engaging directly with the community that surrounds your products and services. This not only demonstrates a commitment to your community but also a human side to your business.

    Screenshot of Microsoft's Channel 9 website

    Conclusions

    Large organisations do a lot right in the running of their websites. However, they also face some unique challenges that can lead to painful mistakes. Resolving these problems will involve accepting mistakes have been made, overcoming internal politics, and changing the way you control your brand. However, doing so will give you a significant competitive advantage and allow your web strategy to become more effective over the long term.

    For more information on how you can make your site more effective read the Website Owners Manual or discuss your site with Paul personally.

    There is a followup to this post entitled ‘10 ways to battle site bureaucracy.’ Check it out!

    Video: Introduction to WCAG 2

    Posted in Accessibility on by Paul Boag

    I recently gave an internal presentation at Headscape about WCAG 2. A number of people expressed an interest in seeing it so I made a point to record it.

    At the end the presentation I references a stripped down version of the guidelines found here.

    I also refer to a quick reference guide to WCAG 2 that can be found here.

    Apologises

    Apologises for the poor audio quality of this video. Unfortunately the decision to record the presentation was made at the last minute and so we didn’t have a proper mic setup arranged. You can also tell it is not quite as slick as my normal presentations :)

    I would also like to apologise for the lack of transcript of this video. Again, it was not my initial intention to put this video online as this was an internal presentation containing my initial thoughts on WCAG 2. I am still learning a lot about the new guidelines and will publish a more considered article when I have a better understanding of the subject.

    Feedback

    On that subject, I would be interested to hear your feedback on the thoughts I present. Do you agree with my interpretation of the new guidelines? Have I misunderstood anything? Are there other elements I should have addressed? Your thoughts would be appreciated in the comments.

    Update: We now have a transcript!

    Thanks go to Anna Debenham who braved the horrendous audio to transcribe the presentation. If you cannot face the video we do at least now have a written version!

    Paul: Ok, this has worked out a little bit weird because the idea initially with this presentation was that it was really about bringing us up to speed with WCAG2 now that WCAG2 has been released. But I made the mistake of mentioning it online and several people said "ooh, can you record that?" so now it’s a little bit of both, a little bit of a presentation to you guys and a little bit of a presentation that will go on the web.

    Paul: So as you guys probably know, WCAG2 has now been released, and as accessibility is a big part of what we deliver and we talk a lot about accessibility, we need to be up to speed on it and we need to know what we’re doing. Obviously accessibility has become such a part of what we do day in and day out that we don’t necessarily think too much about it, it’s almost an intrinsic part of what we do, but with changes to WCAG2, or with the arrival of WCAG2, there have been differences, changes, things that have altered, so I want to make sure that everybody is up to speed with it. Feel free to butt in with questions, that’s absolutely fine.

    Audience: Will the video be able to see the screen?

    Paul: The video will be able to see the screen. Ok, so, WCAG2. Basically, WCAG1 came out in 1999 which is a good old time ago, in Internet terms that’s like forever, and there was a real need to make some changes and improve WCAG1. Let me just pop back and just explain.

    The Journey to WCAG2

    Paul: So, yeah, like I said, WCAG1 came out in 1999, it quickly dated as technology evolved, and some of the guidelines actually became harmful in a way. So you guys know that for example, we don’t always take note of what they say about Access Keys, we don’t always take note of what they say about "make sure you put text in an empty form field" and things like that. And WCAG1 was very much built with HTML in mind, and obviously the web is a lot broader than that and there are a lot more formats about. But unfortunately development of WCAG2 was very slow, and also fraught with controversy. I mean, famously with Joe Clarke who is an accessibility expert wrote on A List Apart "to hell with WCAG2" because it basically had become a bit of a joke, because it was very generic; they were trying to write a set of guidelines that really made no effort to mention specific technology because they didn’t want it to date like WCAG1, but the result is it became unreadable and nobody could understand it.

    WCAG2 Reborn

    Paul: But, things did change. Major changes were made to the WCAG2 draft and things did improve dramatically. They really listened to the community, and the language in it now is much clearer. So what I want to do now is talk a little bit through what WCAG2 includes and what it doesn’t, and how we’re then going to go about implementing it and how it affects us.

    Principles

    Paul: Ok, so let’s look at the structure of WCAG2. Basically WCAG2 has 3 tiers to it that you need to know about. Tier number 1 is the idea of Principles. So this is kind of the most generic of the tiers, you know, it’s really kind of aimed at the kind of things you would tell a board of directors that doesn’t really understand anything technical, that doesn’t really understand accessibility at all. And there are 4 principles which are the foundations of web accessibility and these principles I’ll come onto a little bit later.

    Guidelines

    Paul: Underneath each of those principles are Guidelines. So, within each principle there are 3 or 4 guidelines or a number of guidelines that is different for each principle. But there are a total of 12 guidelines, and these are goals that you should be working towards in order to make your content more accessible to users.

    Success Criteria

    Paul: Under each guideline, there are Success Criteria. So now we’ve really hit the nitty-gritty, these are kind of specific, measurable goals that you’ve got to achieve. And this is how you judge whether your site is WCAG2 compliant, if you like. So, this is the really important level if that makes sense, but it’s organised within this hierarchy of guidelines and principles.

    Techniques

    Paul: Now, actually, there is kind of a 4th tier as well which is techniques. So you’re trying to, maybe as designers, you’re trying to conform to the Success Criteria, well there’s a whole load of different ways and different techniques that you can do that and you could read about those, and you could make up your own techniques if you wanted to, but there are some laid down that can help you get going.

    Working with WCAG2

    Paul: So those are the 3 levels that WCAG2 is built around. Now let’s dive into those a little bit. I had to think about how much detail I want to go into in this room. Obviously we don’t want to go into every technique that you could possibly apply and we don’t even want to go into necessarily every success criteria. That’s really for you guys to look through afterwards. What we are going to do is look at those guidelines and those principles, and hopefully help you to understand where WCAG2 stands over stuff.

    Perceivable

    Paul: Ok, so, the first… heh, totally illegible text, isn’t that great. Very accessible!

    Audience: (laughter)

    Paul: So the number 1 principle is Perceivable, and that’s 1 of your 4 principles that you’ve got here. And perceivable is basically talking about "information and user interface components must be presentable to users in ways that they can perceive"

    Audience: (laughter)

    Paul: Unlike that! (points to presentation)

    Audience: (laughter) Is the rest of the presentation like this?

    Paul: Yes.

    Audience: (more laughter)

    Paul: You actually don’t need to read this anyway which is very useful. So, Perceivable is basically about "can you see it?", that is it as far as the principle is concerned, and the answer is "no you can’t". But perceivable then breaks down into a series of guidelines. So, let’s have a look at what these guidelines are. So basically, perceivable is broken down into 4 guidelines. And if we talk through each of those it should give you an idea.

    Text Alternatives

    Paul: The first one is text alternatives. So this is stuff we already know. "Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language." So this really applies to things like video, audio, forms that you create, and interestingly CAPTCHA is particularly mentioned here. And that is a particular accessibility problem that hasn’t been particularly well solved I don’t think.

    Time Based Media

    Paul: The next way that Perceivable works itself out is in time-based media. What we’re talking about here is that you need to provide an alternative for anything that is time-based. So here we’re talking about captions for video, sign-language maybe, media alternatives, but it also applies to live and pre-recorded video. So if you’re streaming stuff, then you need to think about this as well as with stuff that’s pre-recorded. Now, it does take into account the difference between "crap, how are we going to make streaming video accessible?". If you read into the guidelines it does give some good advice there. So that’s not quite as scary as it first sounds.

    Adaptable

    Paul: Anything that we produce needs to be adaptable. In other words, content can be presented in different ways. For example, a simpler layout maybe for people with cognitive disabilities for example. Really, this boils down to things like using semantic markup, meaningful order in your HTML so that if the CSS is stripped away it still makes sense in the order that it is presented, and not relying on colour and other sensory elements to convey information.

    Distinguishable

    Paul: And then finally it’s got to be distinguishable. So it’s about making it easier for users to see and hear content including separating foreground from background and that kind of stuff. So we’re talking here about contrast, colour, and control over things like audio and video, that kind of stuff. So that’s where we’re at with perceivable.

    Operable

    Paul: Let’s move onto the next principle which is Operable. So, Operable is about user interface components and navigation, and making them easy to use so that somebody can use them whatever disability they may have. So this again breaks down into 4 different guidelines, the most obvious of which is Keyboard Access. So everything that we produce has to be accessible via a keyboard. So, for example, the Flash video that we’re currently creating for the Wiltshire Farm Foods home page needs to be keyboard operated, alright? Which I bet it isn’t at the moment! And to be fair, it’s part of production, I’m sure they’d put that in at the end if I hadn’t reminded them. That existed under WCAG1, so there’s nothing different there. So everything needs to be keyboard accessible.

    Enough Time

    Paul: You also need to provide enough time for people to take in the information that they’re being presented with. So giving the ability to pause, stop and control time based material is really important as well.

    Seizures

    Paul: You’ve got to take into account seizures, some people can have seizures triggered by animation and that kind of thing, so there are various limits that the guidelines lay down about flashing objects and stuff like that.

    Navigable

    Paul: And then finally it’s got to be navigable. So this includes things like skipping content, having descriptive page titles, tab order, links that make sense out of context, lot’s of headings, that kind of stuff. Is this all making sense?

    Audience: Yes, apart from time-based media, I don’t understand that.

    Paul: Time-based media, we’re talking about video and audio. So let’s say you had… one of our podcasts. So, there are certain things we need to ensure. One is that it is operable, in other words, a user can pause the podcast if we get annoying, or they want time to take in the information that we’ve said, but the other thing is that we also need to provide an alternative way of them getting it which is why we provide the show notes that we do and the transcripts and stuff like that.

    Audience: Ok, well that kind of fits under Text Alternatives and giving it control so it’s under Operable… I just don’t get where it is under perceivable, as a perceivable thing, it has to be perceivable?

    Paul: Yeah, basically.

    Audience: Video, audio… all has to be perceivable then?

    Paul: Yes. Some of these principles and certainly some of the guidelines do overlap to some degree. But when you draw down to the Success Criteria level, of how you actually apply these things, then there are more specific techniques. I think what they did is create a load of success criteria, and then kind of chunked them together in meaningful groups, but sometimes they’re not so meaningful. But it is a vast improvement on WCAG1 as far as being able to understand it.

    Understandable

    Paul: Ok, talking of understanding it, our next one is Understandable. So this is the next one of our 4 top-level principles, so everything you produce has to be understandable. So what does that mean? Well that results in 3 guidelines. It has to be Readable, Predictable and has to be able to provide Input Assistance. So how does that work itself out in practice?

    Readable

    Paul: With Readable, we’re talking about making content readable, text content mainly. So this works out in things like setting the language in your HTML, you know, setting what the language is in the header, avoiding using jargon, finally we’ve got a decent reason to go back to clients and say, you know, "you can’t use that kind of language, nobody understands it!". Also things like abbreviations need to be explained, and also reading level as well, and that’s something I really want to get through to a lot of our clients because a lot of our clients, especially the public sector clients that we have, have this attitude of "well of course, people that look at our site are of post-graduate degree people, and they have excellent reading level", but that doesn’t take into account things like people that speak English as a 2nd language, who can be very intelligent but not particularly good at reading, also people with Dyslexia can be incredibly intelligent but not particularly good at reading. So reading level is an important aspect of it.

    Predictable

    Paul: For it to be understandable it also needs to be predictable. So with this we’re talking about things like consistent navigation, and no uninitiated changes. And this is a particularly important one in our world of AJAX and JavaScript and all this cool stuff that we’re doing where we can often trigger events without asking the user’s permission first. When I say "asking for permission" I mean they haven’t clicked on link or they’ve not initiated it in any way. Users need to initiate these actions… and no pop-up windows without them clicking first to trigger a pop-up and being aware of what’s going to happen. It’s all about making it understandable and making them aware of what’s going on.

    Input Assistance

    Paul: The last guideline under Understandable is Input Assistance. So this is going into the realms of when we do forms, how do we handle errors, what kind of feedback do we give to the user, what labels – are things clearly marked up as labels, are they descriptive of the fields and the forms and that kind of stuff. We’re also talking about help, what additional help are you provided in terms of tool tip and contextual help and anything else that you care to mention. So that’s Understandable, that’s what that principle is driving at.

    Robust

    Paul: The final principle is Robust. "Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies." In other words, what we build has to work on everything.

    Audience: What about AJAX?

    Paul: I think that’s where we get into the realm of progressive enhancement, that it’s fine to use something like AJAX as long as, if the AJAX is taken away, it still operates. Or, you provide an alternative version, the guidelines do actually accept that you can do alternative versions of something. So Gmail is a good example of that, Gmail, it actually doesn’t work if AJAX is turned off but they do provide an HTML only version of it which does the same thing. I’m not a great fan of that because it’s twice as much stuff to maintain, and one version become out of date and all the rest of it. My preferred technique is to build it so it works normally, and then to layer on the JavaScript and AJAX on top of it to provide enhanced functionality, which is what we guys have been doing pretty much all along and we need to continue in doing that.

    Compatibility

    Paul: So that Robust principle actually only comes down to one guideline which is Compatible, so that’s about maximising compatibility with current… listen to the wording of this… Maximise compatibility with current and future user agents, so we also need to be looking forward as well and predicting the future which is always good. But that’s where it comes back to using solid, good code that is’nt reliant on lots of hacks in order to get it to work, and it goes back to the conversation that we’ve been having recently about browser testing, upgraded browser support and that kind of stuff as well. So Compatibility and Robustness is the last principle. The other thing I should have mentioned with Compatibility is this also includes things like validation, making sure that your code validates, and just generally other markup type stuff.

    What, no AAA, AA, A?

    Paul: Ok, another thing that might have occurred to you is AAA, AA, A.. Priority 1, 2 and 3. Priority 1, 2 and 3 are still there, there are still those levels of conformance, but I get a real sense from the tome of this document, and this is just my personal opinion, people watching this video who know a lot more about accessibility might jump all over me on this, but my sense is that they were playing down those 3 levels of conformance. To be honest, I think I’m pretty keen on that. I don’t think those levels of conformance have done a lot of good generally speaking, because I think it’s kind of developed a checkbox mentality amongst some of our clients "We must be AA compliant" or "We must be A compliant" and they’re not actually thinking about the needs of the users, they’re just ticking the boxes so they meet some quota that has been established somewhere. One of the things that’s quite interesting, and I’m not sure if it’s a change from WCAG1 or not, I couldn’t find the reference in WCAG1 but again someone will correct me no doubt, but conformance in WCAG2 seems to be on a page-by-page basis. So you’re no longer in a situation where you want to claim conformance so you’re claiming conformance for an entire site, but you’re rather conforming on a page-by-page basis. And this allows you to basically pick-and-mix the level of conformance you want to reach on any particular page which is much, much more sensible because there are some elements where you might be building a particularly complex application that really isn’t going to manage being AAA compliant, whereas the rest of the site is AAA, and this one page isn’t. So it’s giving you the ability to mix and match. In fact, in the guidelines it says "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content. In other words they’re saying it’s just not possible to be AAA in some situations, so don’t even try.

    Start With Basics

    Paul: So how does this relate to what we do on a day-to-day basis? Well, I think the language we use with our clients pretty much will remain consistent with how it was with WCAG1 which is that we need to start of by encouraging all our clients to start with the absolute basics. A lot of people are put off of accessibility because of the enormity of it, of all the things they’ve got to do. And even to be single A compliant there is quite a lot to do if you’ve got a site that has never been built to be single A compliant before. So I think our attitude has got to be that you work towards this over time, it is an ongoing process, you don’t need to do it all in one big go and that you need to start with the absolute basics, the quick wins, the stuff… you know, it’s the 80/20 rule, 80% of the problems that people are going to encounter from an accessibility point of view is caused by 20% of the accessibility issues if that makes sense. So we can solve a small number of issues but have a big impact on the site. So we’ll start off with some real basic stuff. Things like putting in "alt" and "title" attributes, providing alternatives to media, things like video and audio, being aware of JavaScript and the problems that JavaScript can create if it’s not implemented correctly, providing resizable text so that the user has the ability to either increase or decrease the text size on sites, to build everything to be standards based because that makes it so much easier in future.

    Audience: Aren’t we moving away from resizable text?

    Paul: We’re moving away from the resizable interface where the whole thing scales up and down, but there’s no reason why we can’t keep the text itself rescaleable. The layers should be able to push up and down. It has to be said with resizeable text, it is becoming less of an issue. The reason it’s becoming less of an issue is because browsers now have this zoom functionality built into them. But I don’t think we’re quite there yet to be able to drop resizable text entirely is my current feeling… I’ve got mixed feelings about it. But the obvious aim we’re going for here is to be single A compliant.

    Build Over Time

    Paul: So all of this is about building accessibility over time. Taking the guidelines by themselves is not going to be enough, and taking this checkbox mentality that I talked about earlier is not going to be enough. Once you’ve done these quick fixes, the next step on from that is to start consulting with your community. We need to encourage our clients to start talking to their users and find out what accessibility concerns they have. I also think, which I think we’re quite poor at, that we need to start testing with real users some of the accessibility stuff that we do, and the big problem there is persuading clients to pay for that. It’s really hard to get clients to pay for that kind of testing but I do think that it’s a really useful thing to do, and there are organisations out there that provide people you can get in to do testing, or that you can send sites out and they test with them. So, testing with real disabled users is really worthwhile. I think it’s about identifying major issues and dealing with those first, just pragmatic kind of prioritisation of issues, something you do with usability. With usability you look for the quick wins and the showstoppers and those you deal with first, exactly the same with accessibility. Now, what the major showstoppers are for those navigating the site need to be dealt with. And over time you build towards AA and AAA compliance if you can. But you only do that maybe on some pages. The big concern clients have and the reason they get into this check-box mentality of saying "we’ve got to be double A or we’ve got to conform to the WCAG guidelines" is fear, a fear of litigation. Especially our bigger clients, they’re really worried they’re going to get serious issues. But I think it’s important to stress with clients that litigation doesn’t happen overnight. You don’t suddenly have come through the post a writ saying "you need to come into court about this accessibility issue on your site". It doesn’t happen like that. What happens in reality is the user complains. And if the user is repeatedly not heard and not listened to, and not responded to and not cared about and rejected, they get angry enough to maybe approach someone like the RNIB who then take it on into litigation for them. That’s the reality of what happens.

    Quick Response

    Paul: So as a result, you can diffuse that by responding to complaints quickly. So as you’re building up over time with the accessibility policy, if someone does complain, you need to write back to them and you need to deal with that issue straight up. Ok, so that’s how the client should be dealing with all this and there’s loads more I could say on this but I don’t want it to go on forever.

    Headscape’s Approach

    Paul: Let’s briefly talk about Headscape and our approach and how we should be approaching the subject of accessibility.

    Establish Approach With Client

    Paul: Well first of all I think everything that we do in our approach should be in conjunction with the client. I don’t think necessarily we talk enough to the client about accessibility. Some clients are just so bamboozled by it that they want us to take control, others want a say in it and what to be reassured that we’re doing something about it. So I think there’s a dialogue that we need to make sure happens. And if a client just wants us to take control of it, that’s great. If they want to be involved in the process, then that’s great to but we need to engage with the client and talk to the client more about it.

    Remain Pragmatic

    Paul: The second thing and I think this is really important is that we need to remain pragmatic in our approach to accessibility. Everything I’ve been talking about before like building up accessibility gradually, about doing the quick wins first and the show stoppers and that kind of stuff, that’s all pragmatic. I don’t want us on one hand to ignore accessibility, and it needs to be an integral part of everything we do, but on the other hand you can become extremist about it. We could spend hours and hours trying to get something to work in every conceivable user agent in the world and we can worry about every type of disability to the point where it becomes like a paralysis that stops us actually doing anything. So there’s a real balance that we need to strike here. And we need to strike that with our clients and working with our clients.

    Have a rationale

    Paul: Now I think it’s worth saying that if we decide not to comply with a guideline for whatever reason, we need to have a rationale for that. So we might not conform even to single A compliance in certain situations, although to be honest I can’t think of any off the top of my head, but if we do decide not to conform, we need a damned good reason why not. In other words, we need to have thought about it. And the other thing about accessibility is that we always think about it at the end of the project. It’s too late by then, we’ve built everything. So it really needs to become an intrinsic part of everything that we do.

    Responsibilities.

    Paul: Let’s talk about the idea of responsibility here and whose responsibility accessibility is within Headscape. Basically I’m going to say, everybody. One of the absolute great things about WCAG2 is because it’s got this 3 tiered approach, it is "accessible" to everybody. It’s understandable by everybody. So therefore it can be everybody’s responsibility to keep an eye on accessibility. And so this is how I think it should split down.

    Sales/Client – Principles

    Paul: Marcus and Chris and the Client should be worried about principles. The Operable, the Perceivable, those basic top-level principles. And you should be looking at anything that goes out from the company and going "well is that really operable?" So you can take a very top-level approach to it. And I think as you talk to clients as well you take this very top-level approach to it. That’s the level you guys should be working at.

    Guidelines – Project Managers

    Paul: Project managers, I think you need to be looking and understanding from the guidelines point of view. So you need to go in and read what those guidelines are, and you need to be sure that you understand them. And as you look at any work that goes out from the company, you need to be thinking "does it conform to those guidelines?" You don’t necessarily care about the nitty-gritty of how those are measured, or the nitty-gritty of how they’re achieved, but has that guideline been met? That’s the level you need to be working at.

    Success Criteria – Designers and Developers

    Paul: Then when it comes to the designers and developers, you need to get right into these guidelines. And you need to understand the success criteria and how to apply the guideline and how to make them work in practice.

    Check Everything

    Paul: So basically, we need to be checking everything that goes out the company for accessibility. And I have to say I’m making the mistake of saying this on camera, but I think we’ve got a bit lax recently when it comes to accessibility. We reached a point where it was becoming quite intuitive to us, and we were doing it quite naturally, and then as a result of that, we stopped checking because it was the natural process of what we were doing, and then bad habits start to seep in again. So WCAG2 is a great opportunity for us to say "ok, we need to start reviewing everything we’re doing as it goes out again". So I’d really, really encourage you to check everything.

    Needs to be second nature

    Paul: basically we need to get to the point where this is second nature to us, so that we’re doing this intuitively again, but not to the point where we’re no longer checking.

    Audience: Clients often say "what’s the difference? If I just got for single A compliancy, what won’t my site be reaching?"

    Paul: I have to say that I think I would stop talking about double A, triple A and single A compliancy. I don’t think there’s really any value any more in talking about that to the clients.

    Audience: I think there is because having the page by page conformance is a really good thing and that we can now argue that yes, we can now make the majority of your site triple A compliant, but for a page full of videos, we can make it single A compliant.

    Paul: Ok

    Audience: Clients will continue to reference it in briefs. You can’t not talk about it.

    Audience: I think it’s actually quite a strong thing.

    Audience: is it a page by page compliance, or template by template compliance?

    Paul: I think it has to be page by page because the content that goes into the page, into the template, could invalidate it. This is why I think it’s something that should be downplayed. I accept the clients will still talk to us about it, but clients still talk to us about doing speculative design, it doesn’t mean we do it. I think there’s an education thing there whereby we need to move clients away from being obsessed by double A, single A compliance, and to start thinking about accessibility policies. What is there accessibility policy and what is it that they are trying to achieve on their site? Our base mark is going to be single A, it’s always single A, and I think it should continue to be single A.

    Audience: but if you don’t talk to them about it, you could argue that less caring clients would just say "well why would I do anything about it, bottom line?"

    Paul: Yeah, I said you shouldn’t talk about single A, double A, triple A, but that doesn’t mean you can’t talk to them about accessibility and the improvements that accessibility brings because for people that have got that sort of attitude you don’t want to talk about the disabled if they don’t care about the disabled, you talk about search engines, and that’s the best way to sell accessibility, by talking about search engine placement. That’s the reason you want to be accessible for people who have that kind of attitude. For those that care, and are talking about single A, double A and triple A, you need to say to them "well actually, conforming with any level, it’s great that you want to do accessibility, and certainly single A should be an absolute minimum, but we’d encourage you to start working up an accessibility policy and looking at your site as a whole and say could this area do more in your site, your accessibility policy should do real world testing with real users…" all kinds of things.

    Audience: So you think that we should be encouraging large organisations that have accessibility policies themselves that refer to double A, triple A, to try and persuade them to kind of move away from that?

    Paul: No, not necessarily, I wouldn’t go that far. Don’t get me wrong, I’m not saying that they’re a bad thing, I’m saying they’re not the be-all and end-all. And at the moment I feel like the vast majority of clients think they are the be-all and end-all. They’re obsessed with putting that little badge on the bottom of the page. And it’s not about putting badges on the page. The trouble with institutions that have these policies of single A, double A and triple A is that these policies are in place for the institution, not for the user. And that’s my problem with them. That’s why I think we should try to break that mentality with clients. And I accept that sometimes we’re going to lose, and that’s fine. Exactly the same goes when we were talking about browser support. I accept sometimes we’re going to lose that battle as well. But it doesn’t mean we shouldn’t try and fight it.

    Audience: I just wondered why WCAG2 still does it, because yes, you’re right basically, and accessibility requirements should be based on user requirements and not ticking boxes, so why is it still in there?

    Paul: I think it’s in there because… my impression… I hate talking about accessibility on camera! You remember what happened last time in the podcast? It was just a nightmare! I think the reason it’s still in is because some of those success criteria are hard to meet. Some of them are damn difficult. When you start talking about streaming video, you’ve got some difficult challenges there that need to be met. So I think as a result, what the W3C is saying there is that we accept that some of these things are difficult to do. And we accept that you’re not always going to be able to do them, so we’re going to make them triple A. But come on guys, some of this stuff is dead simple and we should be doing it, that’s single A. That’s my impression of the mentality behind it, and that’s a great mentality, but it’s when someone changes that to being guidelines, which is what they are, to being rules, really instilled by Moses and presented to the people. You know it’s not that and I think that’s an important differentiation to make.

    Where to Start

    Paul: I know what you guys are like, especially designers. Ok I’m making sweeping generalisations here. But, if you guys go along to the WCAG website and you look at the WCAG2 guidelines, it’s horrible! It’s intimidating and it’s scary and it goes on for pages. And there’s a lot of text around it.

    Audience: There’s no pictures? (laughter)

    Paul: There’s no pictures! The design isn’t even very good. So what I’ve done is I’ve taken that page, I’ve literally all I’ve done is I’ve stripped out the explanation text in front of it, and the waffle at the end of it, and I’ve left you with just the set of guidelines so it looks like a slightly less intimidating list. Not much but slightly. So that’s up at http://www.headscape.co.uk/WCAG2 so if you go to that, you can get just the actual list of criteria. There’s also, on the WCAG2 website, there’s a thing where you can go and you can say my site uses tables, my site uses video, my site has this and that, and you untick the ones that it doesn’t have and it narrows down the list of success criteria to only show you the ones that you need to care about. So you might want to check that one out as well. Ok, so that’s basically all I have to say, are there any other questions before we wrap up?

    Questions

    Audience: Clients are going to ask us the 1 minute elevator pitch. What’s the difference between WCAG2 and WCAG1? What would you highlight as differences?

    Paul: I think there’s a bigger acceptance of things in the world other than HTML, so things like Flash, PDFs, all that kind of stuff, there’s much more reference to that kind of thing. It’s much better written, much better organised. I think it’s more pragmatic. It’s a little bit more… I think it will last the test of time more. It’s hard to pin down exactly what I mean by that. There is actually a document out that talks about the specific differences between WCAG1 and WCAG2 if you wanted to get into that level of detail. And to be honest, I couldn’t tell you what that is yet because I haven’t looked at it in that much depth myself.

    Audience: I think you and I do need a couple of the more detailed stuff, to get the guidelines, just one or two examples basically. Something that’s new between WCAG1 and WCAG2, and also some of the differences between single A, double A and triple A. The streaming video is an excellent example.

    Paul: Just go along to http://www.headscape.co.uk/WCAG2 and you’ll be able to see those different levels.

    Audience: It seems like, an almost unwritten principle, or unwritten in your list of principles. It’s technology agnostic.

    Paul: WCAG2 started off as so technologically agnostic that it wasn’t understandable.

    Audience: WCAG1, the first line is all about "it must be W3C technologies".

    Paul: Yeah, it will pretty much accommodate anything. You know, it talks in terms of audio and video. It doesn’t mention Flash for example specifically, at least I don’t think it does, but it refers to those kinds of things. It refers to documents that are not HTML. I’m saying this as much for the video as anything else, I’m still learning about it as well. So I think it’s going to be a learning process for a while for us to really get to grips with this, and truth be told we probably should have started a little sooner than this, but it’s not radically different from WCAG1. This is as much getting us back into the habit of thinking about accessibility as anything else really. Ok?

    Audience: 1 more question. Are they new Keynote animations?

    Paul: Yeah, they are new Keynote animations.

    An interview with Freelancer Magazine

    Posted in News on by Paul Boag

    I have just finished an interview for Alex Stubbs over at freelancermagazine.com. Being a clever cookie he massaged by ego and convinced me to take part even though I am on a family holiday in Scotland.

    I hadn’t come across Freelancer Magazine before, but it certainly looks like a superb site. If you are a web design freelancer or are considering making the swap then definitely check it out. It has great features, useful resources and of course star studded interviews!

    But before you disappear over to their site take a look at the interview.

    Thank you, Paul, for taking the time to speak with us.

    Absolutely!

    So how are you enjoying your vacation in Scotland?

    Scotland is one of the most majestic places in the world. At least if it isn’t raining. I have found it incredibly inspiring being out of the office and away from the web. I have achieved so much more here because I am free from distractions.

    Getting to the meat of our discussion is your weekly podcast on Web Design, which is to date the longest running and most popular web design podcast.

    I believe you started this in 2005 and it has been gaining more and more recognition since. How do you feel this medium has served you and your web presence over the years?

    I was very fortunate to stumble into podcasting. I started out blogging but found that hard work. I love writing but find it much harder to express my enthusiasm and excitement for a subject. Podcasting was a natural fit for my personality.

    I doubt you would not be interviewing me if it wasn’t for the show. It has done a huge amount for my personal profile and that of my web design company Headscape. It is also what has enabled me to write the Website Owners Manual too. I doubt any of that would have happened if I had just stuck to blogging. There are simply too many blogs around. You need a way to stand out from the crowd and in my case that was through podcasting.

    Any future plans for video podcasting?

    I have thought long and hard about video podcasting and yet I do not have an answer for you. On one hand video podcasting is hugely popular and an enormous growth area. It would also enable me to show code and designs. This is something that constantly frustrates me about audio podcasts.

    However, on the other hand I am aware that many people listen to my show while walking the dog or commuting to work. You cannot watch a video podcast in such circumstances. Video demands your attention in a way audio does not.

    Probably at the end of the day it will come down to return on investment. Doing a full blown video podcast is a lot of work. Unless we can make it pay for itself I doubt it will happen. For now people will have to be satisfied with the audio show and the live ‘behind the scenes’ video stream.

    You also have a new project in the works which has gone live recently on boagworld.com: “The Website Owners Manual.“ Which from what I’ve read seams to be an evolving manual for anyone interested in running a successful website (from start to finish)….

    I am really excited about the Website Owners Manual for a couple of reasons. First, there are so few books aimed at website owners or managers. They are all aimed at designers and developers. However, the client is key to the success of a project and there are certain things they need to know. Second, I am excited by the way this book is being produced. Instead of simply being published, this book is evolving through social participation. You can get access to chapters right now and have the opportunity to comment on and contribute to those chapters. I collect your feedback and adjust what I am writing accordingly. At the end of the process you get the final product. Its publishing 2.0… or something like that .

    Sounds very progressive! Here at FM the bulk of readers seem to be beginning freelancers who themselves will need to know a bit of knowledge you’ve outlined in this manual… what points do you think this book would be most important to our readers?

    I think the main thing will be how to better communicate with clients. The problem with most people who choose to start freelancing is that they under estimate the challenges of dealing with clients. You might be the best designer or developer in the world, but if you cannot deal with clients effectively you will fail. The website owner manual shows you what clients need to know and demonstrates ways of presenting that information to them.

    So you’re the Creative Director at Headscape, you run a weekly podcast, you speak at numerous web design and marketing conferences, and still find the time to write a book. I think even David Allen himself would be proud… whats your productivity secret? Whats your daily life like?

    I am a huge fan of David Allen and follow the Getting Things Done methodology closely. However being organized is only half the battle. The other half is recognizing what you are good at and sticking to that. I know I am an ideas person. I am great at starting stuff and terrible at finishing it. I therefore surround myself with people who are good at following through.

    At Headscape I have three fellow directors who are expert at managing me to be at my most effective. They bring me in for short bursts of activity when a load of ideas are required and then quietly push me to the sidelines when the REAL work begins.

    With the podcast, I rely heavily on the community to make it happen. There are people who transcribe the interviews, moderate the forums and even produce the show. There is Paul Stanton who helps me source news stories. Ryan Taylor produces the show by organizing guests, writing show notes and much more. Finally there is Anna Debenham who is our technician. She edits interviews, manages the site and handles the RSS feed.

    These people all give up there time because they love the show. That makes me feel very honoured. I would be lost without them and feel guilty that they don’t get more out of it.

    You started out as a Web Designer and evolved into other areas since, I’m guessing mostly due to your success with your podcast. How was your early experience when starting out as a Web Designer?

    I started out designing for the web back in 1994. I was working for IBM producing CD-ROMs for the first generation of multimedia PCs. While doing this IBM decided to start taking the web seriously and so I got involved very early on.

    I was just a junior designer which was why I was given the web stuff. It just wasn’t important back then. My career ended up growing in line with the growth of the web. As the web became higher profile so did my job until eventually I ended up working as a creative director at a dot com company in the late nineties.

    Basically, I just lucked out. A lot of success is luck. The idea that successful people are in someway more talented or better is just not true. It is about being in the right place at the right time. That and having a big mouth and being willing to shout about how good you are!

    What advice do you have for those looking into starting out as a Web Designer themselves?

    Wow that is a hard one. Its very different starting out today compared to my experience. That said, here is my gut reaction.

    First, know the basics. Focus on HTML, CSS and Javascript before anything else. Don’t get distracted by the latest fad or the more exciting trend. These are the fundamental tools you will always need.

    Next, find talented people you admire and get alongside them. Don’t be shy in approaching them. In my experience they love the attention!Follow their work, ask questions and look at who they follow and admire.

    Finally, get involved in the web design community. Go to meetups, conferences and other events. You will learn so much from your peers. Far more t
    han from a book
    or university course.

    Taking a brand online

    Posted in Design on by Paul Boag

    “and here is our style guide”… thump! A huge tome lands on the desk in front of you. When it is written entirely for print, how do you begin to turn it into something that will work on the web?

    Of course not all style guides are “huge tomes”. Some are nothing more than a logo and some colours. However, with only a few rare exceptions, they all tend to be written with print in mind. Sizes are set in millimeters and not pixels, logos don’t display well at 72 dpi and colours often just don’t work well on screen.

    Many designers feel that style guides limit their creativity, but I would argue that actually you have to be extremely creative to get some guides to work for the web! Below are 4 areas that can be particularly challenging and a few pointers about how I deal with each of them.

    Typography

    Style guides often set fonts and rarely are those fonts as universal as those found on the web. Generally speaking there is not much you can do about it except explain the limitations to the client. Normally speaking the client will accept the inevitable.

    However, once in a blue moon you come across a client who starts insisting. He talks about having headings as images so you can set the font.

    Although it is possible to work around the limitations of web fonts using techniques such as sIFR you also need to consider legibility.

    The trouble is that often the fonts selected in style guides are picked because they look good in print. However, not all fonts that look good at print resolution, work when reduced to the screen. They often pixelate and become difficult to read especially at smaller sizes.

    If you do use corporate fonts make sure they are used at a reasonable size in order to maintain legibility.

    Layout

    Layout can be another tricky area that is often included in a style guide. The guide might suggest a 3 column layout or stipulate the position of the logo. Although where possible it is good to stick with these recommendations, you should not do so when they conflict with web conventions.

    For example I recently worked on a project where the style guide specified the logo should be positioned top right. Unfortunately it has become a convention on the web to display the logo top left and the search top right. Both myself and the client agreed that conforming to this web convention was more important that sticking rigidly to the guidelines.This decision was made easier by the fact that we had stuck very closely to the guidelines in other areas.

    Another thing to be wary of in regards to layout is that guidelines often have a bias towards A4 portrait style layout. It also works on the assumption that you have pixel perfect control over positioning. Neither of these assumptions are correct when it comes to the web.

    In short I think guidelines about layout need to be taken with a huge pinch of salt. It is extremely hard to replicate them faithfully on the web and as long as other areas of branding are better represented then their absence will not damage the brand online.

    Logos

    Unfortunately, where you maybe able to get away with changes to layout, you rarely can when it comes to the logo. This can prove an incredible challenge when the logo wasn’t produced with the web in mind. A poorly designed logo can often become illegible when reduced down in size.

    Although I sympathize with designers who have to deal with “bad” logos, I would argue that a logo is so central to an overall brand identity (which extends way beyond the web) that changing it is out of the question.

    However, although you cannot “change” the logo as such, minor tweaks to correct poor web rendering is possible. I have been known to tweak font size, weighting and spacing in order to aid legibility at smaller sizes. I have also been known to make minor changes to colour which brings us nicely onto…

    Colour

    Gone are the days when we worried about the web safe palette. However, that does not mean we can now apply colour guidelines without a second thought. There are still 2 major considerations to take into account when working with colour guidelines.

    The first is the differences you see in how colour is displayed. I have spoken about colour display numerous times before so I wont repeat myself here. However, the fact that colour can often appear either lighter or darker on some monitors does mean that certain colours that look great in print (where its displayed is carefully controlled) will look terrible to some users.

    The only solution to this problem is to manually adjust colours so that they sit nearer the middle of the brightness range. Light colours are made darker and darker colours lighter.

    Another aspect of colour I have talked about before is colour bleed. This is explained brilliantly in a 24 ways article by Jason Santa Maria. In essence it means the smaller the text the more the colour of that text is influenced by its surrounding colour. Text on a white background becomes lighter and text on a black background becomes darker.

    Again in order to counteract this problem it maybe necessary to manually adjust the brightness of a colour when used on smaller text. You cannot rely solely on the pantone numbers supplied in the style guide.

    In conclusion

    The key to successfully bring a brand online is to pick and choose your battles. Keep in mind the ultimate aim, which is to associate the website with other marketing collateral in the minds of the target audience. Making this association does not require compliance with every aspect of a style guide. If you comply closely in some areas, this can give you more flexibility in another area without significantly damaging the brand.

    Standards: Work still to do

    Posted in Web strategy on by Paul Boag

    Apparently the battle over web standards has ended; it is certainly true that 68% of web designers seem to favour it. But do clients understand the benefits?

    As I have posted recently, apparently the “web standards war is won”. Indeed a recent survey on sitepoint.com seems to indicate that 68% of web designers who responded use web standards “most of the time”. Of course that still leaves over 30% who don’t. A recent thread on my forum drove home the point that many designers are still struggling with the subject. One poster wrote:

    Paul keeps talking about how the new method separates content from design this is to my mind a delusion and incorrect. Most true CSS designs are very much a compromise in this fundamental area. The only designs that truly manage to do this are in CSS text books like Andy Budd’s CSS Mastery or Rachel Andrew’s Standards compliant Web site using Dreamweaver 8

    However, convincing designers is not the whole battle. We also need to persuade clients of the benefits as well. Admittedly in many cases clients are led by us as designers. However, there are also a large number that want to maintain their site themselves and may not yet have been exposed to standards.

    Let’s be honest here. Standards are not easy. Working with tables is often the much simpler option and in many cases clients will be resistant to the change. However, it is the overwhelming business benefits that make it the right decision. The problem is that we often fail to communicate those benefits clearly.

    There is no shortage of articles and tutorials aimed at designers, helping them make the transition. However, there is very little aimed at business owners.

    In an attempt to help correct this balance I am making next week’s show entirely focused on the business benefits of standards. It will be aimed completely at web site owners and will hopefully put forward a convincing argument for the need to change. My hope is that those listening to the show, and indeed reading this blog, will distribute the presentation and make sure as many website owners as possible see it.

    Podcast 49: d.construct & web services

    Posted in Classic shows on by Paul Boag

    This week Paul reports from the d.construct 06 web conference and interviews the likes of Jeffrey Veen, Andy Budd, Ian Forrester and Jeremy Keith then endeavours to wade through the jargon to discover the real benefits to your business.

    Download this show.

    To subscribe directly within itunes click here

    The d.construct web conference was awesome. Anytime you get to meet up with other web developers and discuss the future of the web, it is sure to be an inspiring experience. Add to that a great line up of speakers and it is guaranteed to be a memorable day.

    I went to the conference knowing very little about web services and with some real concerns about their viability in a real business environment. However, a day spent chatting with other developers and listening to the speakers, not only educated me but also made me very excited about the potential.

    I spent most of the day interviewing, however only a fraction are used on the show. Audio quality was a constant battle and background noise a real issue. However, there is loads of great stuff and I have tried to piece it together in such a way that it introduces you to the potential of web services as well as providing you with a sense of the day.

    Also in the show…

    Also in this week’s show, we review the upcoming book releases from Friends Of ED with Chris Mills (their senior editor). We look at the target.com accessibility case, review a great article by Chris Heilmann and tell you everything you ever wanted to know about designers.

    50th episode next week!

    Next week’s show going to be entirely based on user submitted questions and comments. To take part simply send your question or comment to [email protected] or submit an audio comment via the odeo website. Remember, your question can be on anything you want, from web design to Marcus’ pop career! We look forward to hearing from you.

    Why IE doesn't play nicely

    Posted in Development on by Paul Boag

    As all web designers know, Internet Explorer is the thorn in our collective flesh. Even with the dramatic improvements in IE7, it still finds ways to annoy. However, the nice chaps at Microsoft have gone some way to soothing our fevered brows.

    Update: Thanks to all of you who pointed out that VMWare actually made their virtual PC free before Microsoft and Microsoft are just following suit. Kind of takes the edge off of my somewhat limited enthusiasm for the move!

    I have to confess I am generally a bit of a Microsoft groupie. Unlike most designers, I don’t hate windows. In fact, I positively love the new version of Office and think Microsoft has improved a lot as a company recently. However, Internet Explorer still manages to extract swear words from me that would make my mother blush.

    So if you are a web designer or web site owner looking to test your site on multiple versions of Internet explorer then head on over to the Microsoft Virtual PC website and download yourself a copy for free!

    I can live with the CSS bugs thanks to conditional comments. I can even live with the fact that IE doesn’t support any of the cool stuff in CSS. I console myself with the fact that IE7 is so much better. Although even here my patience is tested, as the third Beta seems to reduce my PC to the speed of a ZX spectrum (am I the only one with this problem?).

    No, what really gets to me is that you cannot run multiple versions of Internet Explorer together on the same machine. It sucks! I listened to Chris Wilson (lead developer on IE7) try to justify this travesty at the @media conference, but he did little to calm my hysteria. Although the reasons are all very logical, it does nothing to change the fact that I have to battle with this problem every day.

    Sure, there are solutions of a sort:

    I can download the hacked standalone versions of IE, cobbled together by other frustrated developers. However, although these are valiant endeavours, their consistency with the real version of IE is spotty to say the least.

    Alternatively, I could pay shed loads of cash and buy something like VMWare, which allows me to run multiple "virtual" versions of an operating system within windows.

    However at last Microsoft has shouldered some of its responsibility and made their version of VMWare (a product called Microsoft Virtual PC) free.

    So if you are a web designer or web site owner looking to test your site on multiple versions of Internet explorer then head on over to the Microsoft Virtual PC website and download yourself a copy for free! Obviously, having to install multiple versions of Windows isn’t an ideal solution but at least it works and with Virtual PC it is about as painless as possible to do.

    Podcast 34: The roles of the client and the web designer

    Posted in Classic shows on by Paul Boag

    Getting the relationship right between the client and web design agency can make or break a web design project.

    In this weeks show Paul and Marcus discuss the sometimes problematic relationship between web design agencies and clients. They also cover how the line between web pages and the browser have been blurred, the evils of speculative work and a great new book by Ian Lloyd.

    Download this show.

    The roles of the client and the web designer

    Getting the relationship right between the client and web design agency can make or break a web design project. Often both parties enter into a project with very different expectations of who will do what. This is partly because there is such a wide range of approaches adopted by the web design community.

    In this show Paul and Marcus discusses how clients can find web design agencies that suit their working approach and how to get the most value for money out of the agencies they choose.

    They also propose some general principles for improving communication between client and agency:

    Advice for clients

    Paul and Marcus suggest the following guidelines for clients:

    • Recognise that the success of your web project is as reliant on you as it is on the web design agency.
    • Don’t under estimate the time you will need to put into the project, especially when it comes to preparing content.
    • Try to avoid getting drawn into subjective design discussions. Rely on the expertise of your designer.
    • Always consider the bottom line and whether additional functionality will generate a return on investment.
    • Be willing to compromise and take on board the agencies advice.
    • Clearly state your expectations up front. Don’t presume the agency will approach the project as you would expect.
    • Remember, the customer is NOT always right!

    Advice for agencies

    The discussion then moved on to advice for web design agencies when working with clients:

    • Use the kick off meeting to clearly understand any expectations the client has for the project.
    • Remember it is the design agencies responsibility to educate and inform the client about what works well online. If a client fails to grasp the logic of your approach it is a failure on your part to communicate it effectively.
    • Recognise that designing a web site is about compromise. It is sometimes necessary to compromise design and usability for the sake of business drivers.
    • Pick your battles! The client is ultimately paying you to produce a great website so don’t be afraid to stand your ground when their opinion undermines that objection. However, know when to back down.

    Site evolution

    Finally, Paul and Marcus wrap up the discussion by touching on the subject of site evolution and the need to change the client/agency relationship from sporadic redesign to ongoing site evolution.

    For more on this subject see my site evolution post.

    Also this week…

    Also in the show:

    Next week Paul interviews Andy Budd, the author of CSS Mastery, to get his take on the state of web design.

    UK terror legislation hits website owners

    Posted in News on by Paul Boag

    Here in the UK new terrorism legislation has just come into force. Here are some thoughts on the possible effect on British hosted websites.

    Here in the UK new terrorism legislation has just come into force. Normally this is not the kind of thing I would post on. I am not a particularly political animal and this isn’t a politics related blog. However, this particular legislation has an impact on websites hosted here in Britain.
     

     

    Sections 3 and 4 of the Act enable a police constable to give written notice to an organisation that a particular statement they publish electronically is unlawful, because it relates to terrorism. If the organisation does not remove or amend the statement within two working days then it will be considered to have endorsed the statement and thereafter be liable to prosecution for encouraging terrorism or disseminating terrorist publications.

    Setting aside the debate as to whether government has the right to curtail freedom of speech, this does create some interesting scenarios.

    For example, let’s say one of you decided to post a comment on this site that was deemed by the British government to be inciting terrorism. Would it be my responsibility or the responsibility of my ISP to remove that statement? If it was my responsibility then there could be any number of reasons why I might be unable to remove the comment within two days. I would therefore be endorsing terrorism and liable to prosecution. Suddenly running a community based website or allowing others to contribute content to your site becomes a lot more risky.

    But that is not the end of the story. The Act also says that an organisation served with a notice is also required to take all reasonable steps to prevent future re-publication of the same or similar statements. This could in effect force some businesses off line. How would sites like MySpace deal with this? I suppose it depends on what “reasonable steps” means and how stringently they enforce this legislation.

    What is obvious is that there is certainly a lot of room for abuse. With a maximum sentence the same as that you would receive from carrying a gun in a public place (seven years), I doubt smaller website owners would be willing to risk a court battle, even if they could afford to. This effectively allows the authorities free reign in removing “undesirable content” from British hosted sites.

    I guess all of this might be worth while if it was actually going to be effective in the “war on terror” (whatever that means). Of course the reality of the web means that anybody who wants to incite terrorism can simply host their website out of the country. National legislation strikes me as being somewhat ineffective in this case.

    The cynical part of me is left feeling that this is just some PR exercise in response to the sporadic stories that appear in the British media about people learning to make a bomb over the internet.

    I wonder how long it will be before the British government will be joining China in forcing Google to remove certain content :)

    Web design podcast episode 4

    Posted in Classic shows on by Paul Boag

    On this weeks boagworld.com I am without Marcus due to various technical problems with Skype. However, we hope to have Marcus back with us next week so he can continue to show his ignorance then.
    Our main subject for this week is “how to improve your search engine rankings”.

    Play

    Podcast: Download (11.2MB)

    To download the latest podcast click here.

    Below is a brief outline of the things covered in this week’s podcast as well as links to some of the articles mentioned:

    Search engine optimisation

    Here are my pearls of wisdom ;)

    Part of a bigger strategy

    Remember your search engine optimisation work should just be a small part of a bigger marketing strategy. Search engine placement is not good enough by itself.

    Search engines are not all that!

    Search engines have their place but they also have their drawbacks:

    • Delays in seeing results
    • An unpredictable outcome
    • Need for constant attention
    • A passive approach to marketing

    Learn more about the problems with search engines.

    Consider quick fixes

    Because search engines take time to index new sites, consider using pay-per-click advertising until you gain the positioning you want from the main listings.

    Visit Google Adwords site

    Stay focused

    Make sure you have a clear focus for your website. Ensure your links, content and navigation are built around that focus and that you do not deviate from it. A lack of focus will dilute your ranking on your chosen keywords.

    Use web standards!

    For fear of going on about web standards, make sure the code you use is semantic. Your HTML should describe what content elements are, in order to tell the search engines what is important and what is not. For example how does a search engine know what a title is unless you give it a heading tag?

    Learn more about web standards.

    Don’t make the search engines work

    Although search engines can index PDF files and flash sites they cannot do it as well as they can index HTML. Therefore avoid using these plug-ins wherever possible in order to improve your ranking.

    Link popularity

    Encouraging others to link to your site is key to a successful SEO campaign. However, focus on the quality of links not the quantity. Ensure people that link to you are relevant to your subject matter and have a good page ranking.

    Learn more about link popularity

    News

    Dreamweaver 8 is out!

    I have just finished downloading the new Dreamweaver 8 upgrade but haven’t had time to review it yet.

    View Dreamweaver’s new features here.

    Firefox 1.5 is now in Beta

    Firefox have released 1.5 in Beta. I hope that this will go some way to continuing its battle against IE especially how IE 7 is in Beta. Personally, I still prefer Firefox because it has some excellent web design tools as well as the Web Developers Extension.

    More move to web standards

    More and more big name sites are adopting web standards. This week the GAP and Slashdot jump on the bandwagon.

    Google ranking factor checklist updated

    The site which lists the alleged factors that effect your sites ranking on Google have been updated to include the latest changes made.

    View Google Ranking Factors site

    Review

    Because of this weeks theme, I review SEO Elite, an excellent tool for improving your site engine positioning.

    Learn more about SEO Elite.

    Keep them coming back for more

    Posted in Marketing, Site content on by Paul Boag

    The real way to make a website work for you is to encourage users to visit it again and again. But how exactly can you make this happen?

    In my last article we looked at how to encourage users to visit your website for the first time. However achieving this is only half the battle. The real trick is to keep them coming back. Here’s where the real work begins. Having built a Website and attracted some traffic to it, your objective now is to gain repeat visits.

    Why are repeat visits important?

    A one time visitor just isn’t enough. As I am sure you already know, the chances of a first time visitor making a purchase is extremely low. They need time to review your competition, weigh the pros and cons, decide that they really do want to purchase. Depending on your sector this could take anything from a few days to several months. The question then becomes, how do you keep them coming back to your site so that your brand remains in the forefront of their mind when they do finally decide to make a purchase.

    How to keep them coming back

    Regular updates

    Many sites are just never updated. This is a sure fire way of putting people off. If people are interested in what you have to offer they will return again and again as long as there is something new each time. However if they come back more than a couple of times and find nothing has changed the chances are they will never return again.

    Message Boards

    Allow users to discuss your products and services via an interactive forum. You will find that a recommendation by another user is a lot more believable than you telling your visitors how great your product is. Of course you always run the risk that somebody will say something bad about your product but you can always remove such postings from the forum. However be careful. A forum that is full of nothing but praise can seem a bit suspicious!

    Special Offers

    Special offers are always a sure way to keep people coming back. By creating special offers that are exclusive to the website and that change regularly you can be sure users will keep visiting the site to see what your latest deal is.

    Support

    If you sell a product or service that might need after sales support you may wish to consider a support section. This could provide frequently asked questions, downloadable updates or even a forum that allows users to support each other. This will dramatically reduce your telephone enquiries as well as encouraging users to return to your site. When they do return it gives you a good opportunity to recommend related products.

    Newsletters, ezines and mailing lists

    You can have as many special offers and fresh content on your site as you want but if nobody knows they are there then they won’t come back. That is where a mailing list comes in. Send out a newsletter to those that choose to subscribe informing them of updates to your site. Mailing lists are very easy to set up and can generate huge rewards to your business if done properly.

    Hopefully some of these ideas will inspire you and help to maintain those hits well after the initial burst of activity when the site launches. My final article in this series will look at how your current visitors can be one of the best source of advertising you have.

    Financial benefits of usability

    Posted in User experience on by Paul Boag

    In this article I outline exactly why usability testing is worth the effort and how it can translate into real financial gain.

    A large part of my job is improving web site usability. However, convincing companies to spend time and money on usability testing is always an uphill battle. Somehow it is seen as a luxury that can be left out. This couldn’t be further from the truth! Below I outline exactly why usability testing is worth the effort and how it can translate into real financial gain.

    Reducing Customer Support

    Answering customer queries, taking orders and handling complaints can prove an expensive and resource hungry job. But a well designed, usable web site can significantly reduce this burden. If your web site makes it easy to order online, get questions answered and resolve problems then your users won’t need to phone, fax or email you. This means you can reduce the number of man hours dedicated to customer support and so make significant financial savings.

    Design is a matter of opinion

    It is amazing how many web development projects stall over disagreements based on personal opinion. Disagreements over colour schemes, the benefits or drawbacks of dropdown menus, the amount of marketing information that can be collected from a website before you begin to put people off. These are the kind of issues that can prevent a site progressing in its development. Everybody seems to have an opinion and everybody thinks they are right. By presenting these issues to a sample of your target audience you can get a truly independent point of view. This often cuts days or even weeks off development time allowing you to become the first to market.

    Increased customer satisfaction

    We all know that customer satisfaction leads to customer loyalty and that customer loyalty leads to repeat sales. This is especially true on the web where your competition is only a click away. When it is so easy to go elsewhere customers become very fickle and the tiniest thing can make them give up on you and visit your competition. However a site that has been tested with real users, and therefore meets their needs, can give you an edge over your competition. It will ensure your customers to stay with you while encouraging your competition’s customers to make the switch.

    Decreased need to publish after-the-fact fixes

    Hindsight is a great thing. Once your web site is live and real users are interacting with it on a daily basis it often becomes obvious where the flaws are in your site. However, changes at this late stage can often be too late and expensive. If users find your site difficult to use on their first visit they are extremely unlikely to ever come back again. It is therefore vital that any problems are resolved BEFORE the web site goes live.

    Decrease in abandoned shopping baskets

    Something like 70% of shopping baskets are abandoned on the web! This equates to millions of pounds of lost revenue. People abandon shopping baskets for lots of different reasons some of which are beyond your control to prevent. However the vast majority are abandoned because the user becomes frustrated with the shopping process. Usability testing can help identify these points of frustration early and help remove them from the shopping flow.

    Early identification of problems

    Effective usability testing isn’t just something that is carried out at the end of a project. By that point it is almost too late to make changes and correct problems. Usability testing should be an integrated part of the development process happening continually as the site is developed. This enables you to identify problems early and avoid having to make expensive and complex adaptation later in the site’s life. By catching problems early it is possible to correct problems before they have too great an impact to correct .

    Removal of unnecessary features

    It is often surprising what usability testing turns up. It is not unusual for it to actually demonstrate that your web site is over-engineered. Sometimes you discover that actually your site is too small to bother about a search function or that your target audience isn’t interested in some of the applications you are offering. By carrying out testing you discover this early on in the sites development and can drop these components before time and money is invested in building them.

    Success criteria

    Posted in Web strategy on by Paul Boag

    One of the first questions I ask a client interested in developing a new website is, “what are your success criteria?” How a company evaluates the success or failure of its website is fundamental to how that site is built and maintained.

    Establish measurable goals

    As a website developer I may build an incredibly popular website which receives tens of thousands of visitors a day but if those visitors fail to make purchases, when this is a key success criteria for the client, then I have failed in my job. A clearly defined set of success criteria will help to ensure a website is built in the most appropriate way as well as make sure goalposts don’t move too far through the lifespan of the project. In practice it is all about communication. Like most projects, if goals are not clearly defined up front and a mechanism is in place to measure if those goals are met, a website project can soon turn into a battlefield. The client is left disappointed with the end result which hasn’t lived up to his or her expectations while the developer is exasperated believing the client asked for one thing but in reality wanted another.

    Dealing with multiple objectives

    So when I talk about success criteria what exactly is it that I am referring to? Well to some extent that depends on the individual website. A community website is going to have very different aims and objectives to say, an e-commerce site. Often it is impossible to define a single criterion but rather there are a number of factors that the client wants taken into account. In these kinds of situations it is important to prioritise the criteria. For example, I have recently been involved in a lot of work for the National Trust. Like most client they didn’t have a single aim for their site. They wanted to disseminate information to the public and to their members. They also wanted to increase the number of people becoming members through the site. Moreover they wished to make their site visually more attractive and easier to use as well as meeting the need of visually impaired users. The list went on. It took sometime of working with the client before I felt confident in the priority of these goals.

    Be specific

    It is important to note that broad goals for a website, such as those mentioned above are not the same as success criteria. Success Criteria need to be more specific and more measurable. For example my interpretation of a site being more usable may have been different from that of the Trusts. What were needed were tangible goals we could agree between us. Instead of a vague goal of improving usability it would have been better to specify a percentage increase in the number of users moving deeper into the site or staying longer. Equally talking about increasing membership could mean very different things from one person to the next. As a developer I may have believed a five percent increase was reasonable while the Trust may have expected something much higher. It is vital to be specific and that all parties involved are fully in agreement with any criteria set.

    Be realistic

    The final point worth making is that it is extremely important that any success criteria set are realistic. A one hundred percent increase in company turnover within a fortnight of the site going live just isn’t going to happen! No self respecting development house is going to sign on to that. Success criteria should be set at a realistic level and achievable within a realistic timescale. I also don’t believe that it is particularly appropriate to make success criteria a contractual obligation on the development house used. My reasons for this are the client often hugely affects success criteria themselves. The development of a website is a partnership between the developer and the client. The client obviously has a huge impact on the final deliverable and so cannot blame the developer when not all the success criteria are met.

    The blame game

    It is an inevitable part of web design that not all your objectives are going to be met in the first pass. The trick is not to turn things into a blame game but rather sit down and analysis why things didn’t work out as expected. Where your criteria unrealistic in the first place? Where there factors which you could not have predicted at the outset of the project? There is a whole host of reasons why objectives weren’t met. Once they have been identified the next step is to either set new objectives or look at new ways of addressing the existing ones.

    I strongly believe that establishing clear success criteria in the early stage of any web development project will facilitate the smooth running of the project and ensure better communication between client and developer. However it is important that any success criteria laid down remain flexible and don’t turn into a club to beat each other around the head with!