Two users. One platform.
A cleaning marketplace, designed end-to-end.
Most cleaning services make you hand over your phone number before you ever see a price.
Tersus was built to change that. Customers get transparent, self-serve booking. Cleaners get a dependable system for finding nearby work, understanding each job before accepting, and managing the clean itself.
I joined as the sole designer and worked across the full product — mobile app and web, both sides of the marketplace, from first wireframe to developer handoff.
Every decision had to work for two opposite mental models — and survive the move from mobile to web midway through the project.
See real cost upfront, configure a service, confirm in minutes. No contact forms. No waiting for a callback.
Find jobs nearby, understand each one before accepting, manage the active clean, get paid without friction.
Midway through the project, scope expanded to a full web product. The mobile-first system had to scale to desktop without being rebuilt from scratch.
Findings fed directly back into the product. Some scope was added late based on what testing surfaced — keeping research useful instead of decorative.
…build a single product that earns trust from customers and cleaners alike — without compromising either experience?
Three came out of research. One came from a stakeholder request that turned into a real design challenge. All four hit resistance somewhere in the build — and made it to production anyway.
The client wanted pricing hidden until the end of the flow. Research told a different story. Pricing surfaced earlier and more transparently — by the time users reached the Final Quote screen, the total was a confirmation, not a surprise.
The website is very transparent.— Phase 2 tester · customer dashboard round
Once a cleaner accepted a job and arrived at the property, the app had nothing for them. A service checklist and progress timer were added to the active job screen — not in the original scope, identified entirely through research.
Cleaners track rooms as they go, see elapsed time, access pre-job customer instructions, and reach support directly from the job.
Cleaners had no way to define where they wanted to work. A dedicated Cleaning Area screen let cleaners set a preferred location — by address, or by drawing a radius directly on the map.
A custom radius slider gave precise control over distance. The result: a feed that felt relevant, and customers matched to cleaners genuinely available nearby.
Geographic control, straight from research — not in the original brief.
The stakeholder wanted an ASAP option. The brief was simple. The design question was harder: how do you give customers urgency without setting expectations the system can't reliably meet?
The decision: transparency over speed. Rather than a vague "ASAP — we'll handle it" label, the Schedule Clean Time screen explains the entire 5-step process before the customer confirms anything. They know upfront that a cleaner will propose a time, that they can accept it or suggest a new one, and that the cleaner confirms the final window. No surprises mid-flow.
A secondary toggle — Within Business Hours or Anytime — gives customers meaningful control over the urgency window. Most ASAP features skip this entirely. It was a deliberate choice to treat the customer as someone who has constraints too, not just the cleaner.
This required designing both sides of the exchange: the customer-facing ASAP flow with its negotiation model, and a new bid submission screen on the cleaner side that hadn't existed before.
Customer and cleaner experiences designed in full — mobile app and web, both sides, simultaneously.
8+ screens added to scope mid-build — some driven by research findings, others by stakeholder requests that became real design problems. The ASAP job flow alone required a full new bid experience on the cleaner side.
Rolling handoff to developers across the full year — annotated Figma files, interaction notes, and component specs updated continuously.
Critical issues surfaced through structured pre-launch testing before reaching real users.
A shared design language that scaled across two user types, two platforms, and one marketplace system.
Tersus was my first real UX/UI project at this scale, and looking back, it shows in how it started. I didn't know about design systems when I began — I jumped straight into designing screens because the project was moving fast.
The component library came later, assembled from work that was already done rather than built as a foundation. If I were doing this again, I'd slow down the first two weeks significantly and build the system before touching a single screen.
The process was also largely waterfall — designs were handed off to development, and when problems surfaced after build, the work came back upstream for revision. On a project this size, with both sides of a platform running simultaneously, that created real pressure. It taught me how much more effective a closer, more iterative collaboration with engineering is compared to a clean handoff model.
Most of all, this project taught me how to learn on the job at speed. I grew significantly as a designer across this year — in systems thinking, in how to run and apply research, and in how to make decisions with incomplete information under a deadline.