New Account Type Integration

Overview

Plooto is a cash management software that helps users conduct accounts payables and receivables.
It was identified that 12% of the existing firm's on Plooto are not accounting firms, despite the fact that the Plooto app, including the on-boarding flow and in-app experience, is entirely catered towards Accountants.
In an effort to optimize in-app positioning and cater towards this previously unknown consumer base, Plooto wanted to know how we could combat this issue.

Role

Lead Product Designer

Responsibilities

Project Concept
UX/UI Design
Product Strategy
Design Tickets

Team

Laura Perschini, Lead Product Manager
Maria Rapoff, Product Manager
Ayaan Hagar, Product Designer
Robert Riverso, Product Strategist
David Choi, Engineer
Patrick Paskaris, Front-End Developer
Michael Kloubkov, Back-End Developer

Timeline

Jul 2024 - Aug 2024
Jump to Solution

Background

Understanding Plooto

Plooto offers it's users three options upon sign up; 'Accounting/Bookkeeping Firm' allows users to manage multiple entities, while the 'Small or Mid-Sized Business' and 'Not-For-Profit/Charitable Organization' options are made for businesses that intend to only manage their own finances. Straight from onboarding, these options cause confusion to its users—it's hard to understand which option is best for them.
Moreover, as 'Accounting/Bookkeeping Firm' is the only option for managing multiple entities, all users must onboard with this account type and go through an experience tailored to accounting firms.

Research

With a sample of 215 firms on Plooto, I first determined how many were accounting vs. non-accounting. Preliminary research revealed that 28.4% of these firms were non-accounting, primarily business consulting and property management firms.
The sample showed a significant number of non-accounting firms, leading product strategy to investigate further and find that 12% of users were outside the target demographic. User interviews also revealed a strong opportunity to create an experience tailored to this audience.

Problem

Since Plooto's app caters its experience and onboarding towards accounting firms, it alienates 12% of its current user base, as well as potential users who assume that the app is only for accountants.

In-App Experience Audit

Using a site map, all instances of accounting-related verbiage were captured. This included phrases such as "accounting firm," "firm member," "accounting member," "accountants & bookkeepers," and many more. These instances are outlined in red below.

Identifying Areas of Improvement

After identifying all instances of accounting verbiage, I noticed inconsistencies in the app, such as using different terms ("user," "company member," and "team member") for the same concept. Although not initially in scope, I raised this with the team, and we decided to address these inconsistencies to prevent user confusion.
Thus, through auditing the app, we identified three key areas of improvement for this project:

Onboarding

There's no option for non-accounting firms, so when these users are onboarding onto Plooto, they're forced to sign up as an "accounting" firm.

Accounting Language

The app's language is tailored to accounting firms and uses technical jargon, making it difficult to understand without an accounting background.

Remove Inconsistencies

The app has various inconsistencies, including visual discrepancies and using multiple terms to describe the same concept, leading to user confusion.

Design Phase

Making Decisions

During the first iteration, I began creating all of the required screens on Figma and applying updates, a couple key design decisions are listed below.

What Account Do I Need?

❌ TwO-Card Layout

✅ Four-Card Layout

Simplifies the experience with only two options.
Personalized experience, catering towards accounting firms and charities, which make up over 80% of users.
After discussing with various stakeholders, we decided to go with the four card layout as it provides a better experience to the user and marketing opportunity. In case users cannot differentiate between the options, there's a tooltip that provides more information.

Naming Our Users

❌ User, Company Member, Firm Member

✅ One Name: User

Inconsistent user titles caused confusion, especially when some modals used three terms in close proximity.
Using one name, "user," makes the experience more easy to understand.
Before consolidating the term, I audited the entire app to find all instances of user-related terms to bring to stakeholders and discuss which to use. User was concluded as the most intuitive option.

Communicating with Stakeholders

As the scope included removing inconsistencies found in our audit, I added them while making updates. However, as more inconsistencies emerged, the scope expanded, and we needed to rethink our approach.
To address this, we held meetings with all relevant stakeholders to decide which updates should be included in the current project and which should be deferred to the design backlog.

300+

Updates to screens

182

Updates to screens

Final Design

Through tracking and applying all of the suggested changes from key stakeholders, I was able to complete a final design.

14

Updates to screens

20

Updates to modals

148

Verbiage changes
Try Out Plooto
View Figma

Pass-Off

Preparing for Pass-Off

Before handing off the project to development, we met with the team to understand the necessary materials for a smooth transition. This included creating a 'Verbiage Glossary' document to record all verbiage changes for easy reference.

Creating Tickets

The lead product manager and I worked together to create and revise all of the required tickets. Within these tickets, I would highlight all of the required changes for a clear pass-off to development.

Reflection

Feedback

Ayaan | Product Design manager

"Great work from Laura and Nancy on the project! Hopefully one of the many quick wins for improving our user experience"

Maria | Product Manager

"Amazing leadership and initiative from Laura and Nancy on this project's work"

Next Steps

Throughout the project, we found design inconsistencies that couldn't be included in the scope. This prompted us to standardize tracking inconsistencies and improve prioritization of design initiatives. Next steps include:

Standardize verbiage

Users of a firm are referred to by various titles throughout the app (user, company member, and team member), with no standardized term used consistently. This causes conflicts when different titles appear on the same screen, leading to user confusion.

update modals

Various modal patterns are used throughout the app without a standardized approach. This project has prompted discussions about creating a larger initiative to update all modal styles.
I’ve logged all the identified next steps and additional areas for app improvement. Many changes have already been implemented, while others will evolve into larger projects.

Learnings

Defining the Scope

We often discovered too late that a change couldn't be made due to missing stakeholder input. Next time, I'll define the scope earlier and involve all stakeholders from the start.

Persuasive Designs

My designs were sometimes rejected for being out of scope, but I argued they were necessary to improve the user experience. This project helped me better advocate for my designs.

Design guidelines

Plooto has flexible regulations regarding the design system, so this project helped me learn more about design guidelines and industry standards by conducting my own external research.

Kudos

Huge shoutout to Laura for co-leading this project with me, Ayaan for design support, Maria for trusting us with Plooto's first completely co-op led project, as well as Rob and David for product & engineering support and weekly syncs for clarification.
Made with love by Nancy.