A blog post from the Userist (June 23rd 2011“Smuggling UX at the UK IIBA” by Tim Caynes ) highlighted a very interesting discussion that took place this week at the event “Usability & The Business Analyst” organized by the UK IIBA chapter.
The focus of the discussion was, as Tim Caynes put it, to examine “how does user-centred design affect the business analyst?” Tim also summarized the value of this exchange as it showed that “there are clearly opportunities to embed used-centred methods into the business analyst skills and competencies framework and satisfy goals for business benefits and enhanced user experience.
I just wanted to add my two cents on this issue, which has come up more than once also in Miami, when I exchange ideas with the buoyant design community in South Florida.
So how do User Experience and Business Analysis relate?
As a CBAP® I should say that User Experience is (very thorough) solution building that ensures usability, which is one of several quality-of-service requirements a solution must address. Yes, one of many, just like other nonfunctional requirements such as performance and capacity are addressed by Database Architects.
Let’s follow this analogy: The Business Analyst would identify the business needs and structure requirements on performance and capacity for a system. The Database Architect would come back from the drawing room, let's say, with a “sharding” blueprint. The Business Analyst would validate this blueprint if the solution satisfies the performance and capacity requirements. The Business Analyst is completely neutral on the use of “sharding” as opposed to “replication” and he is also completely neutral on whether MySQL or SQL is used. The analyst’s only focus is to make sure that the solution meets system performance and capacity, as elicited from stakeholders.
The value of UX is similarly important: A business analyst identifies the usability requirements for an interface. The UX practitioner offers a design solution that addresses those requirements, and the Business Analyst validates the solution proposed by UX.
So far, this sounds very straightforward; however, we have to acknowledge that in certain contexts the roles of “Business Analyst” and “UX Practitioner” are not fulfilled by different people, and here is where I see some grounds for confusion.
Whenever external UX practitioners (web design companies or software development consultancies) perform a “Site Audit” to evaluate usability of an interface; they are assessing a solution, which is plain old Business Analysis, or as BABOK puts it: “Solution Assessment/Validation”. Whenever UX practitioners use “Persona” to act out scenarios, user stories, wireframes, prototypes, etc. to understand user needs; they are eliciting requirements, which is again Business Analysis.
And this two-hat play can go the other way too: In our consultancy (which we promote as a Business Analysis Consultancy) we use graphic mockups and prototypes not just to elicit requirements from users but sometimes to deliver the blueprint for a solution as well. At that point we acknowledge in our practice that we are not being Business Analysts anymore: we are in the realm of UX or software design.
I think that much of the confusion or apparent “conflict” or “graceful collision” between Business Analysis and UX is the result of same individuals playing different roles. There is nothing wrong with that: From our own experience, in many cases if we present our clients with a neat requirements package that stops short of interface design, our clients would say: Beautiful to know our needs, but we ALSO need to visualize the solution before we buy it. At that point, do we run out looking to hire a UX practitioner? Well, if this is a small project, no, because it is logical that the UX analysis would come bundled with the contracted solution; however, the client still would like to see a basic prototype before prospecting vendors, and so we, Business Analysts until that point, have to exchange hats and get on the —“oops”-- UX turf, if at a very basic level.
Of course my point is: there is nothing wrong with exchanging hats and playing the roles of UX practitioner and business analyst concurrently. The whole OTC software industry is based on vendors also doing the Bussiness Analysis for their clients (…“discovery” they call it)
I am just saying that understanding the roles in the SDLC would make people involved (and I am talking people, not roles) better at focusing on what they need to get at each stage of the project.
And there is also all this toolkit sharing: Whenever you use a mockup to elicit requirements, you are being a de facto business analyst and your focus is on needs; whenever you use that very tool to design a solution, you are being a UX practitioner, and your focus is on building a solution.
If we can share the toolkit, so be it!
On a side note:
One of the distinctions that are thrown around is that Business Analysis centers in requirements to satisfy the bottom line (it is business-centered) whereas UX is user-centered. I think that for all practical purposes, any system built for business success needs to be user-centered and should satisfy the user: otherwise there is business failure.
By Larry Velarde, CBAP®