It is still a common complaint uttered by usability professionals that organizations in general and software developers in particular “just don’t get” usability engineering. They are frustrated because they have all good intentions to provide support for creating user-friendly systems but the reactions they get are reserved at best and developers simply don’t buy into the whole usability engineering process.

So, whose fault is it? Who is it that is just not getting it?

As often in life, it takes two and an occasion to create a problem. Let’s have a closer look.

Obstacles to Cooperation

• One fundamental detriment to the cooperation between usability engineers and developers is the lack of explicit scheduling of this cooperation in the project plan. Very often, the communication between the two parties is indirect or sporadic at best. Developers are provided some documentation in form of style guides and the like and usability engineers are given access to technical documentation in case it exists. Beyond that, there is hardly any contact going on. This can especially be the case if usability engineers are involved late in the project to perform some just-in-time usability optimizations.
• Another basic problem arises when there is a lack of alignment between usability engineering and software engineering processes. Very often, usability engineers are rooted in waterfall-ish approaches that don’t go along very well with more agile development processes. So, while usability engineers are still busy working out personas, developers are already in their third sprint and the usability engineer’s input is rendered useless.
• Even if there is communication between usability engineers and software developers, other obstacles can arise, for example in the form of an “I know better” attitude. Each one of the two parties knows better how to tackle a problem and judges the other’s approach as deficient or even a waste of time. What both miss is that each of them knows better – in their own respective area. This may lead each of them to the belief that the own competencies somehow outweigh the other one’s in terms of impact they should have on project execution. What can create a particular problem for the usability engineer in this respect is that his job is somehow seen as “common sense practice” that does not require any particular expertise and can basically be done by anyone. This may lead people to the impression that they do not only know better in their own area of expertise, but also in the usability engineer’s.
• Suppose communication is explicitly foreseen in the project plan and each of the parties knows their limits and respects the other one’s expertise, there is still no guarantee for success. The communication has to take a form that is beneficial for both parties. Take documentation as an example. Sometimes, usability engineers take great pride in creating extensive documentation, giving rationales, illustrations and so on. What he forgets is that someone has to actually read all that stuff and relate it to his own work to make something of it.

So what to make of this? Is there hope that usability engineers can more than co-exist in the same project: that they can actually cooperate in an efficient manner (and even have fun while doing so)?

Foundations for Cooperation

If some basic ideas are adhered to, there is a pretty solid foundation on which usability engineers and software developers can build upon in their joint effort to create user friendly and technically solid systems.

• First of all, as trivial as it may sound: the communication between usability engineers and developers has to be explicitly foreseen in the project plan. One should not simply take the stance that these two parties will somehow cooperate or notify each other if they require certain information. In larger teams, contact persons should be nominated who are responsible for collecting and disseminating information.
• Secondly, the processes in usability engineering and software engineering should be aligned. In practice, this usually affects the usability engineer more than the software developers, at least when he is working as an external consultant who is brought into a project in an organization with established development processes. A good usability engineer has access to a wide range of methods and tools, which, combined with the usability engineers’ experience, can be made to fit virtually any development process, from waterfall to agile. This affects, for example, the scheduling usability engineering activities and their coordination with software engineering.
• Thirdly, and as a separate bullet point because of its importance, the documentation used should be designed and made available in a way that maximizes its impact. Online documentation, annotated prototypes, posters to place in the lobby – whatever it is to really get the point across and provide common ground for the team in a timely way should be used. There’s hardly anything more detrimental to a project than having documentation collect dust in shelves or on servers because the people who should read it are busy doing other things, and rightly so.

And finally, leaving one’s ego at the door can help. Trusting in the fact that all parties involved know what they are doing and try to put their knowledge to the best use is a good working assumption.