6 things that UXers and BAs can learn from each other

With Agile becoming more and more popular, there is a group of people who believe that we should go beyond the multi-disciplinary team to teams with people that are cross-disciplinary: developer, tester, BA and UX in 1.

It is essential for Agile teams to work together and help each other out, but I do not believe in the one-man-band ideal that those people are looking for. In Dutch, a concept like that is called “A sheep with 5 legs”, and I think that visualizes it pretty well.

Malcolm Gladwell, in his book Outliers: The Story of Success, presents convincing evidence that to be really good at anything you need to spend at least 10.000 hours honing that skill, regardless of your talents. That would mean that a dev-tst-ba-uxer would need at least 20 years of work-experience and the youngest possible cross-disciplinary Agile team would have an average age of 40 years.

So just like in the construction industry I think that IT has it’s own carpenters, electricians and plasterers all trained and skilled for their own discipline, but working together to build a house.

However, more recently I’ve come to see that the disciplines of Business Analysis and User Experience are so close that we should compare them with the plasterer and the tiler: practitioners of both disciplines need to have the same foundations and basic skills and can jump in to help each other out in times of need.

That point was brought home to me during the UX Australia conference in Brisbane last week, a great conference with young, energetic people that very clearly all had the same mission: improve themselves and their discipline.

During this conference I came to realise that the UX and BA discipline  are currently too separate: in many organisations BAs and UXers don’t work together but just “hand over their work to each other”, or even worse: compete for the time of the stakeholders.

I think it would be very beneficial for both groups to work closer together, there are definitely clear lessons that both groups can learn from each other.  I will address some of those lessons here:


What Business Analysts can learn from the UX discipline

1.  Really, no really, think from a USER’s perspective

For the BAs, stakeholders are very important, and a stakeholder analysis is part of the toolkit. However, too often we end up facilitating compromises between those stakeholders which might not be the best for the end-user. The UXer is always working to create the best system for the end-user, regardless of what other stakeholders might have to say. BAs should take some of that drive on board.

2.  Prototyping to validate requirements

As BAs we know that requirements are often not clear. We are trained to “pop the why stack”, but even then stakeholders often don’t know what they want until they see it.

UXers assume this from the beginning and they work with models, wireframes and prototypes to test and validate the requirements. Many Agile BAs will already be doing some of this, and some of us even use prototyping/wireframing techniques in requirements gathering workshops, but what we can learn from UX is to make it intrinsic to our work.

3. Innovative ways to find requirements

Quite a few sessions during the conference talked about going out on the street to do surveys: actually questioning potential users. When was the last time you did that as a BA? Let’s face it, we might complain about the fact that there are no real users to do our requirements analysis, but what do we do about that?


What UX professionals can learn from the BA discipline

1.  Ask the Why question

In the opening keynote at UX Australia, Bill DeRouchey, a celebrated US based UX expert, addressed the importance of the “Why” question. No BA in his right mind would open with a topic like that at a BA conference, because that is the very first skill you learn in BA bootcamp. Bill apparently saw a need to address that issue among UXers, which is telling.

2. Requirements capture and management

During some interesting conversations with the other participants of the conference I found out that many struggle with the level of detail on their wireframes. They are confronted with clients who want business rules and screen rules captured in their wireframes, and they are not always sure how to handle that. This comes up especially with UX people that work at digital agencies, where there are often no BAs.

Although there isn’t a clear answer to different levels of requirements, we as BAs are trained to deal with that and have a number of techniques (capturing Use Cases, UML models, process modeling business rules) to deal with it.

3. How to be heard

It is almost amusing to write this one, as BAs have been struggling for years to be properly involved and I’ve been to many a BA conference where there were sessions on how to be heard as a BA. However, due to the growing seniority of the BAs, organisations such as IIBA, better tools and techniques and authors/presenters such as the Robertsons, the BA profession has matured a lot over the last few years.

UXers are still struggling with this, and most of the success stories are “brute force”: an executive hired an UXer and forced the rest of the organization to listen. Although this works on the short term, what happens when that exec leaves again? There are definitely lessons from the BA community that the UX-people can learn.


In Summary

This was a good conference with great people and some interesting lessons. What I’ve taken from this conference is that BAs and UXers need to start working much more closely and start learning lessons from each other.

This is very different from the current situation that I’ve seen in a number of organisations where the two disciplines are often somewhere between serious disagreement and official state of war. If you feel that your organisation is doing it well, leave a comment to describe how UXers and BAs cooperate and make it work!



  • Katrina Sta. Ana

    Some good points there Erik and I totally agree that the two disciplines need to work closely together. It worked really well in my last project, run in 'full Agile', where I was a dedicated UI designer/UX person in the team. Since we were part of the same team, we were able to overcome most challenges i.e. requirements vs design, but more importantly complement each other to meet the business requirements, with user-centered solutions. Now, I understand that not everyone has the luxury of having a dedicated UX person for a project; having a UX discipline in general is great, but with smaller organisations, with limited resources, I see the BA as the next best person able to adopt and learn the skill. Not everyone will agree with this, but I believe that a little UX is better than no UX at all. Anyways a good summary there, and great to see more and more BAs are interested in learning more about this since you highlighted a good point there about the lack of maturity in the UX discipline (as compared to BA). Here in Australia at least.

  • Andrew Blain

    Great post Erik.
    I was working in a design led environment recently in a traditional delivery model. In addition to the things that you described above, we (as BAs) learnt first hand the power of having a gun UI developer as part of the team.
    Jason and Adrian, who worked with us on our project, were able to rapidly build rich and compelling front ends which really engaged business stakeholders and got them to finish content and sign-off from a controls perspective much faster. We were also able to deploy the finished front end code straight into the delivery team.
    The learnings that I'd like to think we provided to the UX team, were: 1. the need to properly model the domain that you're designing for in order to understand constraints that need to be applied in the User Interface; and, 2. the realisation that while the customer is an extremely important stakeholder, there are other stakeholders to consider.
    All in all, I agree wholeheartedly that the best outcomes on customer facing software projects are achieved when both the UX and BA competencies are present.

Leave a Reply

Your email address will not be published. Required fields are marked *