my newly complicated job title
The eagled-eye amongst you (or those with a fondness for the detail of LinkedIn updates) have noticed that my job title has changed.
I’m now officially “Business Analyst/Information Architect”. Yup, there is genuinely a slash in my job title.
Now part of me is genuinely impressed that RNIB is chilled enough about such things. We all get in a lot of tangles trying to come up with one job title that sums up what we do (both to our colleagues and the outside world). That slash is a nice acknowledgement of a messy reality (although you’d probably need to tack another couple of job titles on end before you had an accurate representation of reality).
So why Business Analyst?
1. IA isn’t well understood inside my organisation, outside of my immediate colleagues and unusually the chairman (and before you start, user experience designer would be even less illuminating). People have a reasonably good idea of the space that Business Analysts work in, if not an understanding of the exact details.
2. But more importantly I was already doing business analyst work. A lot of IA/UX training assumes that no BA work has been done, so you start with that before doing the design work. So I naturally did stuff that my BA colleagues recognised as business analysis.
When I did my BA qualification last year, I was struck by how similar the tools and problem spaces are to those in UX world. The cultural context is different so the language used is more business than design, the outputs are less pretty, and there’s often an emphasis on users being staff not customers. Creating such detailed requirements documents was new to me but everything was familiar.
3. There’s more business analysis work that needs doing than there are business analysts. Now you might say that there is surely a lot of IA work that needs doing, and only one IA. And there is. I’ll be putting IA problems on the backburner that need fixing. But I’m comfortable with this because the BA role puts a greater emphasis on ensuring the right problems are being solved, rather than just implementing the chosen problem well.
Again I know there’s plenty of folks who’d say that IA (and UXDers more so) should absolutely be part of the process of picking the problems. That’s fine, you can say that. I’d support you pushing for that to be the case. But the reality on the ground for many IA/UX types is they get told what the project is.
There’s a greater expectation that the business analyst shapes the projects. So for me that route is the fastest way to my destination. And that destination isn’t championing a professional cause. It’s about making sure the money given to the charity is spent well on the people who need it.