The broken link paradox
It is well known that developers and users view the same application from two different perspectives. In most of the cases these perspectives are completely opposite! Developers and designers are aware of the application and have a great knowledge of how it works which helps them understand better(?) and differently the interaction environment.
A great example of this phenomenon is something that I like to call “the paradox of the broken link”. I am sure that many of you came across this issue either as developers or as eventual users. It is really interesting how a broken link is differently perceived.
Firstly, let’s focus on the eventual users. They feel that the website hides something that is should be visible and accessible! In other words, they feel like something is out there but they can not reach it! A matter of great deal and importance. If you have trouble to place yourself in this situation, imagine that you are trying desperately to read a very important file from a semi-damaged CD… you know the feeling, right?
On the other hand, there is nothing more ordinary than a broken link for a web developer; especially during the development phase. A broken link can be easily fixed and therefore is not considered of great importance. A file is missing, a part of the website is still under development but that’s all!
The same principles stand for a non-functional button as well. I come across this phenomenon occasionally when I try to involve users during the process of the design and development. I always try to explain to the customers and users that what they are going to see is not a fully functional system and they should focus on a particular area. But every time I ended up with comments like “This link is not working” or “There is something wrong with this button” etc.
Lately I feel that this is my fault, that I use a wrong protocol and as a consequence I fail to give an appropriate definition of the problem and lead the users to a particular area. Maybe, it is time to do some relative reading and reconsider the protocol 
Popularity: 2%
- Previous post: Look ma, I got a Mac!
- Next post:Trips, shoots and drafts
It’s been my experience that this happens with more than broken links. In fact, it’s something that happens with all GUI control elements.
Lets say you have a flash element with a button whose actions you haven’t implemented yet, so the button is there but clicking it does absolutely nothing. Clients and even colleagues will inevitably come back to you and report that the button doesn’t work. If you make it pop-up an alert which reads something like ‘This is still under construction’, people will come back and report that the button is popping-up a message instead of working and it needs to be implemented.
What I’m getting at, is that anything you present to clients, or even higher levels of management withing the development environment, should be skinned down to whatever actually works. Put place holders where stuff isn’t ready yet, but don’t put interface controls unless they are usable. Interface controls are irresistible, and if they don’t behave properly they cause frustration. Links, buttons, selectors, scroll bars, get them out until they’re done.
Thanks for your reply George. I found your suggestion so easy and straightforward that I am wondering how I could not come up with it in the first place. Well, I guess this is the point where experience makes the difference, huh?
P.S: I am sorry it took me so long to reply to your comment — I have been quite busy the last few weeks trying to sort out both work and studies.