Just a quick follow up to my last post which aimed to gather comments clarifying a couple of points. What are the key functional differences between the BA and Information Architect (IA) roles, and how the split falls between requirements gathering and user centered design (UCD).
I am an avid listener to the Spoolcast podcast from User Interface Enginerring (UIE). It is really informative and Jared Spool always has some great guests discussing UCD and UX topics. One of the recent guests, Todd Zaki Warfel, was talking about prototyping experiences, and during this discussion he touched on the very same role definition issue. Jared at one point posed the question to Todd, does the BA in even look at the user experience? This brought up some interesting points I wanted to share.
Todd felt that the BA’s typical remit on a project was functionality. What functional requirements does the product need to fulfil. So although the BA is involved in the design of prototypes, he saw these as being on the wireframe, boxes and arrows, Visio end of the spectrum. A prototype designed to show that the functional requirements elicited from the users and stakeholders will be met, and visually how those functions will look, in their rawest form.
However an Information Architect or User Interface Designer will approach building the prototype by trying to take it that much closer to the final look and feel of the site will be. Again the functionality will be there, but there would be more care and attention to the usability and user experience with the site. He also felt that the designer would be more willing to take a risk and create something very new, whereas the BA may be more inclined to stick to existing structures. He used the specific example of the designer adding AJAX type aspects to their prototypes.
I certainly think that makes sense and although every BA and IA role will vary from company to company and project to project, I can see this line holding true the majority of times. It does also back up my contention that in fact there is a fine line between the BA role and the UCD process and that the two sides could easily be joined if necessary. This provides excellent room for growth in a BA’s armory if they can bring in valuable usability and user design techniques and perspectives to the requirement’s gathering remit. Particularly when expressing those requirements visually, which always seems to be the best way to really engage the stakeholders in the requirement’s process as they start to see the result to all the questioning.