The Importance of Starting

I should read more. That’s the conclusion I draw from having to start a post by quoting a quote from another source.

About a month ago I was catching up with the blogs and sites I usually follow, and I stumbled on this great quote from W. H. Murray in Merlin Mann’s 43 folders web site:

Concerning all acts of initiative (and creation), there is one elementary truth the ignorance of which kills countless ideas and splendid plans: that the moment one definitely commits oneself, then providence moves too. A whole stream of events issues from the decision, raising in one’s favor all manner of unforeseen incidents, meetings and material assistance, which no man could have dreamt would have come his way.

I read it with a slight disbelief, yet end up feeling of strangely motivated. I mean, sure we all have had one of those moments where fortune/fate/karma/whatever you call it just unrolled a red carpet right in front of you, waving in your face just the thing that you needed but you never thought you would get – at least that easily. But, come on: to insinuate that the simple act of committing yourself to get something accomplished will somehow make the world work in your favor seems sort of a cheap 80′s MacGyver TV show script… And yet, in retrospective, it actually shapes itself as believable.

The motivation and results loop

A friend of mine in Transientis.com just blogged the other day about how things had started to change since the day he committed himself to starting the blog. He finally got himself to undertake some plans he had been procrastinating on for quite a while. This was all because, in his case, he could feel the cogwheels turning, and that alone gave him the necessary motivation to do things to keep them turning. I sure hope he keeps at it.

Of course, this doesn’t mean that every time you commit yourself to something it will all work just the way you planned it. Sometimes you will end up in a situation that was not exactly how you pictured it initially, and other times you’ll just face shame, defeat and several body injuries (or at least 2 out of 3).

Stability

The message is: do not ever underestimate the simple act of starting. Re-read that sentence and let it sink in, because I’m pretty sure that you might have missed something there. That’s just it: the simple act of starting.

The shocking truth is that most people are afraid of starting. People love stability: the stability of their homes, the stability of their income, the stability of knowing that Friday night is poker night with the guys, or just cuddling up in the sofa and falling asleep watching TV. People just love taking things for granted – which doesn’t mean that people love the things they take for granted.

And I’m not just talking generically about the meaning of life, I’m pointing a finger at our everyday jobs in the IT industry.

Some time ago I was working on a desktop application which had a small yet faithful user base. It was one of a kind, it did amazing things and had absolutely no substitute product.

Having no substitute product AND a small yet faithful user base can be great because it means that the developers can work closely with the users, and gather enormous and meaningful feedback to improve the product. On the other hand it also means that the users have to use it even if it required them to type text using Morse code through a serial computer port connected telegraph machine. While pedalling to keep it powered.

Luckily that was not even remotely the case and, as far as I know, no such device was ever manufactured.

Still, having a devoted user base is not always a good thing; a prolonged usage of any product will see the users become attached to the great things, and will eventually take them for granted and won’t be able to imagine their everyday work without them. They will also recognize the effort that was put into making “standard” things accomplish what they are supposed to do. They will think “This is great, this works exactly like it is supposed to” even if they’re just referring to the “Exit Application” button.

The big problem is the things that the users will just settle to live with. These are the things that the users will find weird at first, but after some days they’ll just keep on using it without quite being able to place the finger on what’s wrong. Some of them will be so in love with the whole product, that when facing these minor annoyances they’ll just say “Honey, it’s not you; it’s me.”.

The bad news is that, most of the time, the developers are not able to understand that there’s anything wrong at all – or if they do, they just face it as a minor problem. They have been so enthralled by their creation for so long that they actually learned to love it unconditionally. Luckily though, beauty is in the eye of the beholder, and useful feedback is in the frustrations of the first-time users.

The epiphany

If you never had the chance of watching users without previous experience with your product or application interact with it, I think it is time you should. There’s just an enormous amount of feedback to be taken from such experiences, but I digress – that’s another topic I want to go back to another time. Still, that was what I was doing at the time: reviewing first-user interactions, completing and prioritizing a backlog of issues related to user interaction with our product. These ranged from things that were immediate in the user tests to things that dated back to the beginning of time but had never been done.

I already had a fair share of experience with the application, so I fit perfectly in the devotee stereotype – for good and for worse. I was used to it being that way, and I liked the stability that, even though it wasn’t 100% perfect, it worked – and reliably at that. I took the functionality and the design for granted – it was there and I grew accustomed to it. The risk of changing something for worse actually frightened me, because of the whole impact it would have on everyone: I would ruin everyone’s stability. As such, I just tried to focus on doing just enough to solve – or lessen the impact – of the exact problems we had identified.

To improve this particular user interface, since there were no direct substitute products, I had to investigate a bit to see how – and if – others were tackling this same problem.

During these investigations, I stumbled upon a particular application whose main focus was a specific part of the area of our application which I was working on. My first reaction was “So this is how it should look.”. I had been the one who had lived with our application’s minor quirks, saying “No honey, that dress doesn’t make you look fat, don’t be silly.” because I had never been able to picture it in a different – slightly sexier – outfit. And at that moment I committed myself to realize this vision, to change that user interface and help our team deliver something grand. No more hit and run jobs, with the fear of compromising some other aspect of the big picture. No pressure on fixing the misbehaviours one by one. I was thinking on a grander scale now, I was going to try and change the causes, and not correct the consequences.

Of course, it would have been too self-assured of me to think “Ha, how come no one has thought of this first?”. The truth is, most likely many people thought of it first for our application – and actually tried it before – but for one reason or the other it had ended up that way because it was the way that it could be. But that wouldn’t demotivate me. I had committed myself to start. And so I did. I just prototyped the simple cosmetic change, and suddenly it did not seem like the same application – and people would stare at it at first, but when they felt it in action the couldn’t quite place why it felt different, yet strangely normal. Apparently, I had managed to change things without compromising everybody’s stability.

To cut a long story short, the limits to the greatness we could achieve were actually the DHTMLEdit’s VB6 control’s limitations: soon after I started hacking and slashing through it, and some hallway usability tests later, I realized why it had been done the way it was in the first place. Though this different approach solved a few problems, it actually introduced some unwelcome minor glitches. It was different, but I wasn’t sure that it was better overall. The stability had shaken not in a good way, the “vision” had to be re-focused.

The good thing though is that now the cogwheels are turning, the world is spinning, everything is in motion. Colleagues drop by with suggestions on how to work around the problems I face in this path. People are actually envisioning things, and are motivated by it.

Eventually we will settle for something that may not be what the initial vision was like, but hopefully it will be different from the starting point. If we can pull it off, it will be new, refreshing, and most important of all, easier to work with. And if it proves wrong, well, worst-case scenario, we always have our CVS repository to revert the changes. It is a win-win situation most of the time.

Conclusion

The points I’m trying to make are:

• You should not have to live with something that just doesn’t feel as right as it should. Don’t be afraid to question anything that’s stable, yet feels wrong. In some cases, it might not only be stabl, it might be stale.
• Starting is the single most important action to changing things. You don’t always have to know where you want to end before you start; you just have to know that you want to go somewhere else.
• Different isn’t (always) bad. And for what is worth, if the change makes you see things from a different perspective, that experience alone is worth the effort even if you end up going back to the starting point. If that’s the case, don’t beat yourself up too hard – failure only happens to those who have the will to try and do something.

Do these make sense to you?

Advertisement

Explore posts in the same categories: Technology, Usability