I first encountered the notion of “affordances” in Don Norman’s excellent The Psychology of Everyday Things (which was renamed The Design of Everyday Things a couple of years later). From the world of design, an “affordance” is a characteristic of an object that offers clues about how to use or interact with that object; the design of a chair tells us it is something for sitting on, a pitcher is for holding and pouring things. Affordances can be difficult to design in a world of more complex physical objects; they can be nigh on impossible in the design of software tools and applications. One of the things that made early computer systems so confounding was that they offered no affordances to latch onto. Graphical user interfaces were a huge step forward in making software user friendly (or at least not overtly user hostile).
Affordances and the design thinking that goes into crafting good ones are rooted in the physical world; dexterity, reach, visual acuity, strength, all factor in to design. This is the world of ergonomics or human factors. Transferring that knowledge to the abstract world of software and the objects in our environment with significant software elements is no simple task. You need only think of the remote control for your DVR and set top box or the user interface of your bank’s ATM to appreciate how difficult this design work can be.
One failure (limitation?) of modern application design is affordances that run out of steam before users grasp the full capabilities of an application. If all chairs looked like a Shaker chair, how would we ever figure out what to do with a BarcaLounger; or the pilot’s cockpit seat in an F-16? The menus and window layouts of your typical desktop application (Word, Excel, Powerpoint, Outlook) get everyone up and running quickly, but they do nothing to hint at, much less reveal, any deeper capabilities or opportunities. So, for most users, most of the time, those opportunities go unrecognized and the capabilities never get exercised.
What separates power users from the rest of us, then, is a willingness to dig into users manuals (RTFM as a career advancement strategy) and to experiment and play with their tools to figure out what is possible. Otherwise smart people take marketing hype about “easy and intuitive” software seriously and judge themselves deficient when good software tools are often neither. The opportunity wasted is tremendously sad.
So, what do we do to help more people get more value out of their software? My specific interests happen to be about knowledge work. What can we do to help knowledge workers push their tools farther and better? Put another way, why do we settle for knowledge workers leveraging such limited subsets of the tools they already use or avoiding tools or techniques that might unlock significant new insights and outputs?
Although I’ve been talking about affordances I don’t think the blame or the answer lies exclusively with software designers. More realistic claims from software marketers wouldn’t hurt although I’m not holding my breath. As software users, one thing we can do is invest time to suss out more of the design models in the heads of the software developers who build the tools we are seeking to leverage.
Word processing software offers examples of what I’m thinking about.
Microsoft Word is likely the dominant word processor on the planet. You can find it installed on most any desktop or laptop computer you encounter. It ushered in the world of WYSIWYG computing where one goal of the interface was to represent your work in as close to final form as possible. Implicit in that design was that the “final form” was a printed page.
A consequence of that design choice was that you now had one tool that spanned what had once been a series of discrete stages in the process of bringing an idea to the printed page. Writing, editing, design, and layout are quite different cognitive activities. In a pre-WYSIWYG world, each of these steps had its own set of professionals, its own set of standards and practices, and its own set of tools. With Word you now have a single tool that can serve at all stages (at least for 80% of cases).
Whether that is a good thing is another question. Having one tool makes it more difficult to see that the activities in each stage are quite different. When you’re working out the structure of an argument, there’s little point to be worrying about what typeface and font size works best for a section heading. But a single tool blurs that distinction and boundary. You can be enticed into playing with those problems or thinking they are important to deal with now while your fundamental argument or storyline is still a mess.
A tool that is suitable across all these steps may be valuable within an organization. But at the price of obscuring the differences between different process stages. You could manage that problem if you made an effort to make the different stages of the process more explicit. But now the organization and its people need to work at cross purposes to the tools. You have a single tool obscuring the differences in the process while you try to highlight those same differences as you manage the development and evolution of any particular deliverable.
Scrivener is a popular word processing tool, especially among authors dealing with longer form writing projects. Its user experience embodies a very different model of the writing process than Microsoft Word. Scrivener makes the various stages of writing–drafting, editing, design, layout–visible and identifiable in its user interface. In particular, WYSIWYG is a secondary or even tertiary goal in the user experience.
Moreover, Scrivener was designed in a time when the printed page is only one of many target forms for final deliverables. It also supports multiple formats for electronic books, PDF files, and the web. To that end, the design of Scrivener separates the activities for structuring a draft output from formatting it for final output.
For users accustomed to the WYSIWYG model embodied in Microsoft Word this is a source of frequent confusion. Learning how to invoke specific functions and features in Scrivener isn’t terribly helpful until new users grasp the fundamentally different process model embedded in the design of the application.
Software marketers don’t like to acknowledge that software users require multiple individual software tools to handle the complexities of modern knowledge work.It is not their job to figure out how to fit multiple tools together to get work done.
This is an element of your job description that hasn’t been acknowledged or addressed in the average organization. You will likely be issued a starter set of basic tools. But don’t expect useful guidance on how to use them in concert to accomplish the work expected of you. It is yours if you hope to be an effective knowledge worker.