ZRUCHNO —
HOME SERVICES APP
Designing a trustworthy, low-friction way to hire help for everyday home tasks
A conceptual mobile marketplace for hiring help with everyday home tasks — cleaning, repairs, assembly, moving. I took it on as a solo, end-to-end project: from framing the problem to a complete, interactive mobile UI in Figma.
Overview
Zruchno is a conceptual mobile app for finding and hiring people to handle everyday household tasks — cleaning, small repairs, furniture assembly, moving, and more. The idea is simple: describe what you need, compare a few trusted people, and book — without scrolling through group chats, asking around, or gambling on a stranger.
It started as a self-directed project, but I treated it as a real product. I owned the entire process from problem framing to a complete, clickable mobile UI. It was never built — the value was in running a full UX cycle on my own, and in designing for a problem where trust matters as much as the interface.
Getting in — a lightweight phone-number sign-in that keeps the first-time barrier low
My Role
Sole UX/UI designer across the whole concept. I took it from a problem statement to a finished, clickable Figma prototype.
Framed the problem and defined the product's scope and modules
Mapped the information architecture and the core user flows
Designed low-fidelity wireframes, then the full mobile UI in Figma
Built the interface on an adapted Untitled UI foundation, with a custom brand
The challenge
Hiring help for your home isn't a normal e-commerce transaction. You're letting a stranger into your space, often on short notice, to do something you can't or don't want to do yourself. That raises the stakes on two things at once: trust and speed.
Designing for trust in a high-stakes transaction
The hardest part isn't the booking mechanics — it's making someone feel safe enough to book at all. The usual options (group chats, classified ads, word-of-mouth) are slow and give you almost nothing to judge a person on. The product had to surface enough signal — ratings, reviews, clear profiles — for a user to choose with confidence.
Reducing friction without losing context
At the same time, the person hiring doesn't want to fill out a long form, and the tasker needs enough detail to arrive prepared. Balancing those two — minimal effort for the user, enough context for the tasker — shaped the entire task-creation flow.
Zruchno was a self-directed concept with no client and no access to real users. Rather than claim research I didn't do, I treated it as a design-hypothesis exercise: I studied how established marketplaces like TaskRabbit structure categories and build trust, formed clear assumptions about what would make a user feel safe and move quickly, and designed against those assumptions. The honest constraint — and the useful lesson — was learning to make defensible product decisions on my own, and to stay clear about which were grounded in established patterns and which were bets.
What I Did
Information Architecture
Before any UI, I defined the product's structure: how someone gets in, creates a task, and then lives with the app afterward. I split it into five areas — onboarding, the home/discovery screen, task creation, communication, and task management — plus settings.
The key structural idea was that Zruchno has two distinct modes: a focused, one-time flow for creating a task, and an ongoing space for managing the tasks you already have. Keeping those separate in the architecture is what later justified the bottom navigation.
Product structure — a one-time task-creation flow alongside an ongoing space for managing existing tasks
The Home Screen
The home screen is the entry point for every new task. It combines a search bar, a row of category pills, and rich category cards — each with an image, an icon, a few subcategories, and a "View all".
I gave users two ways into the same content. The category pills act as anchor links that jump straight to a section for people who already know what they need, while the cards invite scrolling for people who don't. Search works across both categories and subcategories — so a query like "painting" surfaces the right place even if the user doesn't know which top-level category it lives under.
Home screen — category pills as quick anchors, rich cards for browsing, and search across categories and subcategories
Task Creation: a Guided 4-Step Flow
Instead of one long, intimidating form, task creation is broken into four sequential steps, each with a single focus and a clear "Step X / 4" indicator:
Step 1 — Address, task name, a short description, and optional photos or videos. This gives the tasker context before timing or price enters the picture.
Step 2 — Task scope simplified to three sizes (Small / Medium / Large), plus date and time, with an "I'm flexible" option for users open to alternatives.
Step 3 — Choosing a tasker (covered below).
Step 4 — A full review of the task — details, scope, time, and chosen tasker — before payment.
One decision per screen. Splitting the form this way keeps each step short and removes the "wall of fields" feeling, while the progress indicator tells users exactly how much is left. It also mirrors how the task naturally forms — what, when, who, confirm — so the sequence feels like thinking through the job rather than filling out paperwork.
A four-step flow — what, when, who, confirm — each step focused on a single decision
Building Trust into Tasker Selection
Step 3 is where the product's core problem lives. Users see a list of tasker cards, each carrying the signals that matter for a trust decision: rating, number of reviews, completed tasks, hourly rate, and plain-language badges like "Top Choice", "Good Deal", and "2 Hour Min". They can sort and filter (Recommended, Price, Rating) to narrow the list, and tapping a card opens a full profile with an extended bio, skills, and the complete review history.
For this product, the trust signals aren't decoration — they are the product. A raw 4.4 rating means little on its own; a "Top Choice" badge with a one-line explanation does the interpreting for the user. The goal was to let someone compare three or four credible people and feel confident — instead of either checking everything obsessively or booking blindly. The card carries just enough to decide; the profile is there when they want to dig deeper.
Tasker selection — cards surface trust signals at a glance; the full profile is one tap away for a closer look
Supporting Everyday Use
A marketplace isn't just the first booking — it's everything after. I designed a bottom navigation with four tabs (Home, Chat, Tasks, Settings) to support the product as a recurring tool, not a one-time flow.
Chat keeps each conversation scoped to a specific task, with a safety note nudging users to keep communication in-app.
Tasks lists active and past jobs with clear statuses (In progress, Completed, Canceled), and lets users add hours, confirm completion, or cancel from the detail view.
Once a task is done, the user leaves a rating and a review.
I designed the whole task lifecycle, not just the happy path — how a task gets confirmed, how an extra hour gets paid, how it's completed and reviewed. The review step also closes a loop: the ratings and reviews a user leaves here are exactly the trust signals the next user relies on when choosing a tasker. Designing both ends of that loop made trust feel like a system rather than a set of disconnected screens.
Beyond the first booking — scoped chat, task statuses, and a review step that feeds the next user's trust decision
Design Foundation
I built the UI on Untitled UI, adapted to a custom Zruchno brand — a warm orange identity with a friendly script logo — and a consistent mobile component set. Using an established kit as a base let me move quickly and keep the visual layer clean, so the design effort went into flows, states, and the trust model rather than reinventing buttons and inputs.
Built on an adapted Untitled UI foundation with a custom brand, keeping the focus on flows and states
Reflections
Zruchno is the one project in my portfolio I designed entirely on my own initiative, with no client and no brief — which made it the clearest test of whether I could run a full product process solo. I framed the problem, structured the app, and designed every screen and state from the first wireframe to a clickable prototype.
The most useful lesson was designing around trust rather than just usability. Most of my work is on B2B tools where the user has already committed to the product; here, the entire challenge was earning a decision from someone who had every reason to hesitate. That pushed me to think in terms of signals, transparency, and the full lifecycle of a transaction — not just whether a screen was easy to use, but whether it made a person feel safe enough to act.
As a concept, it also taught me to be honest about the line between what's grounded in real patterns and what's an assumption — and to make decisions confidently on the assumption side while staying clear-eyed that that's what they are.
