IAs vs BAs – the IKEA model

Recently, there was some discussion on SIGIA-L about differentiating BAs (business analysts) and IAs (information architects).

In his original email titled “BAs vs. IAs”, Juan wrote:

“I am finding it difficult to differentiate and specially, to separate the activities between an IA and a … BA … Where do we draw the line? I find that because BAs look more into the business side of things …their opinions weight more than from an IA. As IAs, do you find yourself doing BAs work?

“I need some help clarifying the differences between both roles”

I pointed Juan to a post I wrote about 6 months ago on this very topic and everyone on the list seemed happy. But the question came back to haunt me in the last few days as I wrote out tasks, activities, and services that my organisation’s IAs perform against Jesse James Garrett’s industry best-practice IA user-experience methodology to help clients understand what IAs do.

Analysis is an important part of any project, whether systems oriented or otherwise. Garett’s methodology highlights the importance of investigating, analysing, and aligning users’ needs with those of the business (what the business wants out of the project) and how the project itself aligns with organisational drivers. Analysis is what starts the project. Traditionally, this is where BAs do their thing – analysis.

What ever the project, though, someone needs to be talking to the business to ensure needs and outcomes are aligned with expectations, someone needs to design the solution, and then someone needs to implement it. In the middle somewhere is where activities converge and I think where some of the confusion lies.

In the furniture industry, IKEA employs analysts like Mette Old Hussmann to invesigate and analyse market trends and ask people about their needs for furniture. Then, an industrial designer like Hella Jongerius examines the analysis and thinks on issues around how people will use the chair, its ergonomics, and its aesthetics including form, colour, and texture – the whole user experience. Then, once a prototype is built, an engineer works out how to actually build the chair and then builds it.

IAs are like those cool Scandinavian industrial designers at IKEA. They take the analysis — information requirements, user’s wants and needs, business requirements, processes, strategic goals and organisational drivers — and design how people will interact with information. The result can be as simple as a systems interface or as complex as a business taxonomy for classifying corporate knowledge. Core to their array of skills is expertise in:

• accessibility
• usability
• interaction design
• information design

Most importantly, an IA has an understanding of how these things apply to the unique problems of the users’ environment (e.g. the problems of accessiblity for the web for which the Web Accessibility Initiative (WAI) was created), and how to transfer the underlying philosophies and principles into workable, usable designs.

This is not to say, though, that BAs can’t design. Expert BAs, like Maria Murphy, continue to call for BAs to do more than just analysis for requirements gathering and act more strategically. As she points out, many BAs in the IT world even do prototyping and user-engagement to determine how systems should work. In my experience, however, this is a rather rare site indeed. IAs also often do analysis as well as the design and even the building. And there are even a few IT programmers who can do all these things – the analysis, design and the implementation. But are we asking people to do too much? Is this sort of cross-over confusing people?

In my experience, you’ll get the best out of a project if you leave your analysis to the experienced BA and your design to your expert IA. This way, you’ll get the IKEA chair you’re after, rather than the “No Name” stool from ALDI.

M