Why does it need to be Configurable?

So, you’re building a widget, for example, a temperature sensor. Do you display the temperature in ℉ or ℃?
The answer, of course, is “it depends”
• You might be able to get away with a switch that toggles the display between ℉ and ℃.
• OTOH, If this is going into an airport, with travelers from around the world, you might want to display both
And so on. The point being, the amount of configurability that you throw into this depends entirely on what you plan on doing with it, the requirements for your widget. After all, the switch, while effective for home use, is actually counter-productive for airport use, no?
And that brings us to the User Experience. When you’re building out any UI, be it the simple widget above, or something far more complex like a online trading system, you have to approach configurability from a UX perspective!
The vast majority of UI out there falls into one of the following two traps
  1. 1. Feature Overload: The user has the ability to customize every aspect of their experience, for better or for worse (and usually for worse). Whenever the developer wasn’t sure whether to use option A or B, they left it up to the user. And yes, sometimes the defaults are sane, but oh so frequently they are anything but.
  2. 2. Steve Jobs Syndrome: Taking Jobs’ mantra to heart, they remove most of the configurability from the system, giving users a single path. Which is great when most users want (or need!) a single path, but can be unforgivingly stifling when user’s want (or need!) more freedom.
The thing is, Feature Overload and Steve Jobs Syndrome exist on a continuum of Configurability. Where you land on the spectrum should depend entirely o the User Experience you are going for. And yes, if you don’t figure that out up front, it will come back and bite you, and quite probably at the most inconvenient time possible!
Mind you, this has very little to do with the inherent complexity of the system you are building. From Asbhy’s First Law, The greater the complexity (Varietyin cybernetics) of the system, the more toggles you will need to be able to manage it. And if any of those toggles can be eliminated, then, by definition, those are aspects of the system that you don’t care about, and/or didn’t exist in the first place. The bottom line here being that the above spectrum is entirely orthogonal to the inherent complexity of your system, you can un-necessarily constrain users — or expose too many features — for systems that are extremely simple (the temperature sensor), or extremely complex (Think Macs vs PCs back when. Or Anything vs Linux now.)
So yeah, the next time you’re considering just adding a toggle because you can’t decide, slow down, and figure out why you need that toggle in the first place. And, of course, document the answer!

Comments

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

Its time to call Bullshit on "Technical Debt"

Visualizing Prime Numbers