report authoring workflow for non-technical users

Question

I'm overhauling the reporting features of a B2B web app whose users are usually smart but not-very-technical managers in blue-collar workplaces. Report generator apps like Microsoft Reporting Services and Crystal Reports are usually targeted at more sophisticated users. Some of our users barely know how to use Excel! So I'd like to provide simple reporting workflow to guide our low-tech users to the right results.

I'm willing to trade off flexibility ("build any kind of report") for ease of use, but I can't limit to a set of canned reports because we need ability to easily add and remove columns (a competitive product offers this feature and users love it!)

So far the workflow I like best is a wizard-like approach that limits complexity at each step, like this:

1. Is an existing report close to what you need? If no, keep going. Otherwise, pick an existing "canned report" and edit it.
2. One row for every __________ ? Choose from a list: Year, Month, Day, Week, Customer, User, Warehouse, Product, etc. This is a "dimension" in BI terminology, but I'd avoid that term here-- too confusing. The dimension's primary key (won't use that term either!) will be the first column in the report.
3. What columns? Each dimension has a default set of columns (e.g. for Product dimension the defaults may be SKU, Price, Last Month Sales). Users can rearrange (drag-and-drop) or remove columns, or add new ones from a list of applicable columns (each with a friendly name and plain-English explanation).
4. What filters? Allow filtering results based on 1+ values, e.g. (SKU = 12345 or 34567) and (Customer = Acme Corp.). Ideally, allow "contains" filtering on text fields, e.g. "all customers with XYZ in their names". By default, all reports will have a Date Range filter.
5. Group By / Total By _________? Show totals or not? Group results (with subtotals?) by _____ ? Show visual examples of what "group by" vs. "not group by" looks like.
6. Run Report. If we can get the performance good enough, skip this step-- just populate the grid in real-time as the user picks columns and filters. Otherwise, use a button!
7. What's next? Enable saving report for later use, exporting to Excel or PDF. Provide an easy way to edit columns and filters from here.

Any thoughts about how to improve this kind of workflow to allow it to be conceptually simpler for the user? Are the steps in the right order to simplify use?

Finally, custom reporting for non-technical users seems like a problem that's probably been adequately solved by smarter people than me. Any pointers to existing implementations that you think are successful?

Answer 1

I've had to go through similar tests myself to build reporting systems. I can tell you that if you have more than 3 steps you will confuse all your users. The ones who get it will just get frustrated.

Unfortunately I cannot comment too much on your backend technology as there isn't much detail on it. However one thing I would like to point out is that I had as many options as you at first. It simply wasn't practical to do so, especially to the end user.

If you can, these should be the only steps you need to successfully create reports:

1. Report Definition: Report name, frequency, and data range. Frequency determines how often the report runs and the range is for how much data it gathers.
2. Metric Selection: Choose the metrics (the columns) you want the user to add to the report.

Upon completion of those two steps the report should be added to the queue and executed based on the frequency set. The additional steps that you had should be provided in Adhoc options after the report is created and executed. This would allow the user to drill down into details to find more detailed answers to their questions. Like "how many females bought this item?".

Now if you have a system as I used to have that didn't allow for Adhoc after the report is created, you can add another step.

1. Report Definition: Report name, frequency, and data range. Frequency determines how often the report runs and the range is for how much data it gathers.
2. Metric Selection: Choose the metrics (the columns) you want the user to add to the report.
3. Segment Selection: Allow the user to create segments that they can reuse between reports. This will save them from recreating the same filters / group by, etc and will allow you to put checkboxes / selectors

Creating reports is definitely tricky and often depends on what you have on the backend. I've used plenty of tech to this day to know that if you are sacrificing UX because of your tech, you should reconsider your tech. Though you should probably only reconsider new tech if reporting is the primary function of your service or product as it can sometimes be a daunting task to switch to something like Crystal Reports to Vertica (as I am now using).

Answer 2

Your questions are best addressed via user research. Conduct user studies to see if your users can meet their goal with your design. Remember that the user's goal is not to create a report; the report is a means to an end to them.

You could extend this to conducting a competitive evaluation, where you give users of your application and users of your competitor's application the same set of tasks and compare their results. You might learn why the ability to add and remove columns is important to them, which could tell you more about your product than about the feature of adding/removing columns. Perhaps users love it because the canned reports are almost, but not quite, right, and adding/removing columns means that they can use a canned report with minimal effort. That potentially means that you can improve your canned reports instead of focusing on adding the ability to add/remove columns.