« The Occasional Frequent User | Main | The Meaning of Art, The Purpose of Technology »
The (In) Convenience Factor
By Micha | November 27, 2007
The motto and the objective of The User Advocate Group is to:
“Bridge the Gap Between End Users and Engineers”
Why is there such a gap? Well, there are many reasons such as: “language” differences (”geek-speak” vs. “human-speak”); lack of effective communication channels; economics; priorities (technology-centric vs. user-centric); etc.
But here’s one that came to mind recently as I was making my daughter’s lunch. I call it the (in)convenience factor. (How you pronounce it depends, I suppose, on your perspective – a half full / half empty kind of thing.)
You might ask: What’s making a sandwich got to do with using a software application? Well for a start both can involve tasks that should be simple. Using a well designed software application should be basically effortless - or at least rewarding and pain-free. It should be as easy to do as say… making a sandwich.
I’ve made my daughter’s lunch countless times with no significant experience of effort – until this one occasion. I encountered one of those bread bags that was sealed with a bit of sticky tape rather than the familiar and easy-to-use plastic clip. My response was to utter:
“#@#$(*@$??!!!”
And by that I meant “Why is this unnecessary obstacle preventing easy access to my loaf of bread???!!!”
And that’s precisely the kind of user experience any good designer should seek to avoid. Sadly, the world of software applications is full of bits of ‘sticky tape’ that prevent us from getting our work done efficiently and stress-free.
Later I reflected on why these bits of tape even exist. The answer I came to is the (in)convenience factor. My guess is that it was deemed convenient for the manufacturer to use sticky tape rather than the standard plastic tags clips. But what was convenient for the production process in this case was highly inconvenient for this end user.
Perhaps the rationale was profit rather than ‘convenience’ but I, for one, will never intentionally buy a loaf of bread sealed with a piece of sticky tape again. If others happen to agree with me then this could become a costly inconvenience for the manufacturer.
This is precisely what flashed through my mind a couple of weeks ago as I was implementing a navigation feature for a web site. I found myself tempted to lean towards convenience in code production rather than building an interface that would be convenient for the end user. Shame on me!
It doesn’t really matter what the specifics were – the point is that I had two options: get it done fast and grab an early lunch or get it done right - maybe after lunch. As ‘inconvenient’ as it was to my personal agenda at the time, I chose to do it right.
These kinds of twists and turns are the daily reality of software engineers. The risk is that always choosing the convenient-for-production route may ultimately result in serious defects in the product and in the ability to reach customers.
Of course at the same time the profitability of the production process has to be taken into account. In a larger sense, the convenience of production should really come from having a good strategy to meet the needs of both the customer and the business. It’s very inconvenient to not sell yor product and it’s also pretty inconvenient to rewrite it after you find out users are fleeing to the competition.
Great code doesn’t necessarily need endless labour – just a clear and meaningful plan based on an accurate view of user requirements and a realistic assessment of R&D capabilities. Such a plan is in fact the bridge between the end user and the engineer. And building that bridge is what we do at The User Advocate Group.
Topics: Uncategorized, user interface design, usability, graphical user interfaces, customer relations, user relations, customer service, user experience, Geekness, coding, ineffective communication, design simplicity, effective communication |