May 2005 Archives

In September 2004 I had an essay published on usabilitynews.com, on why readability testing shouldn't solely be used to gauge how understandable your site's content is.

The recent press coverage of the Bath University research paper "Readability Assessment of British Internet Information Resources on Diabetes Mellitus Targeting Laypersons" (including UN's own story: NHS Direct Website too complicated for Diabetes Sufferers) has raised interesting questions about some of the methodologies used to measure users' experience on the Web.

The research assessed the readability of 20 information resources on diabetes using Microsoft Word's automated testing feature, which gives a Flesch-Kincaid Grade (rates text on a US grade-school level; the lower the score, the easier it is to understand the document.) and Flesch Reading Ease level (rates text on a 100-point scale; the higher the score, the easier it is to understand the document) score. This was then compared against the 'average' reading age of the population giving the conclusion that a majority of the sites tested were 'too complicated' for their readers.

On the face of it, this conclusion and the methodology used is fine, but due to the indiscriminate nature of automated testing tools, it doesn't present the entire picture and, at worst, can give the impression that the users of these websites can't understand the content at all, which may not be the case.

• A health website which uses (and in most cases defines) medical terminology would score high when evaluated using 'Readability formulae that estimate the reading level of a document based on the words that are used and the lengths of sentences'.
• The readers of such information would most likely have a good understanding of the medical environment surrounding their condition, which would make the articles easier to understand.

It's this lack of context in the research that gives the biggest cause for concern, as some of the sites tested may automatically try to lower the reading age of their articles. They would then run the risk of alienating their actual users, who might not need a simpler article!

I would forgive anyone reading this for thinking that I'm dismissing the research out of hand, but in fact I welcome any research that can help us to provide a better service to our users. This research has done that because it’s made the people in the healthcare community look at how readable their websites are. But the key message is, and should always be, know your users and test against them not just by using automated tools.

(In case you're wondering, the Flesch-Kincaid Grade and Flesch Reading Ease level of this article is 60.5 and 11.1. I hope you've managed to understand it okay!)

User Experience (UX) design is traditionally seen as the domain of user interface (UI) design, but within a software development team it should mean so much more! UX should permeate through the whole development team. It should influence the way middle tier developers' craft their components and the way database administrators create their tables, stored procedures and views.

Update: This article has now been published in UsabilityNews

Within a software development team, most talk of creating a good "User Experience" usually relates to creating an intuitive user interface. In the traditional sense this means;

• The layout of the buttons,
• The ability for the application to remember contextual information,
• Or the intuitive nature of a web site navigation system,

but these interfaces, although important as the "face" of the application, are actually only a small part of what makes up the product.

Beyond the User Interface

A software application, like an iceberg, has a great deal of it's complexity in the underlying structure of the program, the object model, where there are countless different members (interfaces, methods, and properties, delegates etc.) which transfer and transform data between objects and to and from the database.

While not as visible or as glamorous as the UI these are all interfaces that have users, your colleagues, whose needs must be satisfied.

On one level these "users" could be considered the most important users to satisfy because the culmination of their efforts make up the finished application, the ability for them to produce good software and the trade-offs they make in order to create the software will have a big influence on it's character.

With this in mind the environment and the mind-set a developer works in is crucial to their ability to produce a good overall user experience. Every effort should be taken to ensure that they are focused on creating a good quality product, not in compensating for an awkward development environment or in acquiring the contextual information, from obscure code, that they need to complete their task.

Creating the right environment for UX to flourish

Every developer should be encouraged to develop this mindset; one way is to ensure that you create code that enables your colleagues to interface with it easily.

The simplest and most effective way of doing this is by naming your classes and members appropriately.

As a rough guide;

• Your objects should be named clearly.
• Your objects and their members should be named so that their intention is obvious.
• Your members should exist harmoniously within scope of the class they inhabit, as well as the overall application.

When the ambiguity is taken out of the development activity, the amount of tacit knowledge needed to complete a task is diminished and the communication between team members is simplified but it's in the subsequent phases of the project when this clarity pays real dividends. Creating an object model that is clear and expressive reduce the amount of background information that has to be re-learnt and understood before starting a development task, allowing the developer to become productive quicker.

I intend to discuss this topic further, the theme that every opportunity should be taken to reinforce a user centric mind set is, I believe, critical to the development of good products. Only by cementing the "user" in all it's forms as an integral part of the development process will the team truly understand what is needed to create a successful User Experience.

For more information on creating a usable object model take a look at the following article - which has a guideline for creating a usable API;

API Usability: Guidelines to improve your code ease of use By Mathieu Jacques

There are other ways to learn without working;

• read philosophy,
• science fact,
• science fiction (Kim Stanley Robinson = mars trilogy, Antarctica, icehenge, pacific edge, books by asimov, Arthur C Clarke, William Gibson is very cool - neuramancer - who popularised the word 'cyberspace'),
• learn cybernetics and about feedback and control systems,
• learn about evolution (Richard Dawkins for evolution in general),
• how the mind works (Dennet + hofestader - the minds eye, consciousness explained, "Godel, Escher and Bach" for great stuff about mathematical paradox, mind bending art, and remarkably complex music, and Susan Blackmore for taking Richard Dawkins evolutionary model of the mind into a full blown theory - the meme theory of the mind), etc. etc. etc.

the more you learn about other disciplines, the more likely you are to develop your own ideas within your own spectrum that other people will not have - try to be different to your contemporaries, not the same!!! become more worldly, not more insular. Learn from other areas where there is an abundance of talent." ...quite nice to stumble across this when feeling a little lost.