I’m helping to kick start a project where we’re identifying enough user stories to help build a solution towards a tight deadline for legal compliance. We’ve been making great effort at identifying and talking through the users of the system, particularly exploring how difference users have different needs. We’ve managed to talk to existing users of a similar system, and talked to people who will manage the new users. The hard bit is that our real system users don’t even exist yet.

My work colleague, Alex McNeil, will be proud that I’m pushing for the UX flag and we’ve finally got a UX person onboard which I’m delighted with. I think it’s worth fighting for guerilla UX whenever and however you can get it. In this case, more is always a better thing for end users. I want to be proud that users actually use all the features we build and enjoy using them at the same time. Without properly understanding who they are and what they are trying to accomplish, I’m confident we would have ended up with a naff system.

Also, unlike some developers who want to jump in and start coding, this part of getting into the mindset of a user you’re targeting is a key attribute to the proper use of user stories. Focusing first on understanding what problem your users are trying to solve is the key to building what is actually neeed. I’m not the only one in the agile community to feel this way, with many people inverting the classic and now dated, “As a … I want … so that … “ story format made popular in User Stories Applied.

We’ve made plenty of headway in the right direction and although I know we can take the UX much further, constrained by client expectations, time-conscious of a pending legal deadline. Don’t worry though. We’ll be trying to live out another agile principle of getting fast feedback, even if its done using other guerilla user experience methods.

I care about emphasising the user in user stories because I don’t want to be responsible for one of those systems people loathe to use. I hope you will care about it too.