Case Study: PI’s QuickBooks Connector
Simplify our configuration page for QuickBooks: Users cannot configure this add-on application without our direct help guiding them through the questions. How can we best help the user install and configure the application on their own?
What does the feature look like today? Why? Why.so.many.checkboxes?
The application’s developer knew this was not user-friendly, so he took a stab at Information Architecture and reorganizing the fields into five tabs to avoid confusion:
What would this process look like if we back-filled product research, sprinkled in some user empathy, and approached this new application with an insight in mind?
Killing the user persona
Carolyn Beechwood: Bookkeeper. The cutesy, icon-filled user persona always seemed like a waste of time to me — like an agency spent valuable billable time to find a stock photo of a studious, middle-aged woman and arrange icons to explain she listens to NPR.
My process focuses instead on the empathy exercises that get to the heart of what she cares about. What are her concerns? What does she see, hear, say, touch, feel? The original purpose of the user persona is to create empathy for this user — not establish an embellished character. You want to know your users; not character design a role-playing game.
I have recently been inspired by this Kill Your Personas article, and I’m intrigued. What if, instead of a persona, I built a user spectrum? If looking for “an articulation of a specific human motivation and the ways it’s shared across multiple groups”, I care about the following motivations:
- Who physically uses these screens?
- What is their social context with the remainder of the team using Project Insight? How about not using Project Insight?
- What is the economic impact of this user?
- At what point in the user journey does the user encounter these screens? Where is the user temporally?
- Does the user’s culture have an impact on these screens?
Instead of making up a User Persona’s Myers-Briggs personality, their favorite brands, and their media usage in their spare time, what if I answered these questions and narrowed my empathy scope?
Who’s on the spectrum?
Project Insight, the application, limits the users who can set up the QuickBooks connector. This feature is only available to the System Administrators. However, the subject matter expert who knows the answers to these questions are those who use QuickBooks most often.
Those two groups of people are not the same people unless the team is so small they are outliers of our enterprise-level solution.
Therefore, we have architecturally chosen to require collaboration between the PI expert and the QB expert.
The Project Insight owner
A config page happens toward the beginning of a user journey. The user discovers the QuickBooks connector, and they say “let’s use this feature.” In enterprise software, there is a gap in the journey between discovering the feature and setting it up. This phase is the socialization of the feature to weigh user adoption.
This socialization period touches on the social and economic context of the user. With enterprise-size teams, the product’s owner must determine if there is a benefit of connecting Project Insight to QuickBooks compared to their own political capital. Consider this journey.
If a user hit the configure button you see here, and immediately saw the pages at the beginning of this article, collaboration between PI owner and QB owner does not happen smoothly.
If the user must overcome confusing collaboration with a finance expert, convince another team member to “just get through these five pages” and “it will be worth it, I swear”, or risk a good relationship with their co-worker over this new feature, that amount of friction will stop the journey right there.
The Persona Spectrum
As I built the persona spectrum, I found myself in a User Journey/Persona Spectrum feedback loop. As I reasoned through the potential journey, I came across pain points from the perspective of either the PI owner or the QB owner. That led me back to the Spectrum to consider their permanent, temporary, and situational characteristics that could inform their decisions.
Rather than refer to our user as the cutesy “Mrs. Carolyn Beechwood,” my development team and I could now address the user’s pain points and fear moments. We discussed the feature with empathy for her decisions instead of framing decisions in the input/output world of engineering.
Showing them Carolyn Beechwood left the dev team snickering. Rooting my probing questions in the persona spectrum, my team of developers could understand experiences they recognized and experienced before. They themselves have been in a position where they need to work with someone with a very different perspective to accomplish a common goal.
This experience taught me that any method that leads to empathy is a step in the right direction. For my team, a Persona Spectrum created more empathy and less stereotyping than a traditional user persona. This experiment is definitely worth repeating with more experienced team of designers who value human-centered design.