Jamie Appleseed recently wrote a brilliant article on bugs and user experience. It won’t help you magically prove the ROI of QA testing, but you should definitely read it because…
It’s about accepting that things do go wrong sometimes. And that therefore, we should design systems that degrade tolerably and fail gracefully when they are actually broken.
It argues that we should keep simplifying and using progressive enhancement. Think of accessibility in the widest sense, and design for the least capable people & technology first. Not everyone has good vision, good motor skills. Not everyone has a powerful computer, a fast broadband connection. It happens.
Simple, lean, fast… then add the funk
I know that as developers we already think about contextual impediments. Our task models sometimes show that not everyone has time to really concentrate on the information we present to them. Designing for degradation and failure is the same thing – stuff gets in the way.
So make it simple, make it lean, make it fast.
Then layer up the funk. Spec it out good and proper.
Like the other ‘premium’ (ie. done properly) things we try to do, this approach may initially take more time and therefore cost more than you expect.
It’s a relatively easy thing to sell-in on public sector projects – those where accessibility in the traditional sense is a stated requirement. We’re working on a number of projects with Bristol City Council, and the teams for taking this approach already: keeping things simple and designing transactional forms that work well, with or without JavaScript; leveraging GPS capability on your phone, but not excluding those without it; documenting rationale and detailed requirements to help the systems integrators get it right.
Bells, whistles and business value
But what excites me about Jamie Appleseed’s article is that it shows we can frame this good practice as something that adds business value too.
Private sector clients are more likely to want bells and whistles. Maybe big image carousels, full page transitions. When they ask for these kind of features, let’s explain why they should be designed and engineered as enhancements, not blockers. Let’s help them understand that if they aren’t, at some point things will fail, and they will lose money and customer trust.
Tell them we can help make fast, fault tolerant, progressively enhanced, inclusive, high performing, beautiful in all senses, websites.
After all, who wouldn’t want one of these?
