Founding & Lead Product Designer · October 2021 – April 2026
360 Finance
Designed a multi-portal fintech ecosystem to help contractors close financed jobs and homeowners complete borrowing, while giving internal teams shared tools to manage applications, contractors, and lender settings.
I led product design across contractor, homeowner, and internal admin experiences, from discovery through shipped UI. This public overview focuses on my role, the product problems, and the design decisions connecting those experiences.
THE PLATFORM
360 Finance is a home-improvement financing ecosystem connecting contractors, homeowners, and internal teams. Contractors use it to offer financing for jobs. Homeowners use it to complete borrowing. Internal teams manage the applications, contractor relationships, and lender settings that support those experiences.
My work spanned three connected surfaces: the contractor portal, the homeowner portal, and the internal admin portal. Each had a different purpose and audience, but they belonged to the same product. Designing the ecosystem meant understanding those differences while keeping the overall experience coherent, from customer-facing decisions to the work needed behind the scenes.
THE CHALLENGE
The complexity came from serving different needs within a shared financing workflow. Contractors wanted to keep jobs moving. Homeowners needed to understand a borrowing decision. Internal teams needed enough context to support the people using the platform and manage the work around an application.
Those needs could not be addressed by giving everyone the same interface. The right amount of detail for an internal team could overwhelm a homeowner; a simplified customer experience could leave out information needed to support it. The design challenge was to make each role's work clear without losing the connection between products, users, and the wider workflow.
MY ROLE
I was the founding product designer and Lead Product Designer at 360 Finance from October 2021 through April 2026. I built the design practice, process, and design-system foundations from the ground up, including the component library used by the product.
I led design across the contractor, homeowner, and internal admin portals. My scope included product UX architecture, core workflows, reusable interaction patterns, and design decisions across the ecosystem. I owned product design from discovery and prototyping through final specifications and shipped UI, working closely with product management and engineering.
That ownership connected product direction with delivery: understanding the problem, making the experience concrete, and developing a design the team could implement. Shipping was a shared effort with PM and engineering.
THE SYSTEM
The simplest way to understand the platform is through the responsibilities of its three audiences. This is a simplified product map, not a description of the underlying technical architecture.
- Contractors · Contractor portal
- Offer financing and keep financed jobs moving.
- Homeowners · Homeowner portal
- Understand the borrowing experience and complete borrowing.
- Internal teams · Admin portal
- Manage applications, contractors, and lender settings.
I separated the portal experiences by role and used shared status information to connect the work. Contractors, homeowners, and internal teams needed to understand where an application stood and what action came next, while the actions and level of detail differed by role.
KEY PROBLEMS
1. Making borrowing understandable
Homeowners needed to understand financing while contractors were trying to keep a job moving. That made clarity part of the product problem, not a finishing pass on the interface. A flow could be easy to complete and still leave someone uncertain about the decision they were making.
The design needed to support comprehension without hiding important information. I focused on how language, hierarchy, and progress helped people understand the experience, rather than treating completion alone as the goal.
2. Coordinating work across roles
An application was relevant to more than one user group. Contractors, homeowners, and internal teams had different responsibilities, but each needed to understand where work stood and what required attention. Designing a portal in isolation would miss that shared context.
The problem was to make status and next steps understandable across the ecosystem while giving each role the detail it needed. This required looking at the whole workflow, including the relationship between customer-facing experiences and internal support.
3. Keeping different products coherent
The three portals served different users and could not be identical. At the same time, building each as a disconnected product would work against consistency. I needed a foundation that supported distinct experiences without making every interaction a separate design decision.
That connected the product's architecture to its design system. Role-specific workflows needed room to differ, while shared patterns gave the ecosystem a consistent foundation. Reuse was a way to support those differences, rather than erase them.
DECISIONS
Use plain language and visible progress
I used plain-language lending copy and progress indicators to support understanding at decision points. The aim was clarity without removing information that mattered to borrowing. Homeowner research and prototype testing informed that direction.
Organize around shared status understanding
I made status an organizing principle across the portals so users could understand where work stood and what action came next. The shared understanding supported coordination; each role still needed its own level of detail and relevant actions.
Separate roles, share the foundation
I separated experiences by user role while building reusable components and interaction patterns. This allowed each product to focus on its audience without treating consistency as a requirement for identical screens.
SYSTEMS THINKING
Building the design system was part of designing the product ecosystem. I established the component-library foundations and reusable patterns alongside the work across the three portals. The design system gave that work a shared starting point.
A homeowner's borrowing experience and an internal team's working tools could share a design foundation without carrying the same content or complexity.
COLLABORATION
Inputs came from homeowners, contractors, internal support and operations, product stakeholders, and engineering. My role was to synthesize those signals into product decisions, rather than treat every request as a feature to reproduce.
Workflow mapping and prototypes helped make terminology, hierarchy, and cross-product relationships concrete before implementation. Homeowner interviews and prototype testing informed the focus on plain language and progress. Internal-team feedback helped shape the operational experience.
I worked with PM and engineering from discovery through specifications and shipping.
IMPACT
The work produced a design practice and design-system foundation, alongside core platform features shipped in partnership with PM and engineering. My contribution spanned the three portals rather than a single isolated feature, connecting product architecture, workflows, and implementation.
The component library became part of the product's foundation.
DEEP DIVE
Additional detail is available in the protected case study. Access is required because it contains material that is not included in this public overview.