Agile and User Centered Design

Nielsen Normal Group
Nielsen Norman Group

This new article from Jakob Nielsen was an interesting read. It relates back, in a roundabout way if you really squint at it from a distance, to my previous posts (here and here) on where the Business Analyst fits in to the User Centered Design (UCD) process. Nielsen is looking at the problem from the perspective of how UCD fits in to the Agile development lifecycle. The focus on a rapid sprint style of development leaves little room for user engagement and testing. Furthermore the concentration on small sprints to achieve functionality can be at the expense of a unified, user-focused design and information architecture. Unless of course that UCD is integrated in to the project from the beginning. This is Nielsen’s point.

The BA gets involved in many of the areas that UCD preaches (requirements gathering, wireframing, information structure, process flow etc.) but he/she is not a designer, so my query was how they fit together? Nielsen makes this comment:

“it’s important to designate a gatekeeper to track requirements and communications between the UX team and the other project teams to keep everybody on track (even though those tracks are parallel).”

This would be a natural starting point for a BA to again be that bridge between two groups. Although it sounds like a Project Manager type role at first glance, I see greater scope for engagement and influence in the project, and so more of a BA type role. To be the “gatekeeper” between the UCD team and the development team. To integrate the user and design requirements from the UCD side, and working within the information architecture and design principals, bringing that to bear on the functional requirements and delivering that to the development team.

Just a thought.

Agile and User Centered Design

The BA Role, Testing and Support

So this has been a very slow start to my blogging life, I realize this, but essentially since I first got my new job and have subsequently started, really not a whole lot has been happening to blog about. I have just completed my 11 weeks of training with the 15 other new new-hires which has been a mix of methodology and industry training (of which there was a lot to cover).

What is clear however is this company has a very structured and well documented (oh my god the amount of documentation, the intranet is huge!!) approach to the implementation of their software. My role, as it turns out, is actually a combined role of Business Analyst and Customer Support (CS). So I do go in and gather all of the requirements for the software implementation and create a Business Requirements Document from which to work, but instead of passing this client relationship and knowledge on to the CS as it was historically done, I will now also see the client through the test and audit phase after the software has been loaded with the data, help them understand the reports the software generates and will be on-site for when the software goes live.

So I understand that this is not a 100% business analyst role, not that there is really a clear standard for that role anyway as every company seems to use the title and role differently, but it did get me thinking over what percentage of typical Business Analyst’s actually do work on their projects through testing and go-live in the same way?

It seems to me that if you are in a consultancy specializing in Agile software development or as a freelance business requirements gatherer then the answer is probably very little. You have a specific job that you are called in for and any additional involvement is not so explicit. But if you are working in the belly of the corporate beast as I am, then your role probably does have a more holistic aspect where you are seeing projects through to conclusion.

At this point what this actually means for my job is completely unclear as I haven’t even started working on an account. However at this juncture I am looking forward to being able to see my clients through to go live as I feel it will give me a good sense of achievement to actually see the results of the earlier requirements gathering work. I also foresee an excellent learning opportunity because only when the software is up and running and being used by the clients users can you really see how it is used in real life, and where you may have made some errors in the BRD and set-up.

There is an article on the Business Analysis Times that discusses this area – I also stumbled across a posting on this on the Requirements Networking Group website ( however this is in direct relation to Agile and SCRUM development of which I have no knowledge at this point.

If anyone has any input on what happens in your role in relation to testing I would be very interested to hear.

The BA Role, Testing and Support