Domus
Domus is a home-services marketplace concept for Honduras designed to make an informal service economy more trustworthy and legible. I led UX and UI for the MVP across client, technician, and admin experiences, shaping the marketplace model, trust signals, and core transactional flows.
Project Type
Mobile App MVP
Role
Product Designer
Timeline
Sept. 2025 — Nov. 2025
Tools
Figma, Material Design 3
Scope
UX Research, Wireframing, Prototyping, Visual Design
Client
Domus
The Problem
In Honduras, home-service transactions often happen through referrals, social posts, and chat threads, where trust is personal, pricing is inconsistent, and accountability is weak.
Challenges Identified
- No reliable way to verify technicians
- No structured job or payment tracking
- Heavy reliance on informal communication
Opportunity
Build a trusted transaction layer for the market: a mobile marketplace that helps clients evaluate verified technicians, compare offers, and move through the full job flow with more transparency, structure, and confidence.
Business Objectives & MVP Goals
The MVP was designed to test real demand for verified home services in Honduras and whether a pull marketplace could sustain qualified activity.
Success was defined by marketplace behavior, not interest alone: real requests created, technician responses, and jobs reaching completion and payment. The early metrics focused on liquidity, response time, and conversion through the full transaction.
Core MVP Objectives
Confirm user understanding of request and selection flow
Evaluate technician willingness to use the platform
Identify friction points in the experience for both roles
Gather performance metrics to support the development of version 1.0
Success Metrics
Number of real requests created
Percentage of requests receiving at least one technician bid
Average time from request creation to technician assignment
Percentage of completed and paid services
Key User Insights
The strongest signals were behavioral. These patterns shaped how the marketplace needed to handle trust, flexibility, and structure.
Client perspective
What mattered most when asking someone to enter the home
Trust mattered more than getting the lowest price for in-home services.
People were comfortable coordinating through chat, but not without clearer structure and accountability.
Clear scope, timing, and pricing reduced hesitation before inviting someone into the home.
Technician perspective
What made the marketplace worth participating in
Technicians wanted to assess scope before committing, which made flexibility essential.
WhatsApp and Facebook made lightweight communication familiar, but not reliable at scale.
Negotiation was standard, making rigid fixed pricing a weak fit for the MVP.
Competitive Research
I focused less on individual brands and more on the service models behind them: how control, trust, speed, and complexity shape the experience.
Local
Pull Marketplace
Betty, Te Conecto
- Clients post requests
- Technicians submit offers
- Client chooses technician
Strength
High control and trust
Weakness
Slower response time
Assigned model
Push / On-demand
Kompa
- Client submits request
- System assigns technician automatically
- No comparison step
Strength
Speed and simplicity
Weakness
Low control and transparency
Global references
Hybrid / Mature Systems
Thumbtack, TaskRabbit
- Strong technician profiles and reviews
- Integrated chat, scheduling, and payments
- Structured but flexible flows
Strength
Trust and system completeness
Weakness
Higher complexity
Control
Pull models give clients more control over who they hire.
Speed
Push systems resolve requests faster, often with less transparency.
Trust
Verification, profiles, and workflow structure shaped confidence more than price alone.
Complexity
Mature systems earn trust through completeness, but can be heavy for an MVP.
Distilled Signals
Key Insights
- Trust is the primary barrier when allowing someone into the home.
- Pull models increase confidence, but often slow down resolution.
- Push models optimize for urgency, but reduce perceived control.
- Local platforms still lack strong, visible verification systems.
- Global platforms differentiate through trust systems and structured workflows.
Positioning Outcome
How This Shaped Domus
- Preserve client control at the most trust-sensitive moment.
- Keep request creation light enough to protect response time.
- Make trust visible through verification and workflow structure.
Product Decisions
A few product choices shaped the MVP more than any visual decision.
Pull model over instant booking
Letting clients post requests and technicians apply fit variable scope, pricing, and availability better than instant booking.
Trust as a core mechanism
Verification, job structure, and offer comparison were treated as core product mechanisms.
Flexible pricing over fixed rates
Because negotiation is common, the MVP supported technician choice and client comparison instead of forcing fixed pricing.
Liquidity and response-time risk
The model depended on technicians responding fast enough to keep requests viable, making liquidity and response time core risks.
User Flows & Journeys
These flows framed the core marketplace logic: clients create demand, technicians respond selectively, and jobs move through a clear status model.
Request Creation Flow
Lightweight up front, with enough detail to drive qualified responses.
Select Category
Define Service Scope
Add Details
Schedule Service
Confirm Location
Review Summary
Publish Request
Technician Bidding Flow
Preserves technician choice so providers can assess fit before committing.
Browse Jobs
Review Job Details
Submit Offer
Wait for Selection
Get Assigned
Job Lifecycle
Keeps job status legible once a request moves into execution.
Open
Assigned
In Progress
Completed
Closed
Wireframes
Wireframes were used to validate the core exchange: request creation, offer comparison, and coordination clarity.
Design System
Using Material Theme Builder, I created a Domus-branded system, local component library, and tokens that kept the MVP accessible, consistent, and lightweight across client, technician, and admin roles.
Design Approach
Given the MVP scope and market context, the design strategy prioritized clarity, speed, and reliability over visual complexity. Material Design 3 provided a consistent, accessible foundation so the product could stay focused on validating core workflows first without unnecessary design or development overhead.
Previews
Interactive Flows
These flows represent the three core workflows in the MVP: creating demand, responding to demand, and operational trust review.
Client
Creating a Job Request
Shows how request creation stays light while capturing enough detail for qualified responses.
Technician
Finding and Applying to a Job Request
Shows how technicians browse open requests, review details, and apply selectively.
Admin
Approving a Verification Request
Shows how trust is operationalized through technician verification review.
Reflection
Domus strengthened my ability to design for marketplace behavior, not just a linear app flow. The core challenge was balancing trust, flexibility, and operational clarity across both sides of the exchange.
It also reinforced the value of lean execution under real constraints: quality came from focus, not excess. If the product moved forward, the next priorities would be response-time reliability, technician adoption, and stronger handling for disputes, no-shows, and deeper verification.