Working with business analysts

On Wednesday, October, 1st, 2014 in Featured

Meeting designed by Sergi Dalgado from the Noun Project

Last week I was talking to a BA and we were discussing the relationship between a BA and a UX professional. One of the interesting things he said to me was that good BA’s need to know their limits. Likewise UX professionals also need to know their limits too.

I say this having experienced working with a nightmare and a dream BA in the same company. So, in this article I will talk about how BAs and UXers can avoid conflicts.

A lot of this is based upon my previous experience with a particular BA who I did not have the best working relationship with. I want to make it clear that this is not a personal attack on anyone and that my main purpose for writing this article is so that you can avoid experiencing the same issues I did.

BAs should not design

I worked with a BA who insisted upon creating mockups in Balsamiq. The BA in question would take these to the product owner, and other senior stakeholders and would pretty much agree the user interface design. As a UXer I would then be expected to produce cleaner wireframes of what had been agreed.

NO WAY hoozay!


I would actually take the agreed interaction design, and I would rip it apart. For me it was a simple task because the mockups would contain so many usability flaws I could make several corrections and quick win improvements.

However, in doing so the following would happen :

  • I appeared to be a blocker on the project
  • The BA would become highly defensive because I had ripped apart their thinking and design process and would become highly defensive.

In the end, I had to get buy in from the project manager to stop the BA from agreeing any interaction design without my consent.

BAs must prioritise requirements

The same BA was really bad about considering and gathering requirements. To be honest I had never seen anything so bad before.

In my opinion the BA was going to stakeholders and asking them what they wanted and was repeated these requirements back to. This is of course very dangerous, instead a BA needs to :

  • Understand what is needed, and not what is wanted
  • What are the user stories


List designed by Scott Eshbaugh from the Noun Project

For instance, a registration form may need to have some kind of validation to inform a user if they have made an error. To be honest, thats all a UXer needs to then provide a solution from an array of potential design patterns. It is not for the BA to influence the decision making process of the design pattern.

BAs and UXers must not back stab each other

So from reading this so far, you can maybe understand that I was not having the best of relationships with a certain BA. I was getting throughly fed up with them, and the lack of good user and business requirements that were coming my way.


Steal designed by Ricardo Augusto Cherem from the Noun Project

On some occasions I was tempted to start collecting my own user requirements, through “under cover” meetings or the occasional “hi jacking” of a meeting with a BA. This of course was not perhaps the best of working relationship, and it was something that I had to control.

Conversely I knew that the BA was making amendments to my wireframes and prototypes with the company’s digital designer and front end developers when they had been signed off.

BAs must allow thinking time

The same BA called me into a meeting room because they wanted suggestions regarding a particular UX problem. Alas they stated that the solution I was suggesting was too complex to implement despite it proving the most usable solution.

The BA asked me for another solution, I stated that “I needed sometime to consider the issue.”


Brainstorm, Brain and Question designed by SuperAtic LABS from the Noun Project

However the BA didn’t like this response and so wanted me to provide a solution there and then. I could only advise that they did nothing, or that they go for my initial suggestion. Not liking how the meeting was progressing the BA stormed out of the room.

The thing is it could have been avoid if the BA was prepared to allow some thinking time around the solution, because they didn’t a highly tense and pressured situation arose.

We both need to ask Why

So as a UXer Im always asking ‘why?” to nearly everything that I do. Asking why means that I can :

  • Understand issues
  • Backup decisions and one’s thought process
  • Champion end users when others don’t

So BAs need to do exactly the same, and in most cases they will want to achieve the best experience possible for a user.

How to avoid what I experienced

I’ve worked with a lot of BAs now. In the most part they start off needing to represent the needs of their business. However when they meet a UX professional they need to understand that someone else will be thinking and championing the voice of the user or the customer.

To avoid this situation again I would :

  • Question the roles and responsibilities of people on a project
  • Determine if a project really wants to work with a UX professional

A lot of my experience came down to the fact that UX is perceived to be exciting and creative, thus people want to do it. However to a UX professional its more about bringing together previous experience and one’s thought process.

You get to have the first comment !

Add a comment

Your email address will not be published