BA or UX? BA vs. UX (if we believe some project management and job-title oriented blogs)? Where does business analysis stop, and where does user experience start? As a UX specialist in Geneva, Switzerland, I have worked both on projects involving business analysts, and on projects for which they were not part of the team. Whether we need BAs and/or UXs is not a question anymore, and having BA insights is a great advantage for starting the UX part of a project. Instead, I wish to focus this article on the similarities that exist between the two roles, and on this business analysis part of UX that we, as usability consultants, often, and more and more, integrate as a part of our mission.

Elicitation

The IIBA’s (International Institute of Business Analysis) Babok (Business Analysis Body of Knowledge) describes 6 Knowledge Areas for the Business Analysts, guiding their tasks from the beginning to the end of a project. Elicitation is one of the most crucial of them, as it is the moment when Business Analysts gather stakeholders needs, concerns and expectations, which will later lead to requirements. If Business Anlysis focuses strongly on stakeholders, User Experience deploys a lot of efforts and various techniques to gather insights, not only from stakeholders, but mainly from users. For UX specialists, this phase also includes study of the competition.

The techniques are mostly the same, with benchmarks, user observations and interviews, focus groups, brainstormings, etc. I would say the main difference between elicitation by a UX and elicitation by a BA is the strong focus we keep on users, and the amount of efforts we invest in this phase.

Requirements

Once needs are understood, both Business Analysts and User Experience consultants express them as requirements. Whereas for BAs they are often described in Word documents, UX designers prefer to use zonings or wireframes to visually represent requirements in an interactive prototype. This allows to gather several feedbacks iterations from business, users and stakeholders.

Once the wireframes lead to a consensus among the stakeholders, the UX describes the functional requirements deeper, as a brief to the programming and design teams. It includes all behaviors and main concepts, but it stops before any technical instruction: in an ideal world, the usability requirements are neutral regarding technology, whereas BA goes further into solution selection and implementation. That’s why Business Analysts are sometimes specialized in SAP (for example), or other solutions.

Solution validation

Gathering feedbacks using different iterations of wireframes allows UX specialists to validate the solution as the project goes forward. Once implemented, we use several techniques, including user testings (which can be organized at several steps during the conception phase), heuristic evaluations as well as Analytics analysis, after a few months of deployment. UX can then focus on continuous optimization, based on quick-fix improvements with a potential strong influence on conversions relevant to business objectives.

There are many similarities between the Business Analysits and the User Experience specialists scopes of work, main differences being the focus (users vs. stakeholders and project variables) and the form of the deliverables (wireframes vs. requirements.) Having experienced it many times, I would say pairing a team of BAs and UXs is recommended especially for big projects, with a lot of constraints (including technical, financial, political, etc.) For smaller projects, the UX approach to Business Analysis is most agile and flexible.

Because I believe having the right intel is the basis to any good decision, I include at least a few hours of Business Analysis even in the smallest projects I work on. This often ensures all stakeholders are on the same page, and constitutes a knowledge reference guiding the whole project life.