Errata for 1.4:
"though ambiguous times" should read "through ambiguous times".
Many thanks to reader CB for finding this.
Errata for 1.10:
"Brand products well, to differentiate them," should read "Brand products well to differentiate them,".
Many thanks to reader CB for finding this.
Errata for 3.2:
A sidenote refers to 2.2 for more on negative space. It should really be 2.1.
Many thanks to reader John Hanauer for finding this.
Errata for 3.11:
There's one sentence that I think I misstated, and want to clarify. It goes like this:
[Functional specifications and wireframes are] often discarded early in the process, and at worst they're continually fought over.
I think a better way to frame this is that users don't see wireframes. They see finished products. And (your mileage may vary, but) I've found that often, clients don't know how to critique a wireframe. So I'm an advocate for working quickly, and going straight to code as quickly as is appropriate. Often that involves cutting wireframes out of the process.
In large projects, this isn't a viable option, nor should it be. So I think the best way to address the nature of our work is by asking how we can streamline this process while building consensus. I didn't do that in this passage, and think it's tremendously important to address.
Many thanks to reader Gabby Hon for bringing this to my attention.
Errata for 4.1.4:
The final sentence of the first paragraph should read: "And when they have bad experiences, future impressions of similar products are tainted by that negative impression.
Many thanks to reader Jaan Altosaar for finding this.
Errata for 4.2.7:
On page 73, section 4.2.7 of Cadence & Slang goes as follows:
4.2.7. Controls should show the function, not the state.
When a control toggles between two states, it should convey that selecting it would trigger the intended behavior. For example, if you have two states for a control (On and Off) and it's currently off, the control should read On, so as to convey that triggering it will turn the thing on. Then, once its triggered, it should turn on, and change to read Off.
There are two problems with this rule.
1. It is only applicable in situations where it's unclear that a switch-like control is being used, such as buttons or links. This is what I thought of when writing the rule in the first place.
2. As a result, the example is dead wrong. On/off switches are perfect for exactly the opposite of the rule that I'm prescribing. Note, in software, the switches of iOS ( 
), as well as traditional light switches: when they're turned "on," they read "on." This is simply good feedback; it would be counterintuitive to note the function.
The rule should have expanded to include both of these as examples, to show when a control showing the state is (and isn't) appropriate. There may be one-off exceptions to this rule, as well as types of controls that haven't yet been invented, but for now I think this solves the problem sufficiently.
Here is how 4.2.7 should read:
4.2.7. Controls should show the desired function when it's unclear that they toggle between multiple states. Otherwise, they should show the control's state.
When a control toggles between multiple states, it should convey that selecting it would trigger the intended behavior. This should only work for toggles that don't clearly convey the idea of "toggling," such as buttons and links. Switches and switch-like controls should instead convey their current state.
It's likely that most toggling controls should be represented as switch-like controls. Be sensitive in using controls that conceal possible options.
I'll leave the examples as an exercise for the reader.
I apologize for any confusion about this point, and hope that this helps shed some further insight into my reasons for including it. If you have any questions about this or any part of Cadence & Slang, .
Many thanks to reader Anders Kierulf for his insights in the process of researching this.
Errata for 7.7:
The link to usability.gov's page about contextual inquiry has been removed, with a redirect in its place. You can read the original page at the Wayback Machine.
Many thanks to reader Jaan Altosaar for finding this.