The blurred line between BA and UX
In almost every project, tensions, conflicts and disagreements between Business Analysts and User Experience Engineers never end. But the above roles have much similar work than they may appear at first glance. Overlapping and distinct responsibilities of BAs and UXers might make them rethink where their specialized skills will be most useful and applied. While business requirements are getting more complex and ‘human-centered’ than ever, each role holds important responsibilities over where a project is headed.
The Business Analyst
Starting with understanding the project domain and users, the business analyst goes on with a complicated list of gathering, defining and refining user requirements, generalizing or concatenating as necessary, defining user interface layouts, yes, you heard right, and so on. The ultimate goal of business analysts within the project is delivering the product that meets the needs of business and users, within the time and budget limitations. To achieve this, apart from the above-mentioned, the BA should work on a number of procedures, including, but not limited to, formulating business analysis plans, supporting technical implementation, helping the business implement the solution and assessing the value created by the solution.
The UX Engineer
Meanwhile, UXers are supposed to create and enhance how users interact with the product, making it more “user-centered”. Their responsibilities include creating user and content flow, user stories, interactions, designing wireframes, prototypes and working on visual aesthetics. They are also responsible for helping create a content strategy, deciding on information display and user testing. Yeah, not as simple as it may appear! Although in most projects, the UX engineer’s role is supposed to end in an early phase of product development life cycle (PDLC), it is quite important to get UX involvement in each and every stage of it. This is because his/her responsibilities are to cover a wide range of areas of the PDLC, such as designing, development and testing as well.
These responsibilities & job duties of both BA & UX roles will of course vary depending on the project these roles are involved in, the organizational culture and additional/custom job descriptions required for specific purposes.
Business vector created by pikisuperstar – http://www.freepik.com
One destination, different paths
Although both of the above roles work towards the one goal of the entire team – success of the project, they may choose different paths to achieve it. For example, business analysis focuses on ‘Business’ aspects while the user experience engineering focuses on ‘User’, just as the names suggest. Empathy is generally found with both the roles, although they empathise with different objectives – again the ‘Business’ and the ‘User’. Communication is another vital aspect where the business analysts and user experience engineers differentiate themselves. BAs tend to come up with writing down business requirements and preparing them into comprehensive documents while the UX engineers are strong in preparing visual documents such as wireframes, mock-ups and user flows to communicate.
The importance of clarity in roles and expectations
Both of these roles are quite important for product development. Having a project manager do the business analysis or the front-end developer work on the user experience designing never gets the work done perfectly. Every important phase of PDLC, such as planning the roadmap, breaking down requirements, effort estimations and working on the deliverables, requires the service of these two roles more or less. If affordable, getting these project roles on board, with clearly defined responsibilities and job descriptions may add more value to your project than anticipated as well.
Although the defined roles might say otherwise, very often, the responsibilities of BA and UX overlap. For example, building the information architecture must be a collaborative effort of both BA and UX. Likewise, there are several responsibilities such as identifying user stories, user interviews and testing, and documentation that should be handled by both the roles aligning with each other’s objectives and responsibilities. There must always be a mutual agreement between the business analyst and the user experience engineer, on whether they are on the same page at all times.
Does an all-in-one (UX + BA) resource make sense?
This overlapping of UX and BA roles has come a long way that even having a BA with a bit of UX skills and a UXer with some logical and analytical skills, is nothing but a real advantage for the project. Complementing each role with a portion of the other never goes wrong, rather it helps conceive a feasible and attractive product. Moving forward, there might even be job requirements for this sophisticated skill set of both BA and UX.
An important message to UXers and BAs
Despite all the similarities and differences, what both parties should have a concern on is how to do each role effectively and efficiently, so it’s a win-win for everyone. Both roles must have an understanding of clearly defined responsibilities, and importantly the boundaries of each role. There’s no good of a UXer who tries to involve in business analysis without specific domain knowledge and similarly, a BA who tries to outshine a UXer without valid UX knowledge is doing no good either. On the other hand, the chain of command is important where each role understands how to arrive at a final decision without sparks flying. The collaboration between the BA and UX definitely reduces rework, and produces clear and well-defined instructions and roadmap for developers.
Ian Worley, Head of Product Design & User Experience at Marshall Wace, states;
“Clients do not buy UX people and BA people, they buy solutions. Work together to make that happen. We should be focusing on how we can organise our resources and skills, rather than our professional labels.”
In the end, saving the day actually depends on business analysts and user experience engineers getting along and making people “need” things they produce.