If You're Going To Blame The Programmer For Not Being A User, Why Not Make The User A Programmer?
from the simplicity-isn't-simple dept
As we were recently discussing, the focus on "simplicity" is absolutely wrong. It implies the wrong thing. People want a product to be simple to use, but they want it flexible enough to be used in many different ways -- and those may be quite different for different people. And, that's where things get tricky. It's not just that programmers think differently than users, or that marketing folks can't explain clearly how a product will be used, but that it's nearly impossible to figure out how a product will really be used by users until they're actually using it. At that point, you want the flexibility to add in certain tools or features that become more obvious -- but may only be obvious to certain subsegments of the user population. At the same time, you don't want any of this to overwhelm those who are using the product for a different purpose.
What will be most interesting is to see what happens as situated software products start hitting the market, with the idea that the users can make their own damn programs -- avoiding the disconnect altogether. While it sounds tempting, it also seems likely that complexity would actually increase, because each user has very different features and requirements -- and they're not designing the product for overall usability, but for their own satisfaction. In that case, much like the officeworker who keeps a ridiculously messy desk (which, yes, includes me) but knows exactly where everything is, complexity actually works for that person. So, rather than blaming programmers for not making software simplistic enough, perhaps programmers should start handing over the design tools to users, and then laughing hysterically at the not-so-simple products that come out of it.