Recently I've been working on a financial project, with multiple scenarios and loads of data to consider for each interaction. This was the type of project where you can have multiple BAs to help with the stories, and sometimes you can say it's not even enough! Luckily, on this project there were two of them, both brilliant and experienced.
With all this amount of user stories to incorporate in the experience, the Axure prototype became soon very complex and intricate, as it was supposed to cover each of those.
So I started to questioning the way of delivering the demo itself, asking myself simple questions like:
- How Can I communicate to the build team if the story is covered?
- How Do they know how to replicate it in the demo?
- How Can they know how many messages the page needs to incorporate?
When a page has 2 or 3 stories it's easy, and you can work closely with the Devs to ensure that everything is understood, but what if the page has 20 of them?
After a bit of playing around on the Axure tools, I found a quite easy way to answer to all of those doubts. This approach is still to test, as the project is ongoing at the moment, but I'm quite hopeful, so finger crossed!
Basically I used the Page Notes to list the User stories related to that specific page, indicating:
- the reference of the user story (usually the number), and the Acceptance criteria if necessary
- if the story/act was covered or not (yes/no/partially)
- how to replicate it in the demo itself (Click on the button, put 50 as value, wait 30 seconds, show this messages, etc.)
At the end of the notes, I also added:
- the list of the messages possibly shown in that page, to have a clear reference about how many error messages need to be addressed.
Here it's shown how this can look like in the real demo.
This was a good exercise not just to avoid the confusion of the build team, but also mine!
Some pages were so full of variables and hidden panels that would have been impossible for me to remember in the future how to replicate all these stories (click there, put this value, wait 30 seconds...I'm lost already!).
So it was good for me to track each interaction in that way.
It's easy and handy for the build, which can explore the demo without missing anything, and it's super important for you to communicate each interaction as well.
It can look like a methodic work today, but it can save a lot of pain in the future, from my view.