Reporting: Part 6 of How to Commission a Software Project
This reporting article is part of the “How to Commission a Software Project” series.
At some point you will stand over a developer’s shoulder, neck-deep in a forensic exercise trying to figure out how a user wound up in an impossible workflow. It’s a lot less fun than it sounds. Even with proper planning, there will always be a useful data point you won’t capture from the beginning, a report you won’t even imagine until operations begin, or a need to account for a customer behavior you never would have expected. So plan reporting well, but expect those plans to be incomplete.
Three concepts will minimize the pain of asking “Why didn’t we think of that before?”
- Start at the end and reverse engineer
- Dig deep on surprising user study results
- Leverage QAs test methods in creating reports
Start At The End
This is my favorite move. Fast-forward your imagination a year or five into the future and make a list of every measurement and indicator that dictated your success. Are there touch points or milestones of user engagement that can be triggers to identify key users? Are there transactions or specific purchased items that indicate a customer is high-value? Do you have a projected average lifetime value that you need to prove to investors? Answer these goal-based questions early and help identify reports based on the answers.
User Studies Tell Stories
In my 24-year career spending time with users of software, I’ve learned that humans do incredibly unexpected things. We could simply shrug it off as “users are weird.” Instead, we should note these behaviors and determine whether some reporting event or business intelligence can provide clues that maybe we, the nerds, are the weird ones after all. It’s a great way to build empathy into your software and provide a super experience in version 2.
Let QA Lead the Way
Even before the developers have started slinging code around the lab, your QA force has hopefully begun developing their test plan based on the requirements. One of the most useful superpowers of a solid QA resource is their sometimes-sinister “ I know exactly how I’m gonna break this” notion. If you get them to share those secrets you’ll have a head start on some of the more unpredictable behaviors of the system and its users for which you might want analytics.
Now, Fix those requirements
Thank goodness you’re using an iterative process to build this software because now that you’ve created a glorious wishlist of reports, it’s time to revisit your requirements documentation and amend and append. And remember to offer feedback to your QA squad so they can update the test plan as necessary.
Interested in getting help with designing or implementing your reporting or business intelligence systems?