All work

CASE STUDY — 03

Hominex

A multi-market real-estate platform for consumers, agents, and developers — designed end-to-end, from first flow to shipped interface.

Role

Product Designer

Timeline

Apr 2025 – Sep 2026

Location

Bojnurd, Iran

Platform

Responsive web app

01 — OVERVIEW

What it is.

Hominex is a real-estate platform built around a simple idea: a city is a market. Consumers browse properties, agents manage listings and follow-ups, developers present projects — three user types, one product.

I own product design end-to-end: user flows, information architecture, interaction design, responsive interfaces, and handoff to engineering.

02 — CHALLENGE

One product, three jobs to be done.

A consumer wants to browse and compare. An agent lives in listings, customers, and follow-ups. A developer needs to present projects across cities. Each has a different goal, a different rhythm, a different definition of done.

The challenge: one coherent product that never feels like three apps glued together — plus data-heavy forms, dozens of them, that had to stay usable at scale without turning into a chore.

03 — PROCESS

How it was designed.

/ 01

Understand

Map each user type’s core loop before drawing a single screen — what does “done” look like for a consumer, an agent, a developer?

/ 02

Define

Turn loops into flows and information architecture: what lives where, what connects to what, and what stays out.

/ 03

Systemize

Build the design system first — foundations, typography, buttons, form components — so every screen speaks the same language.

/ 04

Design & hand off

High-fidelity UI, responsive behavior, implementation-ready handoff — then iterate with engineering as it ships.

04 — KEY DECISIONS

Decisions, not screens.

DECISION 01

Markets, not a hierarchy

Cities became markets instead of Hominex → City → Everything. Each market gets its own discovery hub; properties, agents, and projects attach to markets independently. The IA scales city by city without restructuring.

DECISION 02

System before screens

Foundations, type scale, buttons, and form components came before any feature screen. New features now compose from existing patterns instead of inventing new ones each time.

DECISION 03

One form language

30+ complex, data-heavy forms share a single pattern library — consistent structure, validation, and error handling. Complex input stays learnable because it always behaves the same way.

05 — SELECTED SCREENS

The work.

Screen placeholder
Marketplace discovery
Screen placeholder
Agent workspace
Screen placeholder
Property detail
Screen placeholder
Design system — form components

06 — OUTCOMES

What changed.

Shipped product

In active development, designed end-to-end and handed off implementation-ready.

Design system

Foundations, typography, buttons, and form patterns adopted across features.

30+ forms, one pattern

Complex data entry unified into a single consistent form language.

Metric placeholders — replace with real numbers when available
(e.g. task completion time, adoption, conversion).

07 — REFLECTION

What it taught me.

Draft — write this in your own voice: the one thing this project taught you about designing products.

NEXT CASE STUDY

Gaaraazh

A niche e-commerce for spark plugs — finder-first product discovery, SEO strategy, WordPress build.