skip to content rich footer

stevenclark.com.au

subscibe to the StevenClark.com.au rss feed

Your Client and the Psychological Contract

As a developer there are two major entities which come to mind when discussing websites - the client (your customer) and the users (your clients customers).

The client relationship should be based to some extent on the physical contract which governs what will and won’t be delivered and the price of certain deliverables and penalties for being late. Physical contracts are an important part of getting things right to everyone’s satisfaction. You will also have these physical contracts with other entities such as hosting companies and so forth. But the physical contract is not the only contract in effect and in many ways its not even the most powerful one.

When you work for someone there is also a psychological contract which applies to your beliefs, perceptions and expectations about the job. The idea that you work for money alone on a one-for-one transaction basis is actually not true at all when you think about it. A lot of your job isn’t defined by money at all but through these perceptions being aligned with the reality of what you are doing.

In the opposite direction if you are hired as a developer and discover that the client only wants you to recreate their paper artefacts in markup and there is no creative design role on your part then you might well feel disgruntled. Maybe you get into a situation where you believe you’re going to be a front end coder at a corporate web firm and find out you’re just the coffee boy and gopher with no career path at all - this doesn’t match the job you perceived you were applying for in the first place! Hey it happens.

Its important to realise this contract exists because you’ll find most of your problems might be evolving not from the physical contract but from these unmet expectations between your client and you as an employee. What were you hired to do? What roles in the project do you play? Are your opinions respected and technical advice appreciated or do you find yourself the code monkey being told to recreate the clients paper artefacts as a web page?

One occasion saw me apply for an in-house job that said they wanted someone to think outside the square and who had new ideas. On my first day in the office it was apparent that any designer not able to create what the client wanted - directed from over the shoulder push this here and that goes there in that freehand font - would be summarily disengaged. No new ideas and the boxes were made of impeccable marble. No scope for realigning their marketing message at a more contemporary audience - podcasts NO, blogging NO, developing relationships with customers NO. What was my job again?

So its important to be aware there’s more going on in these client / developer relationships beyond money exchanged for goods.

But when you think about this concept it extends out to website users as well. Users also have a version of the psychological contract, they come to your website with the belief and perception they will get a service of some kind which aligns with their goals. A big part of meeting this contract is in the form of accessibility and usability. Their perception is wound up with the mental model they bring with them from a million other website experiences. They expect not to be offended, either culturally or sexually or racially, by the content (which could be as simple as a photo of an OK sign with thumb to index finger!).

Just be sure you’re happy with both of your contracts and if not then understand why its not an illegitimate gripe but a real business concept.

Articles are licenced under a Creative Commons Licence but copyright of images is retained by © Steven Clark 2007 - 2008

Comments are closed.

skip to top of page

Currently Reading

Information and Data Modelling (Second Edition) by David Benyon (Cover)With an eye toward implementing another web interface database solution from the ground up I'm casually revisiting David Benyon's Information and Data Modelling (Second Edition). Its critical to have a solid understanding of conceptual data modelling and knowing how to identify various things like fan traps and three way traps very early in the process. To that end, while its fine to have a basic understanding of third normal form and general ideas about relations (that which relational databases rely on), its also a great idea to spend time exploring the theory and case studies that lead to a higher understanding.

Often people I deal with just snuff their nose and say they can design a database - but often its a very naive approach. Having read this book about four years ago its time for a quick refresher over my holiday period. No, I doubt few will envy me.