How to make UX and business analysis (BA) work together
Until recently, I’d never worked with a business analyst (BA) as part of a delivery team. I’d grown up in an agency world, where a brief would appear, the product was already scoped (to an extent) and the need for user experience research (UX) was implicit in the brief.
In my last few contracting roles, when I arrived in the agile teams, there were BAs already in place, along with solutions architects, product owners, service managers and tech leads, etc. It took some time to understand what each person actually did, because even though each time I joined a new team the job roles were roughly called the same thing, the actual role that each person did was often slightly different, depending on that person’s interpretation of it, as well as what needed doing in the team.
For example, in the first team I worked in there had been a lack of a UX researcher for a while, and there was a need for formative research to understand user needs. BAs were already in place, so they’d taken it upon themselves to gather the information about the current processes. This was all cool. I picked things up when I arrived in the team, but it left me confused about the difference between BAs and UX, especially in the formative period of developing a new product.
When I searched online to try and get some definition of a BA’s role, and how to distinguish it from UX, I didn’t find very much. But over the next 18 months I noticed ways in which there are clear distinctions, and so I thought I’d share them here.
Nothing is set in stone
First off, a disclaimer: there are no clear role distinctions set it stone; different people interpret the roles differently. But these are my impressions, from the people I’ve worked with.
The role of a BA seems to be flexible. However, generally, there are themes of behaviours that form core activities, such as:
- Gathering business requirements for a service
- That is, understanding what the company that is making the service or product need it to do in order for it to be a success.
- Talking to services that input into the product to help define their requirements too.
2. Liaising between the developers and the PO
3. Acting like proxy product owners (PO)
I’ve also had people suggest that BAs focus on quantitative data, but I would disagree, and say that’s just as pertinent to a service designer. It depends what the quantitative data is measuring.
Unique BA roles as I understand them
The BAs I’ve worked with have all been great at gathering requirements for a service, to help define what the business needs it to be (point 1, above). For example, what is going to make this product stand out in the market; what market intelligence does the business need it to produce to add value to it.
They’ve also been good at point 2: being the bridge between product owners, developers and tech leads to define what is in scope for MVP, iteration 1, etc.
And they’re always willing to step in and take that role in number three, although I suspect that might not be a true BA role, and is more a sort of ‘gap filling’ when time and resources are tight.
However, these three areas are also areas that a UX or service designer could (and possibly should) want to be across too. For me, the main area of overlap between UX and BA is the first one: gathering business/user requirements. This is also the one where I had an example of the different perspective BAs have, compared to UXers.
When BA thought it was UX, but actually was BA
When I joined a team that hadn’t had a UXer for a while, and the BAs had filled in to gather the initial product and service requirements, they’d reported back to the team that they also had the user requirements for the service from their research too.
The product vision was born. The service was outlined. A UX designer was brought in, and they started to prototype up the screens based on the flowcharts from the BAs. All seemed good and progress was swift.
However, it became clear after I joined that the requirements were not user focussed. Instead, they focused on an object as it worked its way through the system.
We were making a system to process financial transactions. It was to be a new service, to replace an existing, paper-heavy, laborious process. The initial research had been done with the original, laborious system. Yet, rather than focus on the actions and requirements that the workers had to perform in order to process the transactions, the BA research was fundamentally based around flow charts, showing how a transaction moved from state to state as it passed through it.
For this reason the transaction was then seen by the product team as the sort of ‘fundamental unit’ of the system, and the low-level design was created based on this premise. This caused a fundamental issue as the service developed.
In addition, there were no current pain points documented. The current process was long-winded and tedious, and was ripe with errors of copying and pasting information from one system to another, or losing slips of paper. None of this made it into the ‘As-is’ journey, so that it could be ironed out of the ‘To-be’.
So what?
When I joined the team as a UX researcher, and spent my first few visits observing the processes that had “already been documented”. It was clear that the emphasis was on the object and not on the user. One specific issue reared its head, which caused the system to need redevelopment:
The system was built around the transaction, specifically a payment, and in the ‘back-end’ of the system the payment was the fundamental unit. To that unit were attached other features, like a reference number, a status, and various other attributes.
However, occasionally, the payer would be able to get a rebate on their payment, if they were on low-income. In this instance if they had a full rebate, and didn’t have to pay anything then that payment would be wiped out, so the fundamental unit of the system (the payment) on which other attributes were hung, would cease to exist. If that happened, we argued, on what would all those attributes hang? The tech lead insisted users didn’t see rebates as a payment, but we provided evidence that users considered it as just that.
UX had noticed since the first contextual visit that the fundamental unit was the item that the person was paying for, and this was what the workers referenced as they worked. If the UX had been in from the start, with the view from the user’s perspective, this would have been avoided.
I don’t want to say UX is doing anything better than BA. This is simply an example of where business analysis took one perspective (on an object), but UX took another (on the user).
Conclusions
This example helped me to understand that BA and UX are not the same thing, but are complimentary: two sides of the same coin.
Both of these elements need to be in the mix when creating a product, especially a new product. BA and UX need to work closely together; brought together into a formal service design vision, and by informally plotting the requirements of back-end and front-end systems together daily. Recognising these differences helps.
It seems like a simple Venn diagram:
- UX brings the user needs; the observations of current pain points for users.
- BA’s bring the business requirements that the end product needs to meet.
- All work together (always, but specifically in design sprints)
In practice, there’s always going to be muddiness between the two roles, but knowing them better, and what they do, will make for better products.
Originally published at http://benweedonresearch.com on November 21, 2019.
