After having very recently completed a 2 day session on web usability focussing on User Centered Design, I was struck by a passage in a book I’m currently reading:
It is true that we are infected with a spirit of conservatism and would rather make small alterations than large ones. It is disagreeable and troublesome for us to admit that our existing system is radically defective. And it is true that, other things being equal, we prefer simple to complex hypotheses, again from the desire to save ourselves trouble. But if experience leads us to suppose that radical changes are necessary, then we are prepared to make them, even though they do complicate our system. When an observation runs counter to our most confident expectations, the easiest course is to ignore it, or at any rate to explain it away. If we do not do this, it is because we think that, if we leave our system as it is, we shall suffer further disappointments. We think it will increase the efficiency of our system as an instrument of prediction if we make it compatible with the hypothesis that the unexpected observation occured. Whether we are right in thinking this is a question which cannot be settled by argument. We can only wait and see if our new system is successful in practice. If it is not, we alter it once again.
Ayer, A.J. (1936). Language, Truth and Logic, 99
While Ayer here is feeding us the information required to answer his question “What is the criterion by which we test the validity of an empirical proposition”, for me it encapsulates many of the key ideas behind philosophies such as User Centered Design and Agile Software Development. Taking a closer look it’s clear that Ayers words have a broader application than just software development (as you might well hope from a philosopher in the 1930s), but sticking to our chosen design and development methodologies, there are some interesting points to be made.
*“[we] would rather make small alterations than larger ones” *
“Can you just make the title red?” and “Can you just make it so the title is a spaceship?” would rarely elicit the same expression from your favourite developer. Agile is good for breaking big problems into small ones, and this happens on many levels. One such example is a ‘sprint backlog’, which represents a set of discreet, manageable tasks, with an estimate of how long each will take to complete. Rather than a vague cluster of requirements such as “build a registration form”, you might find a set of tasks such as “Send data to remote service” or “Validate input fields”.
Agile anticipates alterations and handles them with high visibility and a clear indication of what larger alterations will do to the system.
“It is disagreeable and troublesome for us to admit that our existing system is radically defective”
Clients change their mind, developers don’t read scopes of work and designers want triangular text inputs; it can be easy to disagree on whether what’s been created is what was asked for. Agile aims to ensure that everyone from client to project manager to developer and designer have the same vision for the project, with no one left to find the outcome “radically defective” in comparison with the system they were expecting.
User centered design helps align the goals of the product owner with the goals of the user, creating a relationship in which you are much less likely to find areas of your system are “radically defective” for either client or user.
“if experience leads us to suppose that radical changes are necessary, then we are prepared to make them, even though they do complicate our system”
Insight into contextual knowledge of where, why, when and how a user interacts with your system is carried out right from the very start when adopting a user centered design approach. The “experience” is the research, and it can often lead us to suppose that what we’ve designed might not be the best for us or our users. The key is that “we are prepared to make [radical changes], even though they do complicate our system”. Considering the users experience from the very beginning, at a point when the cost of change is relatively low, you avoid problems later when the cost of change could well be “radical”.
We often don’t think what we’re creating could be “radically” different from what a user wants or knows how to use. We know how we respond as a user and so can make some general assumptions about how others will behave. That is where you can find a radical difference. This problem of induction is reduced by identifying a handful of core personas from your user research, personable archetypes with realistic traits and behaviours that are used to base your design decisions around. Knowing the user better reduces the probability of the system being wrong for the user.
“We can only wait and see if our new system is successful in practice. If it is not, we alter it once again.”
Ultimately, we don’t know how well a system is going to perform or how a user will interact with it until either a) it performs, or b) a user interacts with it, so we should seek evidence for either of those things as soon as possible. Methods such as paper prototyping are great for quick, low cost iterations of early design and interaction guides. Agiles iterative nature and focus on regular, up-front communication between all parties breeds a process that’s open to changes while following a steady path to its completion.
I won’t do the hermeneutic runaround of wondering if any of the early User Centered Design or Agile pioneers were readers of Ayer, but I’d make a bet he’s at least indirectly influenced many areas of software development today. Later in the book Ayer goes on to state:
*[T]he distinction between a conscious man and an unconscious machine resolves itself into a distinction between different types of perceptible behaviour. The only ground I can have for asserting that an object which appears to be a conscious being is not really a conscious being, but only a dummy or a machine, is that it fails to satisfy one of the empirical tests by which the presence or absence of consciousness is determined. *
This was written a full 16 years before Alan Turing would publish his 1950 Computing Machinery and Intelligence containing the famous Turing Test. Ayer was 24.