Learning to design makes better programmers.

Conversely, learning to design makes better programmers: “Learning Rails made me a better designer” — http://goo.gl/eSnpV”

I have long been a believer in cross-discipline approach to delivering software intensive solutions. This eventually lead me to learn everything I could about user experience. I think this blog post has it just right too:

Learning Rails made me a better designer” — http://goo.gl/eSnpV

A Blg post by Jonas, 37signals.

The Safari Reader button is a little unassuming gem

Apple initially introduced this feature with OSX Lion. When I saw it I immediately tried it then just as quickly forgot about it. The feature is still there on OSX Mountain Lion, and I only recently realised that I have actually been using it all the time without having noticed the point in time when I changed habits.

Your Mac, just like your Windows machine I guess, is full of nice features that you seldom use. If they were truly metering the usage of all the features that get thrown on new OS releases, I think it would be astonishing to see how much bloat creeps around unused.

Safari Reader isn’t such a bloated stuff, it comes in really handy for folks who frequently read articles on the web. Look at the two pictures attached below, it is immediately obvious which one you would prefer to see, that’s how useful the Reader button is. It is not available on all sites as I’ve experienced it, I didn’t try to find out why, but if you are aware of it, it can nicely enhance your reading experience without a sweat. That’s why I use it all the time.

Normal view of an article on Safari, before pressing the Reader Button
Normal view of an article on Safari, before pressing the Reader Button


After pressing Reader button
The same article on Safari, after pressing the Reader button

Conservative innovation as a path to better user experience. Avoid Feature Debt.

Designing sustainable user interface is a very hard task that could take a large number of retries. The wider an established user group is, the more conservative user interface design changes should be. If a complete user interface overhaul is required it may work out much better to present an entirely new product to users. Doing that sets an expectation of a new experience, this gives an adequate cognitive comfort to users.

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.