That’s what this kind of preservation work does. It gunks up our machines. It makes us rethink what we believed about our history.
Dust to Digital, assembling folk music archives of the American South.
That’s what this kind of preservation work does. It gunks up our machines. It makes us rethink what we believed about our history.
Dust to Digital, assembling folk music archives of the American South.
The worst assumption I could make would be that I have it all together. That I have it all worked out and never have to change my lifestyle, habits, or work routines.
Living proof that focus and diligence are moving targets by Shawn Blanc.
Took advantage of Portland’s annual fake-spring to get a 3.5-mile run in on the waterfront. Totally looking forward to running in nicer weather more consistently.
Adjunct professors get poverty-level wages. Should their pay quintuple? The SEIU is organizing adjunct professors together around the future goal of $15,000 per course. Improving adjunct working conditions is long overdue. A side note worth noting is that part of the reason I went to Whitman was their expectation that tenured faculty actually teach.
The sharing-economy companies are not a way to temper capitalism (and its tendency to generate selfish individualists); they just allow it to function more expediently.
Authentic sharing, by Rob Horning.
Best, Propst believed, would be to join the panels at 120º angles. But his customers realised that they could squeeze more people in if they constructed cubes. A rigid 90º connector was therefore designed to join a panel to one, two or three more. Thus was born the cubicle, and Propst came to be known as its creator. He was horrified.
Inside The Box, a brief history of office design.
I read two articles about books and their future this morning. The Millions has a feature on Tumblr’s Reblog Book Club. It’s a refreshing example of creating space for productive discussion online. Om Malik also has an interview up with Matt MacInnis, CEO of Inkling. The idea of unbundling everything we use the book for into its component pieces really appeals to me.
At some point (probably one we’ve already passed), weblog technology will be seen as a platform for so many forms of publishing, filtering, aggregation, and syndication that blogging will stop referring to any particularly coherent activity. The term ‘blog’ will fall into the middle distance, as ‘home page’ and ‘portal’ have, words that used to mean some concrete thing, but which were stretched by use past the point of meaning.
Clay Shirky writing in 2003. Pretty prescient considering that’s 12 years ago.
Last July Ryan Pitts and Sara Schnadt led a session at SRCCON about human-driven design. It wrapped up with a discussion of various maxims that guide design processes. Someone in the room said it was important to remember that, “users won’t read, ever.” That rubbed me the wrong way at the time and I went on a mini-rant in the session. I was thinking back to this recently and wanted to sketch the idea out into a longer post.
The perception that people don’t, and won’t, read documentation is not uncommon. There’s a reason we have the acronym RTFM after all. I think it’s a perception that’s horribly misguided and short-sighted for your product.
People will read. What they won’t do is unquestioningly read on your terms.
When you’re developing a product you don’t ship something and passively wait around for it to become popular. If what you shipped isn’t gaining traction you iterate. You tweak and adjust until your product fits its addressable market.
For some reason we don’t approach documentation with the same mindset. Our predominant expectation is that we can ship docs and expect every person to read them. If the docs have up-to-date screenshots, are detailed, and are searchable then that’s enough. If people don’t read, that’s their fault not yours. That’s a fundamentally broken expectation.
Most importantly, if you react to support requests by wondering why people can’t read the docs then you are missing a golden opportunity. You are directly blaming the person using your product instead of blaming your product for requiring documentation in the first place.
Part of the RTFM-mindset stems from an assumption that everyone is an exploratory learner. That’s wrong. It’s arguably true for many tech folks. That doesn’t make it true for many people using our products.
Exploratory people will find their own way. They are comfortable with uncertainty. They’ll use a confusing product and feel confident relying upon documentation for answers. To them this is part of the appeal. Each awkward setting or obtuse workflow is an opportunity to master the intricacies of yet another product.
Prompt-driven people will read docs, but it’s not their default. They will first look to your support team for help. You could also think of them as human-reliant people. Interactions with your support team may prompt them to read and reference docs. So it’s not that they won’t read. It’s more that they prefer human interactions to help guide them.
Here’s the thing about prompt-driven people: they are a potential gold mine of qualitative feedback. There is no better source of information to help guide your product teams. Yes, this means your support team has more tickets to respond to in the short-term. That’s a great thing.
Every one of those interactions is an opportunity to learn more about how people use your product. If you choose not to take advantage of that and instead blame people for not reading your docs and leaving you alone in your cave, then that’s your loss. The next time you find yourself blaming a customer for overlooking the “obvious” answer in your docs, ask yourself whether you’re reading enough of what they’re telling you. More often than not I think it’s those building a product that don’t read, not our customers.
Thanks to Simon for helping clarify some of the wording in this post.