Complex B2B SaaS · Solo product design ownership
Designing one platformfor two very different users.
Standby was the first large in-house platform I owned after moving from frontend development into product design. Over three years, I designed a data-heavy operational product for landlords and a legally constrained onboarding experience for residents, working across complex states, multi-step workflows, external integrations and reusable UI patterns as the service grew to support more than 1,000 rental units.
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 owned the end-to-end UX and UI as the solo designer, but I did not work in isolation. I collaborated closely with the product manager, engineers, QA and stakeholders, joined technical discussions to understand dependencies and constraints, and used feedback from the wider team throughout the design process.
02 · Owning a growing platform
This was the product where I learned to own complexity without designing in isolation.
Standby was the first design project I worked on after transitioning from frontend development into product design. I stayed involved on and off for approximately three years while also contributing to other products.
Although I was the only designer, the work was highly collaborative. I worked closely with the product manager, engineers and QA, asked questions throughout the process and attended technical meetings so I could understand how the full system worked before shaping the interface.
At the beginning, the priority was functionality. There was little established brand direction, and the platform continued to expand as new requirements, integrations and operational needs appeared.
PHASE 01
Translate the requirements
Turn business needs, legal rules and technical requirements into understandable end-to-end flows.
PHASE 02
Align with the team
Review product logic with engineering and QA, gather feedback and refine the experience as the platform evolved.
PHASE 03
Scale the patterns
Support a growing platform with reusable UI patterns, clearer states and a more systematic design foundation.
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.
1,000+
rental units managed through the platform, showing operational reach rather than a direct UX metric.
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.