I attended a talk today given by Sarah Bloomer, a usability design consultant with 20 years experience who has come to Bangalore to attend Easy7. She talked us through the anatomy of a typical three to six week engagement, which turned out to have a lot in common with how we start off projects at ThoughtWorks.

It looks like this:

  • Establish goals. You need to find out what the company is trying to achieve with their new product / site / intranet / system. Surprisingly, this is often overlooked. We once nearly got thrown out of a bank for having the temerity to ask for a business plan for the new system they were developing.
  • Contextual inquiry / interviews. It turns out that if you ask people what they want their user interface to look like, they usually don't know. If you start asking them questions about their current systems and business processes, they'll tell you the things they are consciously aware of - but it turns out that most of their knowledge and experience is not at the conscious level. In terms of the NLP model of learning, they're at the level of unconscious competence. As a recovering philosophy student, this was probably the most interesting bit for me. Heidegger was the first European philosopher to really explain in depth Nietzsche's idea that most of our knowledge is not something we are consciously aware of1. Instead, he said, we tend to analyse our context consciously when things go wrong and our equipment breaks down. Heidegger and his followers inspired much of the theory behind modern anthropology - and so it's no surprise that usability experts use techniques from ethnography to understand how people interact with their computer systems. Basically this means spying on them with video cameras and taking notes while they carry out their everyday business.
  • User profiles / personas. Before you can really come up with an interface, you need to establish who will be using it. To do this, you create personas who represent typical users of the system. You can go into a great deal of detail on this and do a bunch of market research - as usual, knowing the appropriate level of detail to go into is key. Most of the time there's not the resources to do this, so cutting some pictures out of a handy copy of Cosmopolitan and writing up some notes will do. There's a mouse mat lying around our office with some personas on it for some application we're developing. This is quite handy for developers like me so that you can keep in your mind the fact that real people will be using your application at some point, and they won't have the time or the patience to work out how to operate the complex contextual drop-down tabbed interface you just made.
  • Activity scenario. Use cases, stories, whatever you want to call them - this is a bunch of narratives detailing the kinds of day-to-day processes users of the system will be performing. The pareto principle applies here - there's no point covering every single last one, so discuss the 20% of the activities that the users will spend 80% of their time doing.
  • Workflow diagram. These are diagrams of the business processes that have been covered by your activity scenarios.

Once you've done this, you can actually make some stuff to show your clients. Typically, you'd play around with:

  • Paper prototypes. These are sketched out designs of the screens in your application, so that people can get an idea of how the interface looks and give feedback. This is a highly collaborative process.
  • Functional prototypes. These are more formal, computer-based prototypes. At ThoughtWorks, we often use Ruby on Rails to quickly produce working prototypes to show our customers so we can get quick feedback.

The outputs of a typical engagement of this type is a style guide. In addition to colour schemes, fonts, user profiles, scenarios, diagrams and prototypes, you'd also get some templates for the main screens in the system - the primary application window and the main secondary windows that come off it. You can then hand these over to your design team to come up with the rest of the screens.

The striking commonalities between this methodology and agile methodologies are the importance placed on working collaboratively, getting rapid feedback using concrete examples, and matching the up-front work and documentation produced to the minimum level to allow the customer to proceed with the project. In particular, Sarah said she'd sometimes been brought in to a project and been presented with a big pile of requirements documents, which she had to put aside since they were too detailed and focussed on current processes to be of much use. She said she preferred to maintain a "fuzzy vision" while doing interface design since it allowed you to keep an overall view of the system without getting lost in a myriad of details. However requirements documents do sometimes come in useful as a reference when you're not sure how something works.

The Next Big Thing in usability circles these days is apparently user experience design. This means "designing" the experience the user has with your company at all levels - whether they phone up to talk to customer support, read a brochure, use a website, or walk in to your offices. This involves co-ordination with marketing, legal, management and pretty much everyone else in the company, and is hence pretty tough. However it reflects the experience we have with helping companies implement new business processes and change existing ones. Adding or changing a single process in an organisation produces "side effects", quite unsurprisingly once you take a holistic view of things. In order to manage these effectively you need to include strategies for organisational transformation along with more traditional services. This includes training, relationship development and a whole host of other activities often considered supplementary that are actually essential to the success of any project.

1For the bored, Heidegger's idea is actually a bit more fundamental than this. He says that conscious thought is only possible because of a more fundamental mode of being, which he calls being-in-the-world. This is a destruction of the Cartesian idea that the first principle of philosophy is "I think, therefore I am". For Descartes, thinking is the starting point of being. For Heidegger, thinking is only possible because we are already in the world, interacting with it in a non-reflective way. This leaves most of his predecessors in the history of European philosophy shuffling around looking a bit embarrassed.

Nietzsche was the first person to expound this idea - but because he takes his relativism on the question of truth quite seriously (read the first paragraph of "On Truth and Lie in an Extra-Moral Sense" to get a flavour of what makes Nietzsche such a good read), he doesn't really expand on it. Heidegger spends a lot of Being and Time discussing the ontological repercussions of this discovery. Freud and Jung are the first people to examine its consequences for human psychology (many of Freud's ideas came from Nietzsche, although he repeatedly denied - falsely - that he had ever read Nietzsche).