Are Employees 2nd Class Citizens?

Customer Experience
"They (user) should just use it the way we tell them to"
"Do they want us (development team) to just spend more and more money on fixing speed...because we can"

These are some statements I have heard from frustrated members of IT project teams striving to deliver a working product. Now, I believe "the customer (end-user) is always right". Not "right" in that they get all the bells and whistles with minimal business value. But right in that they deserve to be listened to and managed fairly. It isn't a secret that the internal applications that are not direct revenue generators are usually less smooth, less user friendly and can be unattractive. Why? Is it because their employer pays them to use it? Is it difficult to present a compelling business case to spend resources on user experience and overall design? You might get away with treating employees as second class citizens and deliver a working application. 

However, it may very well be a painful and frustrating experience to get there. The SARAH model, will tell you that people handle change in a curve. It starts with shock and anger which develops into rejection. How the user is managed during the rejection phase is key because they can stay in this phase for a prolonged time and create conflict. The project team must be sensitive to these reactions and support the users emotionally. It sounds like therapy but it will make all the difference. If the benefits of change are really difficult for the user to see that should be a red flag and action should be taken. Ultimately, you want to help the user reach acceptance and hope whether you are a public end user or an employee the experience of a new application being deployed will influence the adoption. Of course there is no simple solution to managing the needs of hundreds of users but a feedback loop goes a long way. So how can you make your users feel not like second class citizens?:

  1. Engage: Let them know they have been heard by proving their feedback has been documented and respond to that. A response builds trust regardless of regardless whether it is good news or bad news.
  2. Be transparent-Explain why a feature may or may not be included. Any IT project worth its salt will have the overarching requirements. There should be an underlying reason for each decision made. Explanations should never end with "…because your senior management said so" or “I’m just doing my job…”.
  3. Use the Fair Value Principle- Where there are various stakeholders with personal interests, stakeholders should be convinced to decide on “fair value” outcomes when prioritising the “must have” features.

Annabel de Souza


Annabel is an experienced, entrepreneurial consultant with an eye for design, with thorough knowledge of business analysis.