PROJECT OVERVIEW
Bushel Wallet is a fintech product designed for the commercial agriculture industry. "Bushel Wallet enables convenient, rapid money movement between agribusinesses and farmers."
DOUBLE DIAMOND PHASES
KEY CONTRIBUTIONS
-
Onboarding Design: Led the creation of a complex yet simplified onboarding process, using dynamic logic gates to guide diverse user types (e.g., sole proprietors, multi-member LLCs) through sensitive information collection. This solution minimized cognitive load and was validated through usability testing.
-
Team Collaboration & Leadership: Fostered a highly effective, three-person design team through daily stand-ups and close collaboration. Your leadership in managing the UI designers and working closely with stakeholders, especially engineering, contributed to a cohesive and efficient workflow, leading to a successful product.
SKILLS DEMONSTRATED
-
Design Team Leadership
-
User Experience Research & Design Implementation
SIMPLIFYING A COMPLEX ONBOARDING
Bushel Wallet is a B2B product disguised as B2C. This meant that onboarding a 'user' meant actually onboarding a business. That meant a lot of permutations because business types ranged from sole proprietors (one individual) to multi-member LLCs with individuals spread across different states.
​
That also meant we were also collecting sensitive information, such as Social Security Numbers (SSNs), bank account details, and legal documentation.
​
How do you make such a serious and tedious onboarding process feel light?
​
To address this challenge, we drew inspiration from TurboTax’s approach of asking one question per page. Instead of overwhelming users with long forms or asking them to self-identify required documents, we implemented dynamic logic gates. These adapted to user inputs, simplifying the process and making it feel quick and effortless.
​
The design was tested extensively using Maze.co, with a focus on two key principles:
-
Clarity: Ensuring users understood each step of the process.
-
Simplicity: Minimizing cognitive load by presenting information and questions one step at a time.
The usability tests and subsequent iterations led to a streamlined onboarding experience that accommodated various user scenarios without sacrificing ease of use.​
TESTING MESSAGING EFFICACY
"If users know this, their onboarding will be much easier. Let's test to see if they actually read or understood the message!
​​
As part of this onboarding, users had to upload documents. We assumed that users would be unlikely to continue onboarding if they uploaded a ‘bad’ document. Therefore, the goal of the usability test was to determine which document upload flow was most effective in communicating document requirements. We would show the requirements one of two ways, and then several screens later ask users what the requirements were. We wanted users to retain 100% of the document requirements.
"If users know this, their onboarding will be much easier. Let's test to see if they actually read or understood the message!
​​
As part of this onboarding, users had to upload documents. We assumed that users would be unlikely to continue onboarding if they uploaded a ‘bad’ document. Therefore, the goal of the usability test was to determine which document upload flow was most effective in communicating document requirements. We would show the requirements one of two ways, and then several screens later ask users what the requirements were. We wanted users to retain 100% of the document requirements.
The above is what happened when we tried to 'front load' the photo requirements. We assumed that if we told users before they took a photo of their ID what they need to do, then they'll do it. Well, it turned out we were wrong: if we told users immediately before opening their camera, then they would retain the document requirements for longer. Look at the difference in responses when we showed users the information they needed at the right time:
Instead of being a burden to the user, they ended up thinking of something as mundane as 'photo requirements' good!
As is standard, we also captured time-to-complete in seconds for each screen. However, the difference was negligible between screens.
USER PERSONAS
During a relatively quiet sprint, I thought I'd recycle some insights from old user interviews to create user personas. At this point, I didn't see the point of creating user personas, but it was a quiet sprint and so I thought I'd just do it for the sake of doing. These user personas ended up becoming integral in product discussions across the company. I put these together because of how much time it wasted in our daily stand-up when contributors would try to explain a feature through an analogy, and would use various team-mates in various hypothetical situations. It was confusing. I thought, "if we had a name to refer to that represents one of our user types, then it will be easier to talk about those features." So I put these personas together, based partly on the discussions we'd have between engineering, design and management, and previous user interviews I'd led.
TEAM MANAGEMENT
Something for which there are no screens, but definitely worth calling out is team management. I’m particularly proud of the team dynamic we established on this project, and have not found one like it at any other company or in any other project. As a small, three-person design team, we were able to consistently deliver time-oriented design outputs. Our role with designers in the rest of the company was somewhat prestigious: the other 9-ish designers worked in 'solutions'. This was client work. They had to log their hours, and agree to every whim of the client. We were 'internal', doing our own discovery, and accountable to ourselves. It was a good internal situation and we knew we had to deliver.
Every morning, I hosted 15-minute stand-up meetings where we shared our current work, short-term goals, and upcoming deadlines. Often, these meetings ran a little longer, as we genuinely enjoyed interacting with each other. Building an app from scratch made the work engaging and collaborative, and it translated into a highly productive and cohesive team environment.
​
Another key achievement was the onboarding solution we developed. Given the complexity of our user types and the intricate logic tree behind the onboarding process, I believe we created a solution that significantly simplified the user experience without sacrificing the necessary depth of information collection.
FINAL THOUGHTS
I left Bushel before this product launched, but I am glad to see that the output we delivered is in the current product today. Check it out!