Stephanie Louraine

Report Builder

A case study in interaction design and usability testing.

Screenshot of a prototype showing tools the user can use to format their report.

Business Need

The company wanted to bring a 20-year-old legacy desktop accounting system to the web. The primary goal was to attract new customers who might find the desktop software outdated, but also add value for current customers so they don’t feel alienated by the change.

My focus was on the reporting tool, a high-value, high-impact part of the system used by people of many age groups, all the way from entry-level staff to CFOs.

My Roles

  • Exploratory user research
  • Information architecture and high-level workflows
  • Wireframing, mockups, and visual design
  • Usability testing (moderated and unmoderated)
  • Detailed design specifications
  • Work with scrum team to implement design


Initial research

I conducted a review of the desktop software, mapping out workflows and identifying potential trouble areas. I worked with our customer-facing support and training teams to discuss areas in the software they find problematic. I also conducted a quick online survey to ask current users directly about both their favorite areas of the software, and their frustrations.

From my research, I was able to uncover two common pain points with the report tool:

  1. A lot of important functionality is hidden, which causes unnecessary support calls and leads to dissatisfied users
  2. Customers want to fit all columns on one printed page, but the desktop software doesn’t easily allow them to preview the report without processing it, which wastes a lot of time

First iteration

The first main iteration of the design was a low-fidelity wireframe created in Justinmind as a proof of concept. Among other things, this design would:

  1. Provide immediate visual feedback on how changes would affect the report output
  2. Update information architecture and layout to expose useful functionality many users don’t know exists

One of the design changes I proposed was to combine all formatting tasks together. Before, they were scattered throughout the workflow. For example, I moved the column width setup to the formatting section of the report builder.

This tested very well with users, who tended to mentally group functionality as either data-specific or formatting-specific features.

Screenshot of the initial low-fidelity prototype shown to users. The design featured a live preview of dummy data so the users could easily see whether their columns fit on one page.

First usability study

I wanted to get user input as soon as possible, so I designed a usability study to test the low-fidelity prototype with users. I wanted to test whether the redesigned workflows made sense to users, and whether the design successfully uncovered some of the functionality previously hidden to users.

Two of the findings:

  • The design successfully exposed important functionality that was previously hidden. When looking at the prototype, several of our testers actually learned about useful functionality they didn’t realize existed in the software they already used! For instance, many users didn’t realize they could switch between Landscape and Portrait layouts in the desktop software, but they found it easily in the prototype.
  • The live preview was redundant for functionality that had nothing to do with formatting. For instance, although filtering data is very important to the generated report, a live preview of formatting would not be affected by added filters if the preview was not showing real data. Since we would not be able to show live data due to slowdown and poor server performance, I decided to rethink the live preview feature.

Continued iterations

I made numerous updates to the design, including removing the formatting preview when it was not relevant. I conducted multiple unmoderated tests on to get early usability data.

At this point I also started working on the visual design in higher-fidelity prototypes, and my scrum team and I began to implement the design.

In the desktop software, users had to look through several menus to get to the report they wanted, and new users often didn’t understand what the different report titles meant. The new design lets users search, generate the report directly from the first screen (instead of having to drill down into multiple levels to generate a report), and allows new users to explore and learn about the functionality of different reports.

Prototype of a card view of the reports, showing the ability to generate reports directly from the navigation without having to drill down into multiple menus.

Many of our customer organizations have high turnover, and training budgets are low. I have added on-screen descriptions of the different report types to help new users learn.

Second usability study

After making many improvements to the design, I planned and conducted a second usability study with customers. Some key findings:

  1. Users appreciated a lot of the accelerators (such as search functionality), which alleviated the pain of drilling through many menus to find what they need
  2. I realized the report navigation structure would be great for newer users (our main target user), but advanced customers may find it cumbersome