Reports Center
PCLaw | Time Matters
The new interface for PCLaw is meant to aid with more efficient data entry and usage. However, some reports can crash the system when they are large and are rendered onto the screen. An alternative method that keeps the efficiency of the platform, is to run reports in the background. As the principal designer, I came up with a method for storing and relaying reports to the users in collaboration with the development team. This feature will improve overall platform efficiency, allow for easier report generation and sets the stage for improved report sharing and grouping in the future.
Enhancing software usability during report creation
Project Overview
PCLaw is on-premises legal practice management and accounting software that is used in many different types of law firms, from small to enterprise-level. For many years processing reports has been a source of frustration for our users. Especially if the user has a large database of information, over multiple years, running reports can take hours and might even crash the software.
To solve this problem, the development team has been working on running the reports through new technology, specifically using Microsoft Blazor. However, once tests were run on report efficiency, there remained an issue. If the user runs some reports without filters the report can crash while rendering, causing the entire program to shut down.
The development team identified that they could run reports in the background, rather than rendering them onto the screen immediately, and this could circumvent the issue. However, this would be a new feature for the user and so we have to create a user interface that is easily manageable and lets the user know how they can use the feature and how they can access their reports.
This feature will help to improve efficiency, reduce frustration as reports won’t cause the program to crash and will let users continue to use the program as reports run, which was not available before.
My Role
As the only UX professional at the company, as a UX Manager I considered longer-term strategy and roadmap requirements for User Experience for this project and coordinate with the Product Owners and Developers to assure that the design aligned with the developmental capabilities. Then I had to switch hats and contribute as a designer, regarding research, flows and final designs. My responsibilities were to ideate on methods to showcase this new feature, create user flows, develop low and hi-fidelity wireframes and wireflows and create cards in DevOps for the development team to use for their sprints.
My team was made up a Product Manager for Time Matters and two Lead Developers. We worked together through numerous discovery sessions and coordinated to assure that development could meet design requirements.
Process
Research
Understand how people behave and how we can change that behaviour.
Interviews
We conducted interviews during the year to keep track of our users feelings towards PCLaw. The system crashing or freezing was the largest compliant. This made it clear that creating a feature that would help alleviate this problem would be a giant value-add.
Personas
I created Personas for the key users of PCLaw, a few months ago. These came in handy for this project as I took a second look at them to glean some insights that weren’t immediately apparent. I took a look at the Personas needs and pain-points and I considered how to make sure that this feature meets their needs and removes some pain-points.
Competitive Analysis
I took a look at different styles of notification centers and report centers. I wanted to see what other companies did when their software was showcasing information that was processed in the background. There are many different methods of showcasing it, from layout to table headings.
The focus of the first iteration of this project was to create a minimum viable product. We wanted to release a version that would have all the necessary features to allow our users to run reports in the background, and be able to receive feedback.
Define
Identify constraints of the problem space
Problem Statement
How can we create a feature to manage reports created in the background, that any typical PCLaw user can access, that will teach them how to run reports in the background?
Scope
Constraints
- Design must be complete by the middle of the quarter (1.5 months).
- Design must be able to fit into the current structure of the software.
Objectives
- To convert users report creation from rendering on screen to in the background.
- To make it clear when reports are available for download.
- To give warnings to the user when they are approaching limits of server space.
Functionality
Goal: Create a workflow that allows users to run reports without affecting software efficiency.
Ideate
Generate possible solutions to the defined problem
Alternatives & User Flow
After generating alternatives, and collaborating with the product & development teams, we decided to go with a solution that meets the functionality, but with no frills. I designed a flow, including the required functionality at each point, to double-check the technical feasibility.
Based on my conversations with the development team and my research, I created a simple flow to allow users to run reports in the background and then view the report in a separate area.
The flow prioritized simplicity and clarity for the user to know how the actions they are taking will affect their experience.
Lo-Fi Wireframes
After getting the flow validated by the product and development team, I moved on to creating low-fidelity wireframes. I used simple grey and white rectangles to signify different parts of the user interface, to keep the focus on the functionality and layout rather than colour.
The low-fidelity wireframes were a great tool to discuss the software limitations and requirements. The development team expressed their feedback on the design, functionality and flow, including:
- Whether the software will suggest for reports to be run in the background to the user, and how.
- Where the notification icon will be placed.
- The table layout:
- Removing file size.
- Including file type and download.
- Cannot include a loading bar for status, can only use text statuses.
- Alert UI limitations.
I took their feedback and created high-fidelity wireframes to continue the process; including design critique, usability testing and final approvals.
Design & Discussions
To build layouts and get buy-in on usability & learnability
Design Critique
Every other week I conduct design critique sessions with team members from product, customer support, technical writing and marketing. This helps me get a fresh insight into my designs from different perspectives.
Within the design critique we went through the updated flow and I got some feedback as to how the design might come off to our users:
- Indicate how the reports are managed and the space resources are used.
- Change the name from Notification Center to something that is more relevant (Background Reports, etc).
- Users might not know that they can make the report run in the background, make it more salient.
Usability Testing
Before providing the final design to development I wanted to double check that the feature will meet our users expectations. I decided to seek out the expert opinion of our customer success team. They speak with our users daily and are able to collect their feelings, frustrations and experiences, to relay back to me. Talking with the customer success teams helps because they can identify any friction-points based on their experience with our users.
The team asked important questions about server load, experience if the software crashes and limits to running reports. These were all important questions users might ask, that I was going to take back to the development team to get answers.
Finalizing Technical feasibility
To assure that the adjusted design still met development capabilities, I worked to create a few different options for the key functionalities identified in the design critique and feedback sessions.
I facilitated meetings between development, product and UX to gain alignment on layout and functionality. I started by presenting the wireflow and then opening the floor for feedback or thoughts. Together we determined which layouts were technically feasible and what would need to wait for Iteration 2.
Wireflow
I took back our finalized choices and created a wireflow that would be easy for any assigned developer to follow. It included notes and arrows to provide directions to junior and senior developers.
Testing & Outcome
To validate our solution & reduce risk
User Acceptance Testing Plan
For testing, I came up with a UX-relevant testing plan for the QA team:
- Providing expected user flows so they can replicate the real world experiences.
- Get design/product/customer success to test the flows as development completes certain milestones.
The Final MVP
This new feature provides two distinct benefits. The first is that now that the user is free to continue working in PCLaw and not have to worry about the system crashing as it runs reports, they can be more confident in their usage.
Users can decide to run reports in the background:
- This selection is made automatically for large reports that would previously freeze the platform.
- A note lets the user know they can use the platform while the report is running.
Users will get notifications when the report is complete, including:
- A bottom banner.
- A dot indicator on the section.
- A number indicating how many reports are complete.
Users can enter the Reports Center and see all the available reports.
- Colour is used as a quick identifier, but is made redundant for accessibility through the status column.
- Reports can be downloaded from here.
Next Steps
This MVP feature provides a strong foundation for some really valuable features in the future such as:
- Reports sharing across users in the same firm.
- Automatic reports running at certain intervals.
- Creation of reports sets and report favourites that can be run together.
Our next steps would be to reach out to users of this feature, identified through our analytics, to get feedback on the feature. We would host semi-structured interviews to help direct future updates.
Lessons Learned
Through this project there are two key lessons that I took away from it:
- Iterative Design: The iteration and feedback cycle was key with this project and allowed members across many teams to have a hand in the design and importantly for user-facing colleagues, also be aware of the upcoming feature.
- Clear Project Goals: When projects have short timelines, it is key to define project goals through all teams (engineering, product, QA, support, success) so that we can remain united and aligned.
Personal Accomplishments
- Fostering collaboration between design, product and development teams.
- Using established design system to create hi-fidelity designs.
- Managing stakeholders expectations across product and development team for feature inclusion.
- Making use of Persona research to establish objectives for this & future iterations.