I can’t remember where I came across Minimalism Beyond the Nurnberg Funnel but I’m glad I did. Still I think I may have read the wrong book, a better starting place for this subject would of been the authors first book on the subject The Nurnberg Funnel. Both books discuss the same concept, namely minimalism in technical documentation. However the newer book (Beyond) is not so much an introduction to the subject but a review of how the ideas had developed in 8 years. So I think the earlier book may have been a better starting position. Now, 9 years after the second book I assume things have moved on again.
The authors' (Carroll is the editor of the new book but wrote the original one) concern is how people learn, and specifically how they learn from documentation. To this end the books are about technical communication. I think the ideas suggested would be interesting to user interface designers to look at too. The reference to the Nurnberg funnel comes from mythology.
Apparently – and I’ve not come across this myth elsewhere – the funnel was a device that allowed knowledge to be poured into someone’s mind. Imagine knowledge as some kind of liquid, insert the funnel into the head then pour the liquid into the head. Thats it! You know have the knowledge! This sounds like a great device.
Although I’ve never actually seen such a funnel they must exist because I know plenty of people and corporations who behave as if such a funnel exists. So it must just be that I’ve been unlucky.
Anyway, get back to the book... The originator of minimalism in documentation, John Carroll, suggests that traditional technical documentation is written on this principle. The authors working on a technical product (most of his examples come from word processors) fill the manual with everything they can think of. And over time the manuals grow as new features are added. For the users of the product the manual can be worse than nothing.
Research by Carroll and others shows that users just don’t absorb everything in the manual through Nurnberg like reading. Users find it difficult to find things and when they do they don’t want pages of explanation and technical details, they simply want to be told what to do. Indeed there is a paradox: people don’t sit down and read manuals. They want to accomplish tasks so they just get on with using the software. When they get stuck then they turn to the manual but they still do not want to read the manual, they want to do their task.
At this point a manual that explains technical details and system philosophy is exactly the wrong thing. Users will get frustrated and skip parts of the manual until they find the bit they want – that is, the bit that tells them what to do.
Actually I’m glad to hear this. This is the way I use manuals, I always suspected that other people used them “properly” but now I know: everyone else does the same as me.
The minimalist solution proposed by Carroll is to make the manuals task oriented. Work out what the tasks the users will want to perform and explain how to do these tasks. In the process recognise that different users will require different tasks so document them as such. Manuals should be organized so users can find these tasks rather than by technical logic.
There is more to minimalism than this but I’m not a technical author so I won’t go into detail. The upshot of it all is: users learn how to use the software more quickly, are more satisfied, are more productive and the manuals are often smaller than the non-minimalist equivalents. But what I do recognise here is that a lot of these ideas overlap with the user interface ideas proposed by Alan Cooper in his book The Inmates Are Running the Asylum . And the same idea populates good product management or business analysis:
Identify your customers, understand what they want to do, really understand what they want to do, then cater for that need specifically.
Whether this is in the product you build, the user interface you design or the documentation you provide it all boils down the same thing: understand and be specific. Don't provide technology, provide the means to do something.
(Interesting I was talking to Tom Gilb at XTC on Tuesday. In his opinion one of the main reason projects fail is that they are not specific enough about what they are doing. There is a big conversation to have around the idea but not here, not today.)
Getting back to the book itself. If you are involved in technical authoring then I think it would be well worth reading either The Nurnberg Funnel or Minimalism Beyond the Nurnberg Funnel. If you are not technical writer then its not very clear if you would benefit from reading the book. If you want to know more about how people learn, or you are a product manager looking for ways to improve your products then it is worth familiarising yourself with these ideas.
I didn’t read all of this book, I read enough to understand the key ideas and understand what advantages they brought. This book is quite academic in style so it might be worth seeking out other books on minimalist documentation unfortunately I don’t know any so I can’t recommend any. There are more implications of this work than I have covered here. I hope to come back to these at some later date.