This week I’m attending STC Summit 2017, the annual conference of the Society for Technical Communication. These are my notes from one of the sessions at the conference. All credit goes to the presenter, and any mistakes are mine.
Kirk St.Amant presented a session titled “Prototypes of Use: Adapting Content to the Usability Expectations of Different Contexts”.
Kirk has recently been working on “the auto manual phenomenon”. Think about opening up an auto manual and using the instructions on how to change a tire. Auto companies get plenty of complaints from customers about these particular instructions. At first the auto companies were puzzled, because user testing had showed the instructions were correct and easy to follow. After further investigation, it turned out that people couldn’t use the instructions, packaged as they were in a 450-page manual. Such a large book isn’t designed to be ready on a highway, in the dark, in the pouring rain. It doesn’t lie flat.
In other words, it’s a question of context. Where do readers actually use the doc? We need to focus on the delivery mechanism.
Consider how people use and process information. We associate a particular verbal representation with a physical object. Taking this further: The prototype that we use when we identify something may cause us to deliver the wrong product.
Kirk asked us to play a game, based on Physics or Maths textbooks. He asked us to describe such a book. The audience was unanimous about how such a book would look: Big, hardcover, blue or grey, with atoms drawn on the cover. We concluded that if we saw a thin pamphlet, we wouldn’t identify it as a Physics textbook. Similarly, we described the concept of a classroom.
When someone asks you to create a manual, you’re predisposed to create something that looks like a textbook, and probably something that fits into a classroom.
Instead, we should think: I need to create something that shares information on a particular setting.
We tend to use this formula when thinking of usability:
Content+audience = design
Instead, we should focus on:
Content+context[audience+setting] = design
Kirk now did a deep dive into defining the context of use, using a series of formulae and process maps to define the concepts and flows, illustrated by real-world examples.
Some cool terms:
- a prototype jam – what you experience when you get stuck because some part of a familiar workflow is suddenly absent.
- context mapping – a process for describing the objective, setting, and sequence of actions, for various contexts (objects, individuals, access points, exit options).
In response to a question about applying the results of a usability study: Kirk described how his team adapted the instructions for measuring blood pressure, based on the patients’ experiences using a blood pressure cuff and attempting to read a heavy manual simultaneously in order to report the results. Instead, the team substituted a voice-activated mechanism for reporting results.
The idea is to get engineers/designers to think about context at the start of the design process, so that content conforms to context.
Thanks Kirk for an educational, authoritative look at modelling usability and context.
Ready for a Friday chuckle?
I took this picture in a stairwell, then tweeted it:
I think that may be taking content management a little too far!!
Can’t tell if it’s a usability fail or win. ;P
LOL (laugh out loud)! 🙂
This week I’m attending the ASTC-NSW 2010 conference in Sydney. These are the notes that I took during a session by Jon Jermey. All the credit for the content and ideas goes to Jon. Any mistakes are mine.
Jon Jermey gave a presentation titled “Software usability: some second thoughts”. After years of experience in the software industry, Jon has come up with the idea that “usability” is not all it’s cracked up to be.
Brave man, to stand up and say something like that when the “U” is so much the trending topic. At first, I didn’t agree with Jonathan. But as I listened to him speak, I grew more and more interested in his perspectives. There were some contradictions in what he said. But then, perhaps that was the point. His presentation was a great collection of “second thoughts”, to get us thinking.
Jon pointed out that there are imperatives that trump the usability imperative. He gave some examples of “products” that may not pass the usual usability tests, but are still worth pursuing. For example, things that advanced civilisation, such as fire. Or a military product that you need to have, because your enemies already have it.
The superficial usability aspects are not the whole story. Jon compared Windows 7 and Linux. Linux command-line instructions at first appear horrible. But there are many great usability aspects, not least of which is the fact that by and large they do not change over time, as the more UI-focused products do.
Jon thinks that the current usability trends are an example of, well, not exactly “group think”, but a number of people all thinking along the same lines. There are very few dissenters.
The problems with the trend towards usability
Jon listed some problems with the current thinking around usability.
Usability is conservative. We find out what most people are doing already and stick with it. For example, the QWERTY keyboard (designed to stop people typing too fast); the traditional spreadsheet. I disagree with Jon here. There’s a lot of experimentation and new design coming out of usability professionals right now. For example, the iPad and various UI designs I have seen floating around that have not yet hit the production lines.
Jon gave an example of usability in action: eReaders. He posed the question, what exactly are they and what should they do for us? He pointed out that there all sorts of different formats of eReaders out there. I think this is an example contradicts Jon’s thesis. The early prototypes have been improved, based on usability design.
Problems are foisted on the designers rather than the users. Usability tends to be made the problem of the software designer, even though the designer has no contact with the users and no idea what the users need. Jon says it seems to be unfair to shift the responsibility to the designer, when the user actually has a lot of power too. The result is that the designer often restricts what the user can do, to prevent problems. Instead, problems can often be solved by the user, if they are willing to learn a few simple things, change their behaviour and fix the problem themselves.
Price and language. Jon posed these questions: Is price a usability consideration, and if not why not? Which is more usable, a product that costs a lot or a product that is cheap? Which is a better solution: Simplify the English version of your product, or translate it into French, Indonesian and Chinese?
What about having no words at all, such as on the first screen of the OLPC machine – using just images. Is this a usability win or failure?
Marketing versus usability. Jon asks, is the distinction always clear? What about the law of diminishing returns: Every new version of a piece of software is less of an improvement on the version before, and costs more and more to develop.
Dealing with failure. Jon put up a slide showing the differences between how the commercial world and the non-commercial world deal with failure. The commercial world blames the designer and tries to sell the user an upgrade, whereas the non-commercial (Linux) world asks the user about the problem, warns everyone else, asks the user how to fix it and suggests and alternative product. I disagreed with the import of this slide, because I think the division into commercial and non-commercial is too uncompromising.
Pressure groups and politics. Jon gave the example of the deprecation of frames. Why did the whole world shift, and why was the onus put on the website designers to change, rather than on the browsers to handle frames better?
Some suggestions from Jon
What if all software was like games? Games are designed to be difficult. Jon made the interesting observiation that people like their recreation to be difficult, but their work to be easy. In games, you learn or you leave (die). Is there a way to take some of that gaming motivation and apply it to software, websites, even documents?
Jon says yes. It’s about recognising that people learn and their skills grow over time. In the same way, software could grow over time with add-ons and feature packs.
Do we in the software industry need to re-think our approach? For example, we could have a director’s cut of our product (borrowing from the film industry). Or looking at the car industry: Take a simple version of the product and invest it with glamour.
Providing personalised products. Companies are providing customers with personalised products: Books, music, films, computer games. But software is generalised. Why is that? Is it that the software industry is going backwards? Looking at Linux, there are 50 to 60 different flavours to choose from. This fragmented hobbyist approach is driving the fast development of Linux to develop. Why is this not so in the commercial products?
Can we capture that exploratory approach and put it to work?
Possibly usability considerations are slowing down the development of our products. Jon’s impression at the moment is that all software products are the same. There are a lot of good things about standardisation, but can’t we set a higher goal and allow people to customise their software products. Put the glamour back into software.
This talk gave me a lot to think about. A new way of looking at our current approach to usability! It’s a brave man who can stand up in this day and age and go against the UX stream. Thank you Jon!