Complex B2B SaaS · Solo product design ownership
Designing one platformfor two very different users.
Standby began as a founder-led concept without an existing product or design framework. As the first designer on the product, I translated the idea into the initial user flows, visual direction and interactive prototype. Over the following three years, I evolved a data-heavy operational platform for landlords and a legally constrained onboarding experience for residents, working closely with the founder, product manager, engineers and QA as requirements, integrations and real client needs reshaped the service.
Project details
One system, two modes of use
A frequent operational tool for landlords and a rare, high-trust onboarding experience for residents.
01 · Overview
A deposit platform shaped by legal requirements, operational complexity and two very different user needs.
Standby allowed landlords to manage security deposits across properties and units. They could upload rent rolls, invite residents, monitor applications and release or claim deposits.
Residents entered the product through an invitation from their landlord, completed a required application flow and received a Standby Deposit Certificate. Unlike landlords, they might only use the platform once or return very rarely.
Much of the complexity lived below the surface. The interface had to translate backend-driven states around invitations, applications, deposits, certificates, claims and releases into clear actions while preserving context across multi-step workflows.
Its complexity came from legal requirements, integrations with external services and the need to keep landlord and resident workflows aligned as the service expanded.
My contribution
I was the first designer to work on Standby and owned the end-to-end UX and UI, from translating the founder’s initial concept into the first product flows, visual direction and interactive prototype to evolving the live platform over three years. The early prototype gave the team a tangible way to communicate the product in investor conversations. Throughout development, I worked closely with the founder, product manager, engineers, QA and stakeholders to align the experience with business, legal and technical requirements.
02 · From concept to product
From early concept to operational product.
At the beginning, Standby was still an idea rather than an established product. There were no existing interface patterns, tested workflows or product data to build from. I established the initial visual direction and translated business assumptions into the first connected landlord and resident experiences.
As development progressed, the platform changed alongside the business. New legal requirements, integrations, operational states and client needs affected both the information shown and where actions belonged. The later version was therefore not a one-off redesign, but the result of continuously adapting the product to a clearer understanding of how it needed to work.
As landlord portfolios and product requirements grew, the property overview became more data-led and scalable. I simplified the cards, clarified the information hierarchy, introduced more detailed filtering and moved key actions closer to their relevant context.
Designing around an evolving technical reality
Early concepts assumed that landlords could connect or import their property data independently. As implementation progressed, integrations still required support from the Standby team. I redesigned the zero state to reflect the available paths accurately: add a property manually or contact Standby to connect an existing property-management system.
03 · Two user journeys
One user needed a powerful operational tool. The other needed a short, reassuring experience.
Landlord experience
Frequent and operational
Landlords used the platform to manage properties, units, residents and deposits. They needed visibility, filtering and control across large amounts of information.
Upload rent rolls and add properties
Invite residents and track applications
Review units, deposits and statuses
Claim or release deposits
Access history and ongoing activity
Resident experience
Rare and trust-sensitive
Residents entered through an invitation and might never have heard of Standby. The experience needed to explain the service, collect required information and build confidence without becoming overwhelming.
Understand the invitation and service
Complete legally required onboarding
Provide identity and payment details
Track progress through the application
Access the final deposit certificate
04 · Landlord platform
Making a dense operational product easier to scan and act on.
The landlord side contained the largest amount of information and the widest range of actions. Properties, hundreds of units, applications and deposit states had to remain understandable without hiding the detail users needed.
At property level, I separated summary metrics from unit-level actions. Landlords could begin with the overall state of a property, then move into individual units, residents, applications or deposits without losing context.
Reusable status patterns, filters and clear action hierarchy helped users identify what required attention across large numbers of units. I reviewed these workflows closely with engineering and QA to make sure the interface reflected real system behaviour and technical constraints.
05 · Resident experience
Keeping a mandatory onboarding flow simple and straight to the point.
The resident application required several mandatory stages. The challenge was to keep the process moving without cramming too much information into a single screen or making users feel that the flow was longer than necessary.
Near the end of the project, I conducted user testing on the new onboarding flow. Participants described it as clear and direct, with no unnecessary steps or filler content. Several completed it faster than they expected compared with similar application processes.
“Simple and straight to the point.”
User-testing participant
After onboarding, residents had little reason to return frequently. I therefore kept the dashboard intentionally minimal: show progress when an application was incomplete, then surface the active certificate and essential information once the process was finished.
Two states for a low-frequency user: continue an unfinished application or access the completed certificate.
06 · Design system
The first design system I created grew alongside the product.
As Standby expanded, I created and maintained reusable patterns for typography, grids, forms, tables, status indicators, cards, navigation and recurring property-management workflows.
It was my first large component system and I developed it through research, trial and error and close collaboration with the development team.
The system supported both the landlord and resident experiences while allowing each side to communicate a different level of complexity and product weight. It also gave engineers a more consistent foundation for discussing and implementing new features.
SYSTEM 01
Reusable patterns
Common forms, states and table interactions could be applied consistently across new flows.
SYSTEM 02
Shared language
Components gave design and development a clearer vocabulary for discussing the interface.
SYSTEM 03
Room to evolve
The library continued to change as the product, Figma and my own system thinking matured.
07 · Evolving the visual identity
Translating a new brand direction into two connected product experiences.
Later in the project, the company worked with a branding agency and marketing leadership to develop a new visual direction.
Following that direction, I translated the updated identity into the platform and created more distinct colour systems for the landlord and resident experiences while keeping the products recognisably connected.
This helped the two sides communicate their different purposes without turning them into unrelated products.
08 · Outcome & reflection
The shipped product reached operational scale, and testing supported the revised onboarding direction.
Before development began, the first interactive prototype provided a tangible way to communicate the product in early investor conversations. Standby later secured $5.25M in seed funding to complete the product, pursue bank partnerships and grow its US client base.
1,000+
rental units supported by the platform by the end of my involvement.
LESSON 01
Systems become essential as complexity grows
The design system became more valuable with every workflow, status and product requirement added to the platform.
LESSON 02
Different users need different levels of product weight
Landlords needed a powerful workspace. Residents needed only the information and actions required to complete one important task.
LESSON 03
Introduce research before scale
Early decisions were initially driven by business and technical requirements. Later feedback and usability testing showed how earlier validation could have reduced rework and made prioritisation clearer.