
Usability is beginning to get treated like a constant software update – I was recently asked how current my usability QA Management was. If February this years isn’t, then I would have to start laughing. Standards aren’t software updates – why this perception exists is basic misunderstanding of what web usablity is about (it is a huge area of testing), combined with middle management keenness to turn everything possible into a buzzword, a marketing tool to senior management – we do it differently, we do it right. If only. Usability encompasses primarily front-end tests in user exepreince, web accessibility (the oft forgottten) coding standards, design heuristics. Back-end tests include load testing based on user stories (scenarios) to simulate an realistic load.
Understanding the audience is a first consideration, but this shouldnt be barrier for adopting a more flexible approach – no company should be arrogant enough to think they know everything about their marketing demographic.
Web Accessibility is overlooked, but a sizeable proportion of a web audience is affected by simple things such as colour. It’s estimated that one in 12 men and one in 200 women have some form of colour blindness (Source: IEE). You can check how Internet users with different strains of colour blindness are viewing your website with Vischeck. Other people who may access your website that have disadvantages include:
- Some epileptic users who must always be careful to avoid seeing flickering between 2 and 55 Hz
- Web users from outside your industry who may not understand industry jargon or acronyms
- Web users whose first language is not English and who may not be able to comprehend complicated language
I get suprising resistance to standards, but in a way not – its almost akin to schoolboy/girl obstinacy. Observing the well defined standards can really prevent basic problems, and code quality is important for maintenance, performance and cross-device/browser friendliness. This alone would improve a sites overall usability. Now this is where usability gets larger – functionality – often excluded in a usablity remit plan, but ludicrous. Poor functionality = poor usability.
This highlights a problem with testing still – the way managers, with little knowlege of project lifecycle, refactor/rework testing principles for aims other than doing things right – or worse, in misguided belief they are doing the right thing. Testing/QA is a skill, like any other IT discipline. Agile/SCRUM impacted this further with large degree of woolliness of QA and Project Management. The reliance is heavily on rounded skilled developers – which are minority. Although Agile/SCRUM focus on requirements, largely project management is left out of equation. Managment feel confidence that there are daily meetings (though largely these are run ineffectively), but I have seen a lot of damage created at these meetings. Usually too long, too few people, and sometimes overly detailed. It should be an account of work done, current work impediments. All other discussions should be offline, and only concern relevant people. There is no point on holding work up, because two people decide o descend into a database schema argument.
I mention Agile/SCRUM because these environments can allow usability to be part and parcel of development. The rapid dev/test turnaround can easily incorporate standards checks. And if the Agile philosophy is applied correctly on user stories and Product Manager input from the client perspective this will keep the expected user experience on track.