0

I have an application that has about a dozen reports that provide totals and summaries of data in the database based on date ranges given as parameters. The application is near the end of user testing. The end-users are saying that the numbers in the totals don't match what they expect based on test data they have entered.

It seems like the developers and users interpret the data differently.

How can I document the reports in a way that the users will be able to see which records are being counted,summed etc to get the totals, without overwhelming them with technical details?

So far I have tried to write out the queries used in the reports in pseduo-code, but it seems too technical and I'm worried I'll just get the same 'The report doesn't produce the correct data.'...

Improve this question
1
  • 1
    You'll never get anywhere unless you agree upon the data you are looking to represent. Repeating data in a different visual manner only to find that the consumer is still not in agreement on the data as it exists within the database will produce nothing beneficial.
    – Aaron McIver
    May 20, 2013 at 15:25

2 Answers 2

Reset to default
1

If there is a descrepancy in a report like this, you will benefit from having some kind of data browsing interface. Queries and database tools can be pretty awkward and intimidating to some end-users. I have had some postive results from making a few diagnostic reports that show the pre-aggregated data (for each report). Then if you need to, you can review the raw data with the users or they can review it themselves at their convenience. It is a big plus if you can make it easy to pull the data into Excel. Then you/they can roll-up/summarize/aggregate and then compare results to your report.

Improve this answer
1
  • Exporting the pre-aggregated data to Excel sounds good.Thanks!
    – Paul Anderson
    May 20, 2013 at 23:24
7

When there is a dispute between the users and the program about how the program should work. The solution isn't to fix the users. That goes double when you're presenting data to domain experts.

In this case if the devs and the users have different ideas about what data should be presented, then correct response is to make the data presented match the user's expectations, not painstakingly explain to them why it's wrong.

They're the ones who are going to be using the data, so they're the ones who know how the data should be interpreted.

I'd suggest that the correct response isn't to document the system, it's to fix the system to meet their requirements.

Improve this answer
2
  • That's quite idealistic advice, and this sort of advice will always get up-votes. I appreciate your point of view but you didn't really answer my question. The users' expectations are basically incoherent due to staff turnover and other reasons outside our control, documenting the system is, I believe, an excellent way to help them understand what their requirements really are relative to the system as it stands so that we can move forward. (How else can we 'meet their requirements'- mind reading?) The documentation can evolve with the system since we need to provide final documentation anyway
    – Paul Anderson
    May 20, 2013 at 23:22
  • I work mostly in data presentation, and really disagree that the advice is idealistic. In my experience in a situation like this the thing you need to document is the user's expectations without confusing them further. I don't think approaching the problem using the current data as your primary reference point is going to anything more productive than confuse your users. This is of course based on my own experience of similar problems YMMV
    – Racheet
    May 21, 2013 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.