Michael Nielsen explains Shirky’s Law, and more specifically, why most social software fails:
The first reason is that developers often have a flawed mental model of their own software. Imagine you’re developing social software. You spend hundreds or thousands of hours on the task. In your mind’s eye, you imagine the user interacting with your software, and reason that if the user is given more capabilities, they’ll be happier.
There’s an implicit mental model being used to make decisions here. It’s a mental model of a system with two parts – the software and the user. A real user’s mental model is quite different. It’s them, the software, and the entire network of other users. How they use the software is strongly conditioned on their mental model of how other users use it. If they lack confidence in that mental model, they have less incentive to use the software themselves, as the Nature Network example shows. The more social the software, the stronger this effect.
Even if you suffer form social software fatigue and want to harm people whenever you see these two words together in a sentence, I encourage you to take a few deep breaths, relax, imagine all tests are passing green, and then go read this post as a general advise, using one particular type of Web-based application to make a point.
And the point is, focus on the mental model that gets stuff done with the software, not the mental model that builds the software.
People who use your software have a mental model of the things they do with your software. The relationships they make (or break), the jokes and trivialities they exchange with others, the documents they publish, the orders they fulfill, the service requests they answer. Whatever they do.
We developers have a mental model of the software itself. We have to. Software wouldn’t exist if we didn’t spend hours creating algorithms and organizing code, hunting elusive bugs and fixing compatibility issues, tuning and optimizing. We know the innards of the beast better than we know how it’s being used.
And right there is the mismatch between what people need and what the software industry produces.
Most issues I see with the software I use boils down to that. You get smart developers who can tell you which objects get created when, what API or protocol is being used, how data gets stored. But not what goes in the mind of the person trying to use it.
Even development tools suffer from that same problem. Too many of them are designed around the implementation, not around the workflow of the developer using them. I’d say most are like that. Which doesn’t help, but rather ingrains the bad habit into the development cycle.
It’s hard to illustrate without a concrete example, which is why I’m sending you to read Michael’s post. Another good example is Git. It’s full of commands and options that let you operate on objects and trees, but it doesn’t have enough commands to support the next action you, as a developer, intend to do.
I know I’m going to get an earful on this remark. “git co -b foo is just as clear as branch to foo” “Don’t use Git if you’re not willing to learn it” “Create aliases for your common uses” Yes. I could and I would. But why do I have to? Why can’t it just have commands for the common development tasks? With so many people using it, you can guess what my next development action is going to be, design for that.
I don’t mean to pick on Git, it’s not alone and not even half as bad as some other tools, and if anything better than the source control systems that came before it. Let’s not even talk about those.
I just picked the first example off the top of my head, which happened to be one of the last things I used today and met the criteria of “lack confidence in that mental model”. I really never trust that my magic incantation of commands and arguments would get the next task happening.
It all starts with the tools we use. We’re lax in caring about the user’s mental model there, and it just permeates to the rest of the development process. So while this advise is for everyone developing software, if you’re developing tools for developers, please. Make it about the user’s mental model. Help us start on the right foot.