Plooto - dashboard

Project Context

What is Plooto?

Plooto aims to simplify and streamline payment processes for businesses by providing an all-in-one platform for managing payments, approvals, and financial workflows. Plooto provides businesses with efficient, secure, and automated payment solutions to enhance their financial operations.

How did I add value?

When I first joined Plooto, there was a series of A/B testing experiments running to determine how to best bring new users to see value in our product sooner. As the primary designer assisting in the A/B testing experiments, my role was to design alternative experiences to better highlight the value of our product. The result of this project was a 39% increase in trialists to clients conversions seen.

First, let's define our problem

DEFINE & SCOPE 🎯

Current Workflow

The current onboarding forces our new users to complete their verification steps immediately after signing up, without telling them WHY they need to do so.

DEFINE & SCOPE 🎯

A/B Testing Experiments

During the first two experiments, the verification step of onboarding was assumed to be what the user should do first since it is crucial to unlock most of the other functionalities. The goal of experiment #3 was to discover what the core jobs to be done for our users are.

Goals for new iteration

Instead of asking for info first, show the value and then redirect them to completing the verification needed
Allow them to experience the product before asking them for personal information

Next, let's conduct some research

PRODUCT THEORY 💭

Jobs To Be Done (JTBD) Model

Upon starting this project, I knew about the JTBD model from a previous internship, but had never applied it. Knowing the goal of this project, I looked into the JTBD model and have summarized the important points that are relevant to this project below:

Focus on jobs, not people
Jobs are situational and contextual
Compete against non-consumption

SECONDARY RESEARCH 🔍

Competitive Analysis

As a part of our secondary research, I conducted competitive analysis to explore some existing user experiences. Through the research process, I posed as clients and discovered many pros and cons of each application I tested.

Now, let's get to ideating!

IDEATE 🖋

Paper Sketches

To begin imagining the workflow, I drew up some sketches of different possible experiences. I explored both options of surfacing the verification steps first, as well as surfacing the product features first.

IDEATE 🖋

Low-Fidelity Wireframes

With the general page layout complete, I took the designs to Figma. Once the designs were in low-fidelity, I presented them to my product managers and other designers for feedback. I also made sure to consistently ask engineering for feasibility feedback as well.

Since Plooto has recently been following a new initiative to make our platform more responsive, I made sure to design low-fidelity wireframes for different devices.

Finally, it's time to present final designs!

PROTOTYPE 💻

Final Designs!

Below are the final designs ready for A/B testing.

FINAL DESIGNS 💻

Polishing for Handoff

Before handing off I went through the flow and fixed up some small details, ensuring I was following the design system for typography, spacing, padding, and colours. I annotated the designs, outlining the interactions, components (& states), and any other notes that may be helpful for implementation.

I received exceptional recognition for considering all the states and the responsiveness of my designs.

Reflecting on this project...

REFLECTIONS 💭

Lessons Learned

The value of the Jobs To Be Done (JTBD) model

Shifting the focus from features or products to understanding the underlying needs and motivations of customers helped us better meed our customer needs and preferences. By thinking of what our users WANT to complete in our platform rather than what our customer NEEDS to do for us, we helped direct more users to seeing the value of our product sooner.

Developer handoff

Perhaps what aided the most in my success in collaborating with engineering was my understanding of engineering feasibility. I made a constant effort to ask for feasibility feedback with every design decision I made. The end result was a very seamless developer handoff since our engineering team was constantly kept in the loop.

Sketch first, Figma last

I’ve learned that when I go straight into designing in Figma, I tend to get distracted by the visual elements and making everything look “pretty.” Yet, without finalizing the UX of the platform, a lot of my Figma iterations end up being scrapped. When using a UX shorthand and sketching on paper, I can eliminate my tendency to get carried away setting up components and variables and just focus on the first task at hand: designing the UX.

REFLECTIONS 💭

Next Steps

Explore accessibility

Something that Plooto has recently been striving to improve is its accessibility. Alongside this project, I have also been working on design system work, specifically, on writing documentation to outline our design standards. Unfortunately, some parts of the experience is legacy design, which I could not change due to the amount of dev work it would require. With more time, I would look into updating our designs to fit certain design best practices while staying within the limitations.

Iterate, iterate, and iterate more!

Due to our tight timelines, we did not have the time to iterate our designs, but rather just went with the first hi-fi designs I provided. Given more time, I would advocate to further iterate my designs after receiving some feedback from the A/B testing.