The business analysis part of UX
BA or UX? BA vs. UX (if we believe some project management and job-title oriented blogs)? Where does business analysis [...]
I have recently worked as a UX specialist on a project in a very difficult and fascinating context. The project itself was an internal financial application, and looked quite simple at a first glance. What made it so particular was its history. The new project was launched after one full year of development and without any consultation of users of the existing system. As a result, users from offices all around the world rejected the new tool, sometimes without even trying to use it. Challenging experience. In this case, as often, UX was far from just wireframing pretty widgets. It was a profound redesign of the system, and a deep rework on the relationship around the project. Creating a positive communication with users, making focused changes to the interface and testing them became the strongest vector of change management and acceptance of the new system.
The importance of conducting user research is often underestimated by business and project management. Leaders like to assume they know better than the users they are responsible for. Even if that was true (which I have never seen), people hate it when others decide for them. Everyone likes to be asked their opinion. Sending a UX (or a business analyst) to observe users, gather feedbacks, needs and expectations not only builds a strong knowledge basis for the project, but also acts as a communication operation. Users feel their opinion is valued and taken into consideration, and are more likely to understand the project and have a positive attitude towards it in the end.
When initiating an elicitation protocol with a few users, you are actually creating as many interest centers about your project. It is most of the times a new and interesting experience for them, and they will talk about it. To their coworkers, managers, at lunch, during meetings, etc. The consulted users will be the best ambassadors for your initiative and the project itself. The temptation can be important to focus on users who the management knows will have a positive a-priori, but this moment in the project lifetime should on the contrary allow to talk to a wide range of users, in terms of needs, tasks, IT knowledge, resistance to change, etc. It can even help defuse tensions before they happen.
Project knowledge propagation from user interviews
Asking their opinion to an important number of users and/or stakeholders does not mean following each one of them. Conducting a user research phase is crucial to gathering as much insight as possible, allowing to take the right decision, based on the right information. There is still a strong need for a project management able to make difficult decisions, prioritize requirements, and sometimes delay or abandon some features. What matters is to communicate to users what the system will do and not do, for the moment or later, and the reasons why. Based on clear and complete data, these decisions are more likely to be understood and accepted.
Once trust is lost, it can be very hard to earn it back. It applies for projects too. In the case of this project I was talking about earlier, improving the system itself was not sufficient. Even if in the end it answered perfectly every need and expectations, it would still have been boycotted. Why? Because sometimes what you do does not matter as much as how it looks. The IT side of the project is not visible to users. They won’t be able to see the improvements for themselves, and will have trouble believing if the trust has been lost before. Changing the project team, a few colors and improving the design can seem futile but will actually shift the overall attitude around the project to a new paradigm.
Asking users and stakeholders for their opinion is great, but it is only a start. If you want all of the above benefits to actually happen and last over time, cherish the new trust relationship you have worked hard to establish. Send regular emails about the project, organize monthly open demos, propose a beta version for download to interested users… And even once the project is out there, living its own life, regularly ask for feedbacks and work on improvements.