Extending the reach of small businesses at a time when they needed it most.
I led the design and research of Intuit's first consumer automation platform for Quickbooks. What was once a project to tap into the third-party developer market's profits quickly became an effort to help small businesses enter the omnichannel during the COVID-19 pandemic.
Context: My team at "The Intuit Developer Group" (IDG) is responsible for maintaining the Intuit Design System, all API documentation for third-party Quickbooks developers, and internal automation efforts.
Opportunity: IDG found that creating third-party solutions for QuickBooks is a worldwide, multi-million dollar industry - and Intuit wanted a piece of that pie.
Objective: My team's objective was to build a consumer-friendly no-code Integration Platform as a Service (IPaaS, a.k.a, an automation platform) to help QuickBooks customers manage and speed-up monotonous tasks within their workflows.
An IPaaS Platform is an API-led, cloud-based architecture that allows two or more APIs to "communicate" with each other. If something happens in one API, the IPaaS will trigger an action in the other API. This is what we know as Automation.
In 2014, Inuit acquired itDuzzit - a Zapier-like startup - to bring automation to Quickbooks. I worked closely with Co-founder Steve Mendoza - now Principal Software Engineer at Intuit - to understand his thinking behind itDuzzit, its system, and future vision.
They had a proof of concept for consumer automation and some really powerful backend that my team could leverage when creating our product.
The logic was there. However, it was clear that a small-business owner would have a hard time setting up their automation.
Before diving deep into research, I worked with my cross-functional partners to gain consensus on some preliminary assumptions.
I spoke to customers about their perception of automation and its implications for their business. Another theme that I probed during the interviews was how each industry uses applications to run its processes.
We validated our initial conjectures through this research and learned that small businesses know what automation is - what they didn't know was how to get started with automation. Some customers looked at tools like Zapier, but what they found was that learning a new platform and paying for it introduced an opportunity cost.
Small businesses were not intimidated by automation, although they did not see how it would work for their specific industry. Automation is not one size fits all.
We also confirmed (to no one's surprise) that small businesses were hurting significantly. Businesses were feeling helpless because they didn't equip their brick and mortars for a global pandemic - who was? They could not compete with Amazon and Walmart and felt like time was running out. They knew they needed to diversify their business channels and rake in more revenue from e-commerce sales.
We learned how data flows through a business and the industry-specific apps that appear (CRMs, and POS systems). Some common "business-standard" apps (Like Google Sheets or Slack) and Marketing Tools like Facebook Ads.
This research ultimately informed us of the logistical challenges that small businesses face and helped prioritize what apps would make our MVP. (Shopify, Shipstation and others in the e-commerce stack)
We learned that the problem wasn't whether or not small businesses wanted automation or knew what it was. But instead, SMBs were unsure if automation was worth their time and met their specific contexts.
Furthermore, we found that instead of designing an automation platform to replicate the services that third-party solutions produce, we saw an opportunity to lessen the pressure e-commerce giants impose on small businesses by leveraging our substantial third-party developer pool to create personalized automation for customers.
In parallel with the interviews, we quickly conducted a competitive analysis of primary and secondary suites of applications that can fit the same use cases in order to inspire requirements and serve as a foundation for design explorations.
I coordinated with my PM early to conceptualize feature requirements and advocated for our engineering team to join those meetings to communicate feasibility concerns and give overall feedback. Through these conversations, we created a user flow for the ideal state, taking into account the creation and setup of automation.
The main challenge I faced during the design exploration of the platform was gauging how much modularity we should introduce to the user in the initial stages of the journey. The more small moving parts you show to the user, the more arduous the task may seem to them. However, if we failed to present enough value to the user, there might not be a reason for introducing automation into their workflows.
The conversations I had at this stage of the design process revolved around how I intended to show the value proposition quickly while inspiring action.
I worked with Christiana Gunn, a Senior Content designer on the Quickbooks team that has worked on projects surrounding internal automation, to identify a conceptual model that would help users visualize the mental model of automation and facilitate a happy medium between developing understanding and selling the main value proposition of automation.
We agreed that automation could be best described as, "someone doing something for you" through our conversations with different small business owners. So we wanted the content to reflect the feeling of the platform taking the wheel after they finish with set up.
We found that some automation sequences are intentional - while others may be a discovered requirement. So I (with guidance from the fantastic QuickBooks Design System team) designed a component to show the "art of the possible."
We decided to segment the automation creation and configuration process into separate screens to lower the chances of users feeling overwhelmed by the following tasks.
After selecting action and trigger apps, the user can now connect these apps through an OAuth2 flow. You're probably familiar with this flow if you've used the "Sign in with Google/Facebook/Etc." button on your favorite apps.
I also designed a flow for apps that require a "secret key" entered manually.
This part of the platform depends on the apps chosen at the beginning of the creation process, meaning that the configuration screen will look different for every combination.
While we could have designed every configuration component manually - and had our engineers work on integrations for every app in our MVP, it wouldn't have made sense scale.
So I designed the system for how our partner apps' (the third-party vendors that our original scope hoped to run to the ground) custom integrations would appear on the configuration screen.
The thinking was that the partner apps would create the integrations commands themselves because it is in their best interests for Quickbooks to work well with their apps. This method has already been tried and true with the apps store on QuickBooks.
After a user successfully creates their first automation, we assume that the user knows and understands the use cases of the feature. So we replace the education component with a utility component to quickly manage automation at a glance of the dashboard.
A user can turn an automation on/off, view logs, reconnect/switch Auth Tokens if necessary, and delete the automation entirely.
Throughout the project, design and development worked well to voice feasibility concerns and create workarounds. When it was time to hand off early designs, I presented these in an annotated wireframe process flow.
The engineers I worked with were highly specialized in backend development (and were seriously fantastic at it). So I included detailed mocks of how the designs would behave and conform to the paradigms of the Quickbooks design system.
There were for sure opportunities to add quick and valuable "moments of delight". While these moments of delight are nice to have, it was more important to focus our efforts on executing automation before adding cool micro-interactions or animations.
One particular delighter that I would have loved to have experimented with was a "Human Hours Saved" message somewhere in the experience. (similar to Stripe's Climate convention above) The message would reassure a user was making an impact with their automation. The problem was that I would have needed to find out how much time particular automation would yield. That was more research time that I, unfortunately, didn't have.
Design systems people are your friends: You need to extend your hand out to your design systems friends when you can't find a component to fit your context. It's their job to keep things consistent and tight, but they also know that sometimes there are exceptions. It's important to remember that - if they object, it's probably for a good reason.
Research is non-negotiable: I was aware of this rule before the project, but it's drilled even deeper into me now. If I were complacent about generative research being axed off the timeline, the product would have been a mess before it even started. As designers, we're the closest user advocate in the org. It's a big part of our job to reach out to them and challenge how we view the world to create an experience tailored to them.
Your senior designers have seen some shit: Take their word for it when they don't think a particular flow would work for a specific context. Think for yourself, but sometimes lean back and let their experience work for you (and your users).
