On a typical day at Online Business Systems, you can probably hear the UX team yammering on – to just about anyone who is willing to listen – about the benefits of user centered design (UCD), the importance of well-defined personas, and how we strive to build for the user. By bridging the gap between our understanding of human emotions, motivations and goals, the user experience design approach attempts to create better programs that are more suited for the users. The theory is that if we know what the user wants to accomplish and we develop the exact tools for them to do so, the users will be happy, the company will have less to support, and profits will increase.
Convincing others within the organization on the fantastical magic that happens with UX is a walk in the park, but on the other hand, convincing a client of its grandeur can be a completely different story. Let us paint a typical scenario in which we are attempting to convince a client to use UCD.
At the start of a project, we can tell the client about the potential for increased sales or whatever they wish it to be, usage savings, support savings, and reduced development time.
We can then show off our UX portfolio, provide them with compelling statistics, encourage them to follow best practices, and tell them that we can deliver and increase their profits.
Despite the fact that UX can do all that and more, UCD just sounds like another process, one of the many that they may have tried in the past. All this talk about benefits and gains can be very enticing, but nonetheless, it is akin to advertisement and can sound much like a sales pitch.
As a result, it is not surprising when clients nod their heads in approval, check our previous experience, and then entrust us to “do what we need to do” to deliver on time and within budget. That could work if it were not UCD. However, unlike other development or design strategies, UCD is not a solo-project-team task. Project teams do not disappear and reappear with a finished product, but rather require a great deal of communication, participation, and support from the client.
When a client does not understand their role or fully support the UCD process, there can be some significant risks introduced (e.g., cost overrun, requirement gaps, developing the wrong product for the wrong user, etc.). Getting the full backing and participation of the client can be a very difficult task and the UCD approach requires involvement and cooperation from all parts of the business.
There may be various departments within the client that are opposed to the very idea of letting the user be the core of the project, or they may hold conflicting ideas about what should or should not be implemented. How can we convince the client and its stakeholders that doing user research, defining the interaction, designing the UI, and developing around the user is a good approach?
To address this concern, we can take on a well-known phrase: “The enemy of my enemy is my friend.”
This “enemy” could be anything really, as long as it is understood and is passionate with the client. For instance, a client who deals with relationships could relate better to UX metaphors of love and getting users to experience the highs and lows with the website. By relating to this common enemy, we can excite and unite the client to channel something that they really believe in and get them to then focus together in addressing the problems and gaps which are affecting its current users.
Here is an example of a situation I was dealing with recently. Before starting at Online, I was working for an emergency air transport organization. There were a number of potential projects ideas discussed, one of which was an overhaul to the current electronic patient care record (ePCRs) systems.
This ePCR system is used by emergency caregivers to provide a documented record of care provided to the patient and serves as a means of communication among clinicians. In talks with various emergency physicians throughout Alberta, it was found that the ePCRs were often deemed unhelpful, and at times even detrimental in the task of addressing a patient’s emergency medical condition upon their arrival in the emergency ward.
In one conversation with an emergency physician, the physician recalled a situation where a patient with a medical emergency arrived at the hospital with a completed ePCR. Despite having the ePCR, given the time-sensitive and stressful situation, the collection of unimportant information (e.g., type of mask the paramedic was wearing) quickly rendered the documents useless. The ER doctor instead relied on a quick verbal summary from the EMS personnel. From a preliminary user research, it was found that the ePCR system was constructed for a wide variety of audiences (nurses, legal, physicians, paramedics, etc.) and as a result, the users who really needed the system had difficulties accomplishing their goals with it.
In this particular case, each department involved had different ideas and goals about what should or should not be in the application. By molding the concept of UCD with the client‘s core belief of saving lives, the importance of working with and supporting UCD in order to address those gaps faced by their current users was quickly understood.
In other words, to sell the idea of UCD to a client, we need to understand the client first. By understanding the client, and molding the reason for UX to something they can fully comprehend, it becomes a lot easier to get the full backing, involvement and participation of the client.