Messages

Alright. I'll throw in my hat...or, towel...or, something...

BA's. You know I love'em.

Here's how I see it:

1) BA's collect business requirements. Now, the tough part is that stakeholders speak "solutions" or "designs" when they're asked for business requirements. So, good BA's are awesome at collecting these requirements, hearing the solution-speak, and showing stakeholders the difference between the two. If you've got rad BA's on the team, they'll be able to manage these requirements gathering sessions, and create a common language of requirements.

2) Once you've got the requirements in front of you, you've got to design a solution that meets the business requirements. BA's are really good at working together with IA's in designing these solutions (along with good technology folks, as well, of course). They can bring the business flows from requirements gathering sessions and identify the changes that the organization may need to make in light of a new solution - also, creating new flows and use cases helps customers understand the new solution. BA's rock at doing those.

3) Now - this means that BA's and IA's need to work together to show the stakeholders the new potential solution or concept...even before we've created a new solution map, site map, flows, or complete set of wireframes. BA's and IA's should work together to provide potential solutions that meet the requirements (BA's memorize these, or something) - and that solution needs an estimate, man...so, other teams need to be a part of that solution design process for estimation purposes (at very least, as well). You'll notice that we haven't created wireframes yet in my strange, rambling scenario I've started to build (sorry, I think I am buzzing on Crystal Light - is that even possible?)

4) When stakeholders understand the new solution and the budget/time related to it...and they love it...well, that's when the BA's need to start writing specifications - all manner of them, I tell you. While IA's are working out the new experience, building interaction designs, structures, models, wireframes, and prototypes...the BA's are annotating those bad boys with the specs...they even write specs for things that don't have interfaces...that's where they are vikings, I think. Use cases, stories, scenarios, interfaces...and a 360 view of features make for some awesome solution design docs, I tell you. If we do it right, we've done some iteration planning - so that we can hand off packages of iteration specs (including technical architecture, solution designs, use cases, stories, wireframes, and annotations) for small parts of the solution every few weeks - allowing tech/design to start building this good stuff we've designed.

5) Lastly, I think that there's a role that UX folks and BA's can do together, going forward...where the roadmap of features are regularly prioritized and slotted for subsequent iterations.

Anyway - I think that BA's, like any part of a good, multi-disciplinary team, are critical for success; however, separating requirements and solutions are key if you want to maintain a design process.

Wow. This is long. Hopefully, this provides some sort of insight into how the BA/IA thing can be symbiotic.

Best,



Tim