Designing sustainable user interface (UI) is a very hard task that could take a large number of retries to get right. A technology powered solution that spares its users tedious learning will fare better than those who simply skim over such issues in favour of other agendas. Realising this makes me respect even more people who invented some of our everyday tools such as drinking glass, the pen and paper, and so on. This post is about highlighting some aspects of UI design decisions and why that is where conservatism should be preferred.
I always push hard to find out every detail I could about the problem domain that I am dealing with, preferring to postpone technology concerns until I know enough about everything else. Incidentally, this way of working tend to ruffle the feathers of those who prefer to skim over details, the manager looking for quick way out and avoiding any potential blame. I digress there a bit. In essence, looking to get more than one perspective of a problem domain makes me spend hours exploring wide ranging concepts, business and technical blueprints, various vendor solutions, looking to debunk blind-spots from the endeavour. Ultimately I found out that UI design decisions where happening everywhere even though people weren’t looking at things that way. In this post I’d like to highlight some of the learning points on user interface issues:
- A stable UI design will sustain several product revisions without requiring that users learn and adopt new behaviours. Designing and rolling out a stable user interface seems to be an extremely difficult task, partially because the UI scope is often hamstrung by blind-spots.
- Technology vendors that tend to frequently overhaul their UIs will upset users, cause people to scramble to adapt, disrupt well honed user productivity work flows, distract people from doing their real job.
- In software development texts you often read about “Technical Debt”, meaning that some corners were cut for technical reasons with the intention to make amend at some (often unspecified) time in the future. In a similar vein I also frequently noticed what I would call “Feature Debt”, which has a broader meaning than its technical counterpart and is mostly about adding clutter. I’ve not heard of this term before, so I am creating it to make my point. An example of Feature Debt is when people sneak in requirements that only reflect their own personal preferences far removed from the actual problems at hand. Another example of Feature Debt is when designers don’t envision the user’s daily activities while designing a solution. Feature Debts stemming from a technical way of thinking tend to result in cognitive tax on the UI experience. I will write a dedicated post on Feature Debt when I get a chance. The point here is that Feature Debt is really hard to fight, it goes against conservative UI innovation and coud cost dearly.
Changing the UI of a well established technology should not be taken lightly, because of the unnecessary upset it might cause. A symptom of Feature Debt is when a solution is deployed then outsiders react in bewilderment, wondering how such product release came to be. Another sign of this is when folks have to scramble to learn new habits for things that are otherwise plain and simple normal activities.
With this way of thinking in mind, I try to analyse new technology product releases that hit the market, sometimes you expect to see revolutionary new interfaces and may be disappointed not to find that. Sometimes new products receive negative media or user reactions, you wonder how that could happen when the organisations behind them clearly had all the resources they needed to get things right. It is always too easy to shout at bad decision making with hindsight, especially from an armchair executive perspective, but it is very difficult to spot issues as they are happening. People often seek prescriptions as an easy way out, some of shortcoming of such prescriptions is that they make our minds lazy and could be giving us an excuse to blame someone else if things don’t work out. To illustrate the effect of the mind laziness, imagine a situation where someone could perform a mental mathematic calculation but they stop trying if a calculator is at hand, over time they lose the ability to perform any mental calculation at all. That is also what happens if we keep looking for prescriptions and stop thinking things through by ourselves.
One thing that could help in IT driven initiatives is to look out for Feature Debt, they typically won’t survive proper user testing, won’t make it through the “five whys”. Feature Debt has a snowball effect, everything that trickles down from it will amplify its negative impact. When a group or organisation is caught in Feature Debt, very smart people might totally overlook obvious faults simply because they would imagine that fellow smart people must have vetted things and nobody wants to look bad or sound like they are obstructing. Such invisible pressure would nurture Feature Debt, people would start rationalising them and after a while feature debts become indistinguishable from real user wants, that’s when the damage potential is maximal.
Conservative Innovation is about looking for those precious UI experiences that must be preserved as one innovate, actively looking for Feature Debt and removing them from the picture before they grow and become ingrained. The conservative part is really about avoiding changes in what is already working well. When considered this way, examples can be found in a lot of successful products out there. This is also what drives copy-cats because they don’t risk trying something new, they try to follow what appears to be working and accepted by communities.
This post isn’t asking to avoid change, that wouldn’t make sense. But rather, this is about ensuring that user comfort is sought and protected very early on and often as you go about innovating.