After we write and ship code that probably contains a bug or two (or three), our job is to then write more code, which will also contain bugs. It’s a bad cycle.
This means that someone has to be in the middle, as the face of Flickr, acknowledging these mistakes and going to great lengths to fix things. This is often a thankless job, as users just want their problems to go away and developers (usually) don’t like to be told they messed up. But they do it for the good, and for the love, of the site. Every bug that gets filed and every support case that gets carefully answered makes the site that much better.
After being a liaison between these two worlds long enough, you end up knowing more than anyone else on the team. When you have millions and millions of users that hit every button and link in combinations you would never dream of, then reporting the “interesting” outcomes of their explorations, these support agents become walking encyclopedias of the ins-and-outs of the site and with Flickr, there are odd edge cases waiting on every page. Having people on your team aware of everything the site does is huge. You literally can’t buy that or replace it or outsource it, though it appears that Yahoo thinks it can.
When you spend all day working with the same piece of software your definition of what is easy for someone else becomes horribly skewed. Since I started jamming with the CoPress gang in 2009, I have spent thousands of hours staring at a WordPress dashboard. It means much of the WordPress interface is easy for me. That’s dangerous.
I try to minimize the number of times I use easy in a support reply. I avoid phrases like “Setting up custom menus is easy…” or “Writing a new post is easy…” There are a few reasons for this.
First, if a feature or product were legitimately easy the user would not be writing in to support about how stuck they are. Sure, some percentage of users will find questions to ask about any interface. But do you want to start the conversation by assuming the user falls into that percentage? You venture to learn much more if you assume the software is wrong, not the user.
Second, describing something as easy sets a dangerously high bar for the user when they walk away and try it for themselves. Before you characterize a feature as easy you should be certain it actually is. If you say “easy” and the user does not get it they will, at best, feel like they are wasting your time and, at worst, feel like it is not worth using your product.
Finally, the worst part about saying a product is easy is that it immediately starts the conversation by putting you in command. You are the expert. You are the one who said it was easy. In some cases that is okay. It will work out. But doing so shuts down your opportunity for learning from your users. If, instead, you think back to the days when you did not know everything, you can start the conversation on an equal ground. Help the user accomplish their goal but also learn about where the pain points are so that you can make the user’s experience, and your product, better.
The best support is a conversation. The best support happens when a user learns how to do something new and you learn about how your product can be better. This can only happen when you do not immediately think of your software as easy, intuitive, or simple. If you can remember that you too were once new to things you will end up with a better product and, most importantly, happier users.
Copying only got easier following the passage of these laws—copying will only ever get easier. Right now is as hard as copying will get. Your grandchildren will turn to you and say “Tell me again, Grandpa, about when it was hard to copy things in 2012, when you couldn’t get a drive the size of your fingernail that could hold every song ever recorded, every movie ever made, every word ever spoken, every picture ever taken, everything, and transfer it in such a short period of time you didn’t even notice it was doing it.”
Cory Doctorow – Lockdown: The coming war on general-purpose computing.
Locked in the Ivory Tower: Why JSTOR Imprisons Academic Research. The proscriptive part of the article is shallow, but the process of how an article gets published is fascinating. If you’re looking for an area of higher education ripe for disruption I’m not sure it gets much better than this.
Continuing in the style of last week I spent most of today reading my Instapaper backlog and listening to podcasts. Good day. Here are the highlights:
- Happiness Takes (A Little) Magic
- All aboard the Cocaine Express
- The Devastating Costs of the Amazon Gold Rush
- The New French Hacker-Artist Underground
- Lockdown: The coming war on general-purpose computing
- Back to Work episodes #48 and #46
- Seminars About Long-Term Thinking: Universal Access to All Knowledge
Making It in America. What manufacturing in America looks like in 2012. Fantastic work by the Atlantic.
The first 80% of a blog post writes itself. The rest? It’s like pulling teeth sometimes.
Jonah Lehrer on concussions in adolescents and the future of football. There is a part of me that wishes I played football in high school. I think I could have been a decent wide receiver. Reading this article makes me glad I didn’t.