High-level view of the 7 competitors we assessed
OVERVIEW
About the project
Businesses that provide services depend on invoices to receive payments from their clients and customer. I helped create an invoice creation experience that would be applicable to many types of merchants from home contractors to catering businesses. I collaborated with another product designer, a content designer, a lead engineer, and a project manager to add the ability to track and create invoices from the Clover mobile app.
The problem
Although the majority of Clover merchants are service-based businesses, we did not have a way for those merchants to create and track invoices on the go. If a merchant wanted to send an invoice to a customer from their phone, they couldn't do it from the Clover app.
The goal
Allow merchants to create and track invoices from their phones in the same app where they are able to track their sales activity and manage their business. Merchants shouldn't have to alternate between a web browser and an app to run and manage their business.
Responsibilities
Interviews, user flows, competitive analysis, visual design
Tools
Miro, Figma, UserTesting.com
30K
Merchants who use invoices
1,000
Invoices created everyday
Empathize
COMPETITOR ANALYSIS
Evaluating where we stand as well as where we can differentiate ourselves
There are many invoice products that merchants can use to send invoices to customers. Some products are solely focused on invoicing while others, like Clover, include invoicing as a feature.
We noticed that many of these experiences have some similarities among them such as a form-like structure, the ability to add multiple line items, flexibility for customization, and a preview of how the invoice will appear to the customer.
Consolidated takeaways from interviews
INTERVIEWS
To understand what our merchants need and want when creating invoices, we conducted user interviews to build to inform the design as well as prioritize feature requests. Together with the team, we prepared an interview script, focusing on our target audience’s values, motivations, and daily routines. We recruited and interviewed 6 users remotely. We referenced the user interview findings throughout the entire design process.
Key takeaways
Merchants need to have a quick way to track paid and unpaid invoices
Merchants need flexibility in defining which fields they have on their invoice
Merchants need a way to see the status of an invoice for task management
Merchants need a flexible system for invoice creation
User Journey
Based on our interviews, competitive analysis, and list of feature requests, we outlined the entire flow from setup to tracking. Not only was this useful for crafting the mobile experience we were tasked to create, but it also informed us how we could expand and improve invoicing across all of our channels. With the help of multiple project managers, we assessed what we were able to support and what should be on the roadmap for future releases.
From the paths we outlined, we discovered that how invoices are configured both in settings and during invoice creation would impact how customers could pay and what would be important for the merchant to track. So ensuring these settings and configurations were clear and easy to navigate would be essential to a successful invoicing experience.
Steps that wouldn't be part of the MVP were de-emphasized to keep design and product aligned.
Working with product managers to define what's possible for the MVP
After outlining the ideal experience, we met with the 3 product managers who had a stake in invoicing and narrowed down what design and engineering could and should accomplish for the MVP.
Ideate
One of 4 flows that came from brainstorming invoicing at a high-level
Sketches
Honestly, I started with higher-fidelity mockups because I knew we already had some existing patterns such as adding items to an order. But I kept getting blocked because I was trying to take an experience that worked in another context and fit it within invoicing.
So I took a step back and realized I needed to sketch out ideas first. By going to a lower fidelity ideation method, I was able to think more clearly about how to build an invoicing experience catered to the user's mental model rather than trying to work within the technical constraints and reuse existing modals.
Wireframes
After reviewing with another designer the 4 flows I sketched out, we decided to move forward with 2 of them. Using Figma, I translated those sketches into low-fidelity wireframes.
At this stage, the wireframes were defined enough for a broader design crit. Based on feedback from that design crit, we decided to show all invoice pieces on one page as well as put it into a full-screen modal once other designers pointed out all of the different areas a merchant might want to create an invoice from.
Deliver
FINAL UI
Prototyping and handing off
Once we had reviewed the wireframes with our product manager and the broader design team, I created high-fidelity mockups and wired together a prototype. I aim to always create a prototype before handing off design work to the developers. It helps me catch anything that might be a less-than-ideal interaction as well as help answer questions for the developers.
NEXT STEPS
To learn from the MVP, we asked engineering and product to set up analytics that would help us validate or gain a better understanding of some of the assumptions we made during the design process. We'll use those analytics to inform the post-MVP updates.
01
Expand the experience to include enhancements we weren't able to include in the MVP such as configuring customer payment reminders and editing accepted payment methods.
02
Learn from the analytics we're able to capture with the launch of the MVP and use those to better inform the design direction.
03
Test the post-MVP experience with users before implementing it so that the complete experience truly is complete and easy to use.
LEARNINGS
This project's release was pushed up a quarter, so the time we thought we had to dedicate to it was shortened by several weeks. I know we'd have to scale the MVP back even further in order to meet the release date. Because of this, product, engineering, and I had to get aligned on not only what we could build but also how we should approach the MVP so that we are still setting ourselves up for success for the post-MVP release. As a designer, it's important that I remain flexible and listen to my colleagues, but I also have to continue to advocate for our users and ultimately bend without breaking.