Cognitive Friction

We had a bit of a heated debate in work this week, which followed my suggestion that we should consider using a HTML/CSS Framework to create prototypes instead of creating so many wireframe drawings. Now, there’s a whole case for and against this approach, but I don’t intend to go into all aspects of it here or any of the specific differences among my colleagues. Instead, I want to focus on the most contentious issue in the debate, which is how technically adept a user experience designer should be. This will also bring me back to the issues that started me blogging again, as set out in my Agenda Addendum post.

My agenda

If you missed that post, or just forget what I said, here’re the issues that were exercising me in that post:

• The role of prototyping and design specifications and the wisdom of spending time on these design artifacts as opposed to just diving into the build process.
• The role of design and designers in the development process and the relationship between designers and engineers

To ease back into this subject, I want to introduce a little known but seminal text on this subject by Mitch Kapor, co-founder of Lotus Development Corporation. It was written back in 1990, before the web really took off and before the phrase ‘user experience’ enjoyed wide currency. In fact, it contains the earliest use of the phrase ‘user experience’ that I have ever encountered. It’s called A Software Design Manifesto, and was eventually published in the anthology Bringing Design to Software, Terry Winograd (ed.) Addison-Wesley, 1996.

Kapor’s Manifesto

In this manifesto, Kapor opens by lamenting the poor user experience of the software of the day, which he puts down to a total lack of professional design in the software development process. The remedy he proposed was the creation of a new role in software development teams:

The lack of usability of software and the poor design of programs are the secret shame of the industry. Given a choice, no one would want it to be this way. What is to be done? Computing professionals themselves should take responsibility for creating a positive user experience. Perhaps the most important conceptual move to be taken is to recognize the critical role of design, as a counterpart to programming, in the creation of computer artifacts. And the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience.

Kapor then goes on to make a brief but convincing case for design as part of the software development process. He defines the role of the Software Designer thus:

The software designer should be the person with overall responsibility for the conception and realization of the program.

But more importantly, Kapor outlines the skills and course of education likely to turn out people who could adequately fulfill this role. Let’s see what he recommended.

A software designer’s skill set

Kapor sets out a number of basic tenets for the training of software designers, which can be summarised as follows:

1. Their training should be distinct from that of computer science, software engineering, and computer programming professionals in that their focus must be on usability and users rather than technology and computing theory.
2. They should be trained in part through practice, in a studio environment, where they participate in directed projects to learn their profession.
3. They must master the field of human computer interaction and related social science research methods.
4. They must have a firm technical grounding to make them effective participants in the software development process and so that they will not risk losing the respect of technical colleagues for not understanding fundamental technical concepts.

We have been striving at work to do as good a job as possible to live up to points 1 to 3 in that list, and part of the reason I started discussion of prototyping is in an effort to advance our skills in regard to point 4 on Kapor’s training agenda. User experience design is a very new field, and practitioners have very diverse backgrounds, some with more technical understanding than others. I contend that one of the benefits of doing more prototyping is to increase this technical understanding.

To be an effective participant in the design of a web application without a good understanding of the fundamental principles of the technology is problematic, to say the least. Certainly, the developers who must implement your design will have less respect for both design and designer if they heard you confess that the learning curve of HTML and CSS is too steep. But prototyping is more than just an excuse to gain a good technical grounding, as Kapor also points out.

The importance of prototyping

No one, least of all Kapor, is advocating that the designer be able to write code professionally. That is not the focus of the designer, which should be on defining a good user experience. But in an interactive medium, words and static pictures are only going to take you so far. Kapor points to Architects, who create models of their buildings, because 2D plans are an inadequate medium to understand their designs. Software designers will need a similar tool:

In both architecture and software design it is necessary to provide the professional practitioner with a way to model the final result with far less effort than is required to build the final product. In each case specialized tools and techniques are used. In software design, unfortunately, design tools aren't sufficiently developed to be maximally useful.

The important phrase here is Far less effort, Kapor doesn’t envision a software designer opening a text editor at a blank file and starting to define variables, functions and data structures. He realised that for prototyping to make economic sense, it had to be quick and easy. Here’s how he saw it in 1990:

Hypercard, for instance, allows the ready simulation of the appearance of a program, but is not effective at modeling the behavior of real-world programs. It captures the surface, but not the semantics. For this, object-oriented approaches will do better, especially when there are plug-in libraries, or components, readily available that perform basic back-end functions. These might not have the performance or capacity of back ends embedded in commercial products, but will be more than adequate for prototyping purposes.

Behaviour, that’s the clincher. The effort to model web applications in static drawings can approach or surpass the effort required to create a prototype in code. As Jeffrey Zeldman said Wireframing Ajax is a bitch.

In the last few weeks, looking around for the right sort of tools for rapid prototyping, I came across the excellent work done on speeding up and simplifying the creation of CSS, HTML and Javascript in projects such as the YUI library, or the BlueprintCSS Framework, or the work on the Protoscript Javascript library. These are exactly the sorts of tools Kapor was talking about in 1990. All that’s missing is the will to learn to use them effectively. It’s time for those User Experience Professionals who don’t do markup to up their game, and I include myself in that number.

Comments RSS