- PropTech
- Marketplace
- Research
Gidaly
One place to find, vet and close property deals in Nigeria
- Role
- Senior Product Designer
- Timeline
- 12-week delivery cycle
- Team
- Research, IA, interaction and visual system
- Platforms
- Web · Lagos, Abuja FCT, Kogi
- Status
- Designed and delivered
- Outcome
- Built against a ~40% cut in time-to-source, from client brief to shortlist. Target
The problem
Ask an agent in Lagos how they found the last property they sold and you get a story, not a search history. A cousin's WhatsApp group. A flyer. Someone who knows someone in Lekki. It works, in the way anything works when capable people absorb the cost of a broken system themselves. That cost is specific and everyone in the trade can name it: the three-hour drive to Ikorodu to inspect a property that sold a fortnight ago, the client asking for a floor plan nobody has, the same duplex listed by five agents at five prices with no way to tell which is real. Four problems feeding each other. No canonical record of what is actually available. Matching done from memory, then chat history, then contacts. Prices, dimensions and title status that cannot be verified until the fuel is already spent. And deals moving at the speed of whoever replies last, while nervous clients ring other agents.
What made it hard
- The thing to beat was WhatsApp. It is free, instant, already open on every phone, and it does not need a login. Anything slower or more ceremonious loses by default.
- Agents do not trust classifieds platforms, and Nigeria has plenty of them. Being another one was the failure case, not the benchmark.
- Two devices, two mindsets. Desktop for long sourcing sessions, mobile for checking status between viewings. Neither could be the stripped-down version of the other.
- Inventory quality sits outside the product. Developers and listers feed it, so the design had to make verification legible rather than assume the data was clean.
Three decisions
With what I turned down, and what each one cost.
Decision 01
A property is an object, not a post
- Chose
- A structured record: units available inside a complex, property age, exact geo-coordinates, developer verification status, pricing by unit type, document completeness.
- Rejected
- The classifieds model every competitor uses, where a listing is a photo, a price and a phone number.
- Why
- Everything worth having downstream depends on this and nothing else can substitute for it. Filtering by unit availability inside a complex, a verification badge that follows a developer across every listing they touch, a shareable brief that comes out as a finished document instead of a copy-paste job. A flat post cannot produce any of those, no matter how good the interface on top of it looks.
- What it cost
- It front-loads the work. The data model had to be argued through before anything could be designed, and it raises the bar for what a lister has to supply before their property is usable.
Decision 02
Signup with friction on purpose
- Chose
- A friction-balanced account flow: validation as you type, visible rigour from the first interaction, phone field defaulting to the NG country code.
- Rejected
- The conventional advice, which is to minimise signup friction and validate later.
- Why
- The entire pitch is trust, in a market that has been burned repeatedly. A signup that waves anyone through quietly contradicts that promise on the very first screen. Visible checks are the first evidence the product is what it claims. The NG default is a small thing that says this was built here, rather than localised afterwards from someone else's template.
- What it cost
- Measurably worse signup conversion than a frictionless form. That is a real trade and I would defend it, but it is a trade.
Decision 03
Exact prices, never rounded
- Chose
- The headline price rendered in full, ₦580,989,000.00, sitting beside area chips and the developer verification card.
- Rejected
- Rounded or abbreviated pricing, which is tidier and easier to lay out.
- Why
- In this market vagueness is what people do when they are hiding something. Precision reads as a trust signal before anyone consciously registers it. Putting price, size and legitimacy together means the three qualifying facts land in one glance, and an agent whose client fails on any of them moves on without scrolling. Their time is the whole product.
- What it cost
- Long numbers are awkward to set, and they break layouts at small breakpoints in a way rounded figures never would.
Decision 04
Filters that stay put, status you can read across a table
- Chose
- A table-first console with City, Property Type, Status and Cost filters persistent above it, and colour-coded Available / Sold / Deleted tags.
- Rejected
- Filters behind a modal and a card-based browse view, which photographs better.
- Why
- An admin running dozens of listings is not browsing, they are slicing, and they re-cut the same table continuously through a session. A modal charges them two extra clicks every time. The status tags are the hardest-working pixels in the product: state readable across a full table without opening anything is what turns a filing cabinet into something you open with your morning coffee.
- What it cost
- Persistent filters eat vertical space, which is expensive on smaller screens and forced a genuinely different mobile treatment rather than a reflow.
What I took away
Trust is not a feature and you cannot badge your way into it. The scepticism I met in interviews had been built out of dozens of small burns, a wrong price here, a dead listing there, and it only rebuilds the same way it broke: pricing precision, developer metadata, honest button labels, rigorous onboarding. Small doses, everywhere, constantly. The second thing was about devices. Agents work desktop for deep sourcing and mobile from the back of a keke between viewings, and those are different jobs rather than different screen sizes. Every dense view needed an honest answer to what must land in one glance and what earns a tap.