We’ve all had the experience of being unable to find something we are looking for on a website. Perhaps you have used an app that won’t let you make a purchase but also doesn’t tell you why, or allow you to correct some imperceptible mistake. You may have inadvertently ordered a distressingly odd combination of food as the website’s description of it was difficult to read, or the information was incoherent. Or you’ve been given a huge list of options to choose from, none of which actually apply to you, but you must select one to proceed.
If any of this sounds familiar, or if you have ever been frustrated using any digital interface, chances are that the development team didn’t include a “User Researcher”. One of the purposes of a user researcher (also known as a “user experience researcher”) is to identify failures like those listed above, before they ever reach the light of day and cause those frustrating experiences we are all increasingly familiar with. But user research is also more than that. For people who are building digital services, how do they know what it needs to do? What problems is the service solving? And the key question: who is going to be using it?
User research allows us to answer these questions, so we can make sure we’re designing the right thing, the right way, for the right people. It also allows us to test these designs or functions, with the people who will actually use it. After all, development teams go through rigorous acceptance, system, integration, functional, load testing, QA testing… amongst numerous other forms of technical testing to ensure a system works. Testing the back end is clearly important when creating digital services, so why should testing the front end be less so?
Much of the resistance to user research comes from a misunderstanding about where a user researcher “sits” in the development process. Too often, a user researcher is brought in at the final stages – almost as if to “sign off” on work that has already been completed. It’s hardly surprising then at this late stage that there may be little appetite, time or budget to make any meaningful changes based on the insights gained from doing user research, or desire to undo or rework complicated elements of a product or service. This can often lead to another common misconception: that user research is too expensive.
If user research is implemented at the end of the development process and extensive changes must be made to a mostly built system, this rework is naturally more expensive due to the time needed to make these changes. But what is really expensive is having a system, service or site that doesn’t work efficiently, that isn’t used or is even actively avoided. The whole purpose of creating that system is negated. For example, if a user becomes annoyed that they cannot work out how to make a purchase on a website, they will simply go elsewhere and that sale is lost. The back end may be a fantastic feat of engineering but if the front end doesn’t match it in quality, people will only ever remember the experience of using it as a negative one.
Issues such as these are easily overcome by having a user researcher embedded in a project throughout its lifecycle. Challenges with designs can be identified – and rectified – in the early stages, before they become real problems. Involving end users in the process and gaining a thorough understanding of their motivations, behaviours and needs means that services can be efficient, effective, and satisfactory. In many cases, improving the user experience is good for the business (whether it is in the public or private sector) by reducing operational costs, streamlining processes, and keeping staff and/or customers happier.
This is where Mobilise Cloud really excels. We have the most knowledgeable and innovative engineers, first-rate Business intelligence teams, and now an expanding user research, user interface and service design capability. Mobilise create those fantastic feats of back end engineering, and having a front end to match testifies to the quality of that work. We shouldn’t ever lose sight of the fact that real people use these websites, tools, interfaces, or services, so let’s make sure that we are designing, creating, and building with them in mind from the start.
Image Credit: Jason Bell (User Researcher)
