QuickBooks “Advanced” is the accounting software for the US and Canada small medium businesses and mid-market companies. The problem Advanced version of QuickBooks is trying to solve is to cater to the fluid nature of small medium businesses as they have to battle scarcity of resources.
Customer Problem
As the businesses grow, the teams get bigger and business owners are forced to delegate their work. Delegating accounting works to employees demands two primary requirements:
1. Granular permissions (so that employees can do only those tasks which they are supposed to, lest, it will affect the books and the business)
2. Data security (so that employees can see only the data which they are allowed to)
Design Challenge
Robust and future proof Technical architecture
The technical architecture of the RBAC (Role Based Access Control) was designed as a pyramid of requirements, which also defined the sequence of implementation. The best part was that the technical architecture team had envisioned a robust and future proof technical design. Below illustration shows the already built and yet to be built part of the technical architecture.
Non-scalable UI design
How much ever the technical architecture was future proof, the same could not have been said about the user experience and user interface design.
I had joined the RBAC team mid-way and the implementation so far had been by the engineering team. The team did not have a designer during the implementation of Department(L1) and Transaction(L2) level granularity; I had to continue the design and design for Tasks (L3) level granularity and the Record level (L4) data security; which meant that I had to work with the design debt that was introduced in the previous four quarters, which actually meant introducing more design debt and hence making it difficult to build new features planned (or to be planned) in the future.
Following were the design debts identified by me
1. Too much dependence on the info “i” icon for permissions
NOTE: Shall cover the resolution of design debt 1 in another blogpost.
2. Incorrect or non-scalable interaction paradigm explained in next two images. First one explains the current problem and second one explains problems we may run into if we continue on the legacy interaction paradigm i.e. vertical tree structure (which was not consistent though as you can see the Access subscription L3 permissions laid out horizontally)
The design challenge in-front of me was to work on the foundation of the product’s UX which meant risking the expectations of already existing customers who were already used the existing UI, but were also complaining about the half built granularity and complete lack of data security.
Customer Obsession(Grid or table of permissions) v Legacy Design (List of permissions)
Continuing on the legacy design (list of permissions paradigm) meant that the screen will eventually grow into a long scroll of permissions and quagmire of checkboxes. The technical team preferred to continue the legacy design as it meant least disturbance to the code written in last four quarters.
However, my competitor study clearly indicated that the interaction paradigm the legacy design employs to give granular permissions is headed for a user experience disaster. What was required was a GRID or TABLE of permissions instead of a LIST of permissions.
“Sprint&Marathon” strategy
In order to ensure the velocity of the feature release is not affected, I employed a “Sprint&Marathon” strategy
In essence, I was working at two different layers of the product. The sprint track was to ensure the product roadmap is not impacted and we have a steady release of features as promised to the customers; but at the same time, I was also working with my product manager to build the case stronger for a scalable and future proof interaction design.
This unique strategy to ensure right experience is delivered to customers without impacting the already planned product roadmap, helped me to be nominated for the “Customer Obsession award” at Intuit Annual awards 2020.
A. Sprint track — Continue on the legacy design release the granular permissions at L3 level i.e. at task level but with a twist (quite literally). Instead of going vertical, changed the course of interaction from vertical to horizontal, so that the existing customers are tuned for the grid view of permissions that we planned to work on and release later on.
To begin with the first release of L3 and L4 was only at Sales L1 level and it seemed to work without any friction.
However, as you could see below how the intermediate design starts to look clunky and starts to again show proximity and grouping problems.
B. Marathon track — Start a series of parallel explorations and giving it a name called “target state explorations” and conducted customer interviews over zoom with almost every customer who had raised a ticket related to role based access control permission.
Victory to Customer Obsession
“Going Broad and Bold” in explorations
I went broad and bold in our explorations to ensure the marathon track was not biased towards a single approach only. Here are some explorations.
Final design
After 35 customer interviews, 3 leadership reviews, 4 internal cross-functional team reviews, we finally got approval for the development for the GRID VIEW of permissions. Here is the final design after countless functional iterations and customer validation and 3 iterations of visual design.
User verbatim
Following were some of the user reactions on the design we validated over next 5 months
“Last-minute-Challenge” before the release
When it comes to implementation of the grid view of permissions, we however, completely missed out on the timeline of implementation. Since every checkbox in the design meant working with cross functional teams and would mean many lines of code, it was not possible to release the ideal design as is. It was important to design an intermediate phases of the design.
So we collectively decided to disable all the granular checkboxes let the first release be only about the grid view of permissions but functionally it will still be all or nothing access, which looked something like this.
However on customer validation interviews it turned out that customers get irrate when they see checkboxes as disabled and there is no information about how and when the disabled checkboxes will be enabled. On asking what would they do 100% of customers (9 customer interviews) told they would call QBO customer care. This raised the scare of customer call volumes to go up and hence breaking the communication lines. It was critical for us to design for teasing the customer just the right amount but not at the cost of communication infrastructure. Below is the spectrum of solutions provided along with their pros and cons.
