Cognitive Friction

Today I’ll be heading up to the Black North to attend a lecture at the Queens University of Belfast entitled Design Thinking for Innovation: Treat Your Company, Your Team, Your Products as Prototypes. It will be delivered by Michael Dearing, an associate professor at the Design School at Stanford University.

Michael Dearing has an impressive track record at eBay and a lot of fascinating research interests around design innovation for new product development, web-based businesses and user experience design. I must say I am really looking forward to this, as design thinking and innovation in organizational behaviour is a real interest of mine too. I’ll be sure to blog my notes on the train home.

I have noticed a couple of interesting developments at two of the leading companies in the user experience design field: Cooper and Adaptive Path. Both companies seem to be taking a decisive step into the wider design territory occupied by companies such as Ideo and Frog Design.

On July 9th, Adaptive Path announced that they had selected Michael W. Meyer, a former executive at both Ideo and Frog Design, as their new CEO. About the same time, Dan Saffer started blogging about physical computing and his experience of learning electronics. In his first post, he says:

Over the last several years, Adaptive Path’s business has expanded from mostly web work to a mix of web, mobile, medical devices, and consumer electronics.

Interesting. The second thing that got my attention was that Cooper made an appointment on July 14th, making Michael Voege, also from Frog Design, their Director of Industrial Design. Making the anouncement, Dave Cronin at Cooper said:

Some of the most exciting and challenging products we’ve designed here at Cooper have involved a physical component. We admit it, we’re greedy: we want to do more fun projects like that.

So what? Well I think this marks a sea change in the field of user experience design. I have long admired Ideo’s work and wondered what the difference was between what I did for a living and what the people at Ideo did. The answer seemed to be simply that I designed for software, a material with no physical properties, whereas at Ideo they designed both the software and the hardware. I’m sure that at Cooper and Adaptive Path, people have been looking at the iPhone and at Microsoft’s Surface and have been thinking that these types of physical computing devices with complex behaviours and innovative interfaces are where all of the interesting future action will be in our field. They are positioning themselves to take advantage of these kinds of opportunities. Now that’s the sort of move I wish I was making myself.

I was buying the excellent ScreenFlow application from Vara Software yesterday and that old chestnut, the mandatory post code field, came up again. For some reason, whoever coded their purchase forms decided it would be a good idea to ensure that:

• You must enter a post code, even if you don’t have one.
• It must not be one character long
• It must not be too many characters long

What’s too many? I would guess that it’s the maximum length of a British post code or American ZIP code, or some such arbitrary length. Filling this in was a pain – here’s how it played out.

First, I can see the field is mandatory, so, I try entering a hyphen, figuring that it’s the least effort and if anything actually gets posted to me, that’ll look the least silly on the printed address.

Error! you have foolishly attempted to enter one character, this is verboten!

OK. Time to send these people a message. But wait. That is verboten also.

By this stage I am trying to model the mentality of the coder of this form:

Hmmm. What boundary conditions can I imagine that would enable me to validate the text in this mandatory field? Well, I know there should be more than one character, because I can’t conceive of a post code system that uses just one character. And if I set an upper limit to the number of characters in the field, say the length of my local postcode, I’m done. Excellent! What a diligent programmer I am.

Do you know the worst thing? After all this careful validation, he accepts two hyphens.

So, effort was expended in ensuring that only nonsense that falls within rigidly defined parameters is acceptable. AAARRRGGGH! Maybe I just get riled up too easily. But these little details are so easy to get right, there’s just no reason to get them wrong.

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.

The excellent Luke Wroblewski is currently writing a book called Web Form Design Best Practices for Rosenfeld Media. I’m really looking forward to reading it, and so I was interested to see Luke’s blog post on Zip codes and locations. Having read it, I hope that Luke remembers in his book that not everyone lives in the States, and that many people have no postcode of any sort at all.

This is a bugbear of mine, because I live in Ireland, in County Dublin, just outside the only city in the state that has any sort of post code system. In urban Dublin, the city is divided up into areas labelled D1, D2, D3 and so on. All of the even numbers are on the south side, all of the odd ones on the north side. In Northern Ireland, still part of the UK, the excellent British post code system is in place, which assigns a seven-letter code to groups of no more than 25 street addresses. Everywhere else on the island, though, there is no postcode system at all. Indeed, in rural areas, addresses look positively inadequate, like this:

If you look for Cornaglea on Google maps, you’ll just see a road running through a big blank area of map. It’s farmland. There may be 3 or 4 houses scattered around the area. How do you find such an address if you are driving? How do you deliver mail there if you are a delivery driver? Well, you either know your way there, or you don’t. If you don’t, you ask directions. Now, let’s get back to web forms, and eCommerce in particular.

It drives me nuts when forms require either a ZIP code or a postal code and call me out with an error message if I don’t provide one. I don’t have one to provide! Worse, some forms even try to ‘validate’ whatever I type as a workaround (usually a hyphen) and inform me that my postcode is in error because it must contain only alphanumeric characters. Says who? Don’t these people know the Internet is available all over the planet? I shop online a lot, and have for years, and I still email the owners of forms with this irritating characteristic every time I come across it. It’s so easy to fix this, especially when your form knows which country I am in.

All of this is to say nothing of French or Italian street addresses, where the door number may come at the end of the first address line, not the start. And let’s not even venture into Asia at all. But Luke, please tell me you have a section in your book on international addresses, calling attention to the wide world of sports outside of the USA. Please tell me it is so. Because people will read your book, they will learn, and in some small number of cases, they’ll take the trouble to do this address thing well. And who knows how far best practice may spread from there, as those who couldn’t care less simply copy forms from some other site.