Business Analyst and UX Designer. Spot the difference.

Have you noticed that the roles of Business Analyst (BA) and User Experience (UX) Designer are often confused with each other, or conflated into the same role?

As a UX designer, I have often encountered this in practice. For example: a BA has determined the functional requirements prior to my involvement with the project, or in other cases, they have gone ahead and produced the wireframes. More about this later.

Why does this happen?

It’s easy to see why the confusion occurs.

At first glance there are noticeable similarities – both Business Analysts and UX Designers are concerned with gathering product requirements, defining product solutions, and influencing product strategy.

The reason why Business Analysts are sometimes expected to take on User Experience functions, is that when resources are allocated it might seem wasteful to have two people gathering requirements, when one person could do the job just as well.

And after all, user requirements are just a subset of the business requirements, are they not? Save your answer for later ;)

Opposing interests.

While the similarities are readily apparent, the differences between the roles are less obvious. Let's have a closer look at what each specialist does.

The Business Analyst, as the job title suggests, is focused on the business. They’re concerned with business requirements, and they are drawing on their business training and business knowledge to provide solutions for business problems. Typically, their main deliverables are drafting requirements documents and establishing business rules.

The User Experience Designer also needs to consider the business requirements, but is focussed on the user. They’re seeking to understand user requirements and are drawing on their human centred design knowledge and design thinking experience to design solutions for user problems. Their typical deliverables include user insights and visualisations of solutions through prototypes.

We acknowledged their similarities earlier, but as we now can see, the two roles actually have quite different agendas and competing priorities. The Business Analyst is biased towards the business’ needs while the User Experience Designer leans towards the users’ needs.

Using the right tool for the job.

We all tend to understand that there are important business challenges to solve before products can become viable, scalable and successful. But at the same time, it’s essential to acknowledge that products are created for humans, to make their lives easier in some useful way. Product success is therefore dependent on solving compelling customer problems so elegantly that our audience has no choice but to choose our product over the competition.

Remember the truism “If all you have is a hammer, every problem looks like a nail”? In my experience there is a nuanced, yet profound conflict of interest that occurs when Business Analysts are tasked to solve user experience problems. This is because the BA’s empathy lies with the Business, as it must. Even amongst BAs with a good grasp of UX concepts, sooner or later their loyalties will prevent them from seeing the user’s perspective and from advocating for user needs to the same extent as the User Experience Designer will.

The perfect marriage?

This is not to say that Business Analysts and UX Designers can’t work well together – in fact they can make formidable teams.

Let’s look at one of the examples that I’ve personally experienced:

I was at a client’s office expecting to be briefed on the design and integration of a new feature into a SAAS application. Meeting with the CTO and the brand new BA, I was updated on the various requirements, and together we sketched up an ideal user journey.

Everything was going well until they let me know that there was no need for me to design the wireframes, as they had already been created by the BA.

We don’t typically work this way with this client, and I was taken aback at first. But rather than react defensively, I wanted to be able to respond from a position of understanding and empathy.

A combination of the following dynamics was happening:

1. The BA was new to the client’s team, and they were simply doing what they believed they should be, which was to define the requirements.
2. They may not have had much prior experience in working with UX designers, and didn’t know that designing wireframes is an activity that I would be doing.
3. The BA was afraid of losing control of the project to an external consultant, especially one they yet didn’t have a relationship with.

I wanted to bring them on board, so that I could continue to deliver an appropriate outcome for the client. In order for that to happen I needed to:

1. Show that I understood that they were operating out of good faith.
   I thanked them for taking the effort to draft wireframes, asked them to walk me through them and made sure to acknowledge the insights they had brought.
2. Establish my credentials, and win their trust.
   I tactfully pointed out where I saw gaps in the user experience, and how we could improve the solution.
3. Demonstrate that we could work together.
   We agreed that I would refine the wireframes, and that we would review them together before involving the wider team.

This proved to be the first of several projects we successfully worked on together. The BA became a key stakeholder who translated the business requirements for me, brought their valuable insights into play, and most importantly, they learned to trust me to direct the user experience.

In conclusion

There is a common misconception in various corporate circles that Business Analysts and User Experience Designers have interchangeable roles, and therefore if there is already a BA on the team, there is no compelling reason to also bring in a UX Designer.

It is far more beneficial for product teams to recognise that these two specialists have different agendas. In fact their points-of-view, skills and experience, are strongly complimentary. I have discovered that through collaboration, we’re able to leverage each other’s strengths, and limit each other’s blind spots to ensure the products we’re working on are equally sound from both business and the user experience perspectives.