The best services are intuitive and easy to use. And so, when designing services, it's important to keep the service user firmly in mind and gain an understanding of what they would find valuable and useful. After all, if a service is delivered which users perceive as being hard to use or not valuable, chances are they will find a way of avoiding it! This can lead to a lot of work done (and money spent) for no real benefit.

The only reliable way of finding out what customers want and need is to ask them. This can be a challenge when there are thousands (or millions) of them. Imagine designing a government website — this will be used by a diverse range of users, and it's clearly not practical to interview everyone in the country.

User Research

User research can be extremely helpful in these situations, and some organisations have user experience (UX) or user research professionals dedicated to this task.

Their approaches vary but are likely to include semi-structured interviews with a range of different user types, surveys, focus groups, observation and possibly even prototyping and A/B testing. The qualitative and quantitative research they carry out will often be distilled into a set of personas against which key design decisions can be tested.

However, it's clear that some elements of the user researcher's role overlap with business analysis. Fundamentally, user researchers elicit and analyse the needs and wants of users (and possibly other stakeholders too), which is also a core part of what a BA would do. Without collaboration, there is a danger that silos could emerge, with the BA and user researcher working independently. This could lead to duplicated effort, conflicts and contradiction. A "turf war" could emerge!

Avoiding Silos

By recognising the benefit each role brings a siloed turf war can be avoided. User researchers often have the time, remit and budget to conduct extremely detailed qualitative and quantitative investigations that BAs typically don't. Yet user researchers might not always be aware of the broader organisational context.

When it comes to the needs and wants of users, not everything that is deemed as desirable will actually be feasible. Imagine a user saying "I'd love to have a 24 hour live chat function on the website so I can get answers quickly". This is easy to express as a user request, it's easy to draw on a prototype and it might even be relatively easy to technically implement. Yet there would be a whole range of business impacts.Questions a BA would likely ask include:

• Who will be attending to/answering the live chat?
• Are there additional staff costs and, if so, are these accounted for in the business case?
• Is this in line with the overall scope/desired outcomes of the initiative?
• What about security and other non-functional areas? Are there any cybersecurity concerns?
• Are there any ethical concerns? If we move our service to be predominantly digital, does this disproportionately disadvantage any groups?
• Is the business willing and able to support live chat?
• What transition, training and communication planning would be necessary?
• … etc.

User research and business analysis are two different, yet complementary disciplines. There really does not need to be a turf war: user researchers can bring deep knowledge of real users, often to a level it would be hard for a BA to obtain within the constraints of a project. Whereas a BA can bring the wider business and organisational context, as well as ensuring that the wider goals and objectives are kept clearly in view. There will be grey areas in the middle too, where responsibilities overlap, but the key is to work together.

Negotiate Ways of Working

To avoid conflict and contradiction, it's key to negotiate ways of working together. Done well, this can be helpful for both parties. The BA can provide useful contextual information, which helps the user researcher prepare. The user researcher will provide valuable insight which can be analysed and fed directly into the requirement analysis work.

These ways of working will vary significantly between context but might involve the BA and the user researcher 'shadowing' each other when key tasks are being undertaken. If a focus group is run, a BA may attend to hear views first hand. If a BA is running a workshop with a range of other stakeholders, the user researcher might attend so they are aware of any issues and requirements that emerge. Open communication is key.

As with so many roles, there will be areas of overlap. With open communication and planning it is possible to lighten the load for both roles while also ensuring a better outcome is achieved. The key is to open those communications channels early!

Looking to update your BA toolkit? Check out AssistKD's wide choice of business analysis courses.