Project Background
Role Product Designer
Client CaseWare
Query Dashboard was shorter project that took the highest priority problem from a problem set and drove it to a solution. I also redesigned the entire Query feature from end to end in a separate project.
Project timeline: 3 months
Team: Cross functional product team (Product Owner, Developers, QA)
The product feature was showcased as part of the RCT product demo.
Problem
“...An area where I can see an overview of statuses?”
One of our primary goals for improving client collaboration was to enable users to track all requests and their progress from one location. Furthermore while usability testing the older Query feature, there was a noticeable gap when accountants attempted to follow up after sending the query. A discouraging amount of people were able to actually successfully track their queries as they were collected with their other documents.
Solution
Requirements gathering
We decided on a table layout by wireframing potential solutions. However, there was debate around what would be included in the dashboard.
How much information should be shown in a dashboard?
A table layout invited a lot of requests from both users and stakeholders to add columns. At the end of the day no piece of information on the Query was “unimportant” so we drew a line in the sand on how many columns we wanted. Looking at a prioritized list of use problems we isolated the top few and created a column which addressed the top user problems.
Mindmapped all of the possible information that an accountant may want to see
Iterating on a design
Collaborative sketching of the user flow
The first sketch of the dashboard
Early wireframes
Increasing fidelity
Outcome
Sending to client
Some early concepts, like sending multiple Queries simultaneously, did not make it to implementation. There were conflicts with our current system that caused this to scale back and we could still achieve most of the user value by addressing the other key problems.
Client progress
Clients typically provide incomplete documents, either returning later to finish the request, or never returning at all. An indication of progress was meant to provide accountants with an overview of the client’s progress across all requests.
I had to make a decision between showing the progress as responses provided versus responses accepted. One of the project goals was to increase the response time of follow ups and the amount of responses provided was a key indicator enabling a quicker follow up.
Due dates
Due dates are often ignored by clients and special attention needs to be paid by the accountant due to the amount of reminders which are usually sent out. I chose to highlight overdue requests but there is room for improvement here by allowing the system to prompt for a reminder message which could be sent to the client.
