Requirement or Design?

The last few years as a BA, I’ve become increasingly convinced of the necessity of mockups, or better yet high-fidelity simulations, in order to effectively elicit requirements. Yes, text based requirements are still a main-stay and process documentation is routinely needed, but when it comes to requirements for a system implementation, being able to show your stakeholders exactly what will happen is simply a must.

Its because of this realization that sites like Service Design Tools strike such a chord whenever they appear in my news feed. I think the Business Analysis community and the User Experience community have both come to the realization that both disciplines are necessary if we’re ever going to create applications that meet our users needs and do so in the condensed timelines that our business partners are increasingly needing.

I love that this site gives you different suggestions for ways to communicate a design, which is nothing more than a visual representation of requirements, to different types of users and stakeholders. Not all of us ‘get’ requirements in the same way, but these generalizations help us tell the story in such a way that we are most likely to get the message through to our target audience.

The other thing that I think is just great about the site is its ability to inspire me to try out new techniques that are not in my current toolkit. I’ve never created a Moodboard nor have I created a Customer Journey Map. Sure, many of these techniques would never work in my organization, but the sheer volume of options suggests that there are at least a few items here that might work for me. I can’t wait to try a few of these out on my next project.