Clearly, these sorts of strategies have applications well beyond restaurant menus. About 15 years ago, taking a usability engineering class from Randy Pausch a

Clearly, these sorts of strategies have applications well beyond restaurant menus. About 15 years ago, taking a usability engineering class from Randy Pausch at UVa (yes, that Randy Pausch), I worked with a team that was determined to develop a "cheat sheet" to help CS students debug the awful HP Laserjet IV printers in the UVa CS lab. Think "PC LOAD LETTER?! What the f* does that mean?!" After several user rounds of user-testing, we found ourselves using similar tricks. While iterating on documentation that would maximize our users' success, we occasionally found it necessary to provide partial information or even outright lie to the user! While this sounds under-handed, it was done to (1) help the user accomplish their intended goal (e.g., fix the damn printer) and (2) ensure that the user read enough of the instructions to be able to perform the task. In all seriousness, we found that most CS students, unsurprisingly, do not have the patience to RTFM. But we were ultimately successful in tricking them into doing the right things. How we phrased and partitioned the branching instructions turned out to be more important than providing a deep understanding of the printer itself. Then again, some of the solutions to HP LJ IV problems, derived from their awful awful manual, seem like voodoo. ;-)