Why we designed things this way. The 12 principles are the decision rubric; the key decisions below explain specific choices.
"Make executing a shift a joy for the field, and running a portfolio effortless for the office."
When two design options compete, the one that better serves these principles wins. Listed in priority order.
The tasker's experience is the product's soul. Consumer-grade UX. If a feature eases the Manager at the Tasker's expense, the feature loses.
Every task shows its guest, arrival window, upsells, VIP flags inline. The tasker never asks "who's coming?"
Prioritization uses revenue signals; taskers see badges, managers see dollars. Dignity for the worker, intelligence for the business.
No "please reconnect" screens. Sync reconciles silently. Basement ≡ full bars.
Task/issue/comment creation feels like a sticky note. Always returns to where you were.
Reporting inside a task never navigates away. Bottom sheet, submit, back to exact checkpoint.
The Manager home answers "is Unit 301 ready for 3pm?" before "what tasks exist?"
1000+ tasks, 100+ requirements-per-task, 500+ units. Search < 1 second. Speed doesn't change with scale.
Unlock from a task, reservation, property — never a detour to a separate screen.
No surveillance vibe. No leaderboards. Time tracking for payroll fairness. Completion celebrated, never judged. Spanish, Tagalog, French from day one.
Budget Android + tight data plan. <100ms taps. Photo compression. Virtualized 100-item lists. If it's great on Maria's phone, it's great everywhere.
Web and mobile share vocabulary, IA, and capabilities. Mobile is not web-lite. Density differs; meaning doesn't.
Click any decision to see the reasoning.
Home · Inbox · Tasks · Properties — identical across Tasker and Manager, with role-aware content inside each tab.
Why not different tabs per role? Cross-device parity (Principle 12). A Manager and Tasker looking over each other's shoulders see the same structure. James moving between desktop and mobile sees the same four tabs. Adding a 5th tab for Manager costs thumb-reach and cognitive load; everything extra fits as sub-views or modals inside the existing tabs.
Why not 3 tabs for Tasker? The Tasks tab is thin for Maria (she mostly uses Home), but keeping it preserves structural parity and gives her search + history access. Consistency > minimal.
Maria's #1 JTBD (T-1) is "see my day at a glance." A timeline shows the shape of the day — order, drive times, guest arrival urgency — which a flat task list or a priority feed can't do.
Why not a pure priority feed? Loses the "my whole day" gestalt that route-day cleaners rely on for break planning and time management.
Why not just a task list? Doesn't surface the most important contextual signal: guest arrival time relative to each task.
The Priority Strip (0-3 cards above the timeline) gives feed-like urgency signals without dominating the surface. It's empty and invisible when nothing needs attention.
The Manager's north-star question is "will my guests have ready units?" — that's an arrival-centric question. An arrival = one guest check-in on the selected day.
Why not tasks? A property might have 3 tasks (clean, inspect, maintenance) but one arrival. Counting tasks would triple-count the readiness question.
Why not properties? A property with no arrival today isn't relevant to the readiness pulse. Non-arrival work surfaces separately in the Critical Feed and Aggregate Batches.
The pulse label says "Today's arrivals · 14" explicitly to prevent ambiguity.
Validated finding: Managers plan in short horizons (typically 4 days) because reservations shift, staff calls out, and the schedule rewrites itself daily. Yesterday doesn't matter for the home — it lives in deeper navigation.
Why not today-only? Managers need to spot Thursday's staffing gap on Tuesday, not Thursday morning.
Why not a full week? 7 days of data at 100+ units is overwhelming. The 4-day window is the observed planning horizon from customer interviews.
An earlier design had Arrivals · Properties · Team · Map as four competing views on the Manager home. This was simplified to a single-purpose home (readiness over 4 days).
Why cut Map? For driving between units, Apple/Google Maps is one tap from a property card and works better (traffic, navigation, street view). A custom map is a significant engineering investment with uncertain ROI.
When does Map come back? If supervisors tell us "same-street clustering" (3 at-risk units on one block) is a real recurring pain that external maps can't solve, we'll re-evaluate for V2+.
"Who's working, who's overloaded" is a coordination question — you check it before reassigning, then go back to what you were doing. It doesn't warrant its own top-level tab competing with readiness for attention.
The "8 working →" link in the Home header opens a drawer: clocked-in, on-break, overloaded, with quick-reassign actions. Same data, smaller surface, preserves the home's single purpose.
Validated behavior: Taskers commonly do the physical work for a room, then click through and verify many items at once at the end. They don't check off items one-by-one during cleaning — they clean, then verify.
The Batch Verify Review screen lets them confirm "yes, I did all of this" in one pass before hitting Complete. Two actions: "Mark all verified" (fast path) or "Flag any" (per-item review).
This respects the real workflow instead of forcing per-item discipline that doesn't match how people actually clean.
Validated finding: "Ad-hoc items" (adding checklist items to a current task mid-execution) is not a common real-world behavior. When something unexpected happens, taskers reach for one of two paths:
Removing ad-hoc items simplifies the Execute surface and the data model without losing any real user need.
Principle 6: Report-and-return. Maria is mid-checklist (item 23 of 75) when she spots a broken tile. If reporting navigates her away, she loses her scroll position, her mental context, and has to hunt for where she was.
A bottom sheet slides over the current screen — the checklist stays behind it, dimmed but intact. After submitting, the sheet dismisses and she's on the exact item she was on. ~35 seconds total, zero context loss.
Departures (checkouts) are the upstream event that creates turnover pressure. Showing them lets the Manager:
Departures are not a peer to arrivals — they're a secondary section below the readiness board, collapsed into one summary card. Arrivals remain the primary pulse; departures are supporting context.
Validated finding: Supervisors look at their departments mainly. Marcos (Cleans supervisor) doesn't need to see maintenance tasks — they're noise that hides the cleaning-readiness signal.
The scope row defaults to the supervisor's department. James (org-level manager) sees "All departments" by default. Both can change the filter, but the default matches their actual job scope.
At 100+ units, showing every property's status creates a wall of cards that's impossible to scan. Exception-based display means:
Calm when nothing's wrong, detailed when something is. Scales from 5 to 500 units without redesigning.
Principle 3. Showing dollar amounts to the housekeeper cleaning a unit creates a surveillance/judgment dynamic: "this guest paid $400/night so clean better." It undermines dignity (Principle 10).
Instead, revenue signals drive sort order and priority badges that the tasker sees. A VIP guest's unit gets a "High priority" badge and sorts to the top — Maria does the right thing without knowing why it's prioritized. James sees the upsell values and dollar stakes because that's his job.