Plot.gr v2

Reframing the brief

There was no research to inherit, so I triangulated across four sources.

Behavioural: Microsoft Clarity heatmaps and session recordings on the live site, which located where attention stalled. Quantitative: GA4, which confirmed the decline was specific rather than general. Qualitative: support tickets, and the sales team — who speak to agents every week and were carrying the same requests over and over. Sales is an underused research channel; they had the demand signal months before design did. Competitive: Spitogatos, XE.gr and the rest of the category, looking for professional tooling we did not offer.

The research was directional rather than rigorous. It told me where to look and what agents were asking for; it did not let me rank problems by severity. So I framed the redesign around structural failures I could observe and defend directly.

Then I mapped what actually had to exist, and the shape of the problem changed.

The listing page is not one page. It is a sale listing, a long-term rental, a short-term rental priced by night, and a wanted listing — each shown differently to an anonymous visitor, a signed-in user and the listing's owner, across desktop, mobile web and app. The panel is not one page either: thirteen sections, two account tiers, three platforms.

That is a combinatorial problem, not a visual one. You cannot style your way through it, and two designers cannot hand-build every permutation in fourteen weeks. Plot.gr was a classifieds site that professionals were using as software, and the redesign had to make it software — which is why the design system stopped being a nice-to-have and became the delivery mechanism.

From a map that counts to a map that shows

The results page paired a list with a map of the entire country, marked with cluster bubbles reading 90,633 and 51,366. The two views were not coupled: scrolling the list did not narrow the map, and panning the map did not filter the list.

The clearest evidence was a button in the toolbar labelled Freeze list. Someone had shipped a control whose only purpose was to stop the two views fighting each other. A freeze button is not a feature — it is a symptom.

I rebuilt the map around the question people actually arrive with: not how many properties exist, but what can I get here, and where exactly is here. Pins carry prices instead of counts, so comparison happens at a glance. The search area is drawn as an editable boundary, and users can draw their own — because the boundary that matters is a school catchment or a commute, not an administrative district. Where map and list do diverge, the page now says so and offers a way back.

Filters got the same treatment. Price had not been in the primary row — on a property site — and nothing showed which filters were active. Price and area moved up, active filters carry a count, and the filter set varies by category: land, homes, commercial and short-term rentals ask different questions. Five sets are only maintainable because they share one shell and one component library.

From two hierarchies to one

The professional panel ran two competing navigation systems at once. Sixteen items sat flat in a sidebar — Favourites beside API, Saved searches beside Subscription — and one of them, Account, opened a page with four tabs of its own.

The cost was not aesthetic. Billing had been split across both levels: invoice details and payments lived two clicks deep inside Account, while subscription and credits sat at the top. An agent asking where do I pay had three places to check, two of them behind a page they had no reason to open. With no rule for what became a sidebar item and what became a tab, there was no way to learn the system — only to search it.

I removed the tabs and gave the sidebar one level of nesting. The commercial functions moved into one family, and invoices and payments merged, because they were one job wearing two names.

The account page had the same problem in miniature: private administration mixed with public marketing in a single form, where an agent could not tell which fields their clients would see. It became three named cards, each with its own save scope.

The same structure serves both tiers. A private seller sees the account essentials; a professional agent sees the full set. One shell, capability as the variable — which makes the upgrade path legible rather than hypothetical.

What I got wrong, and what I would change

Early on I tried pulling an agent's own listings onto the homepage as a feed. It was faster for them, and I dropped it: it would have made the panel optional, and everything an agent pays for lives there — renewals, promotions, credits, statistics, the request inboxes. I had optimised the fastest path through one task without seeing what that path removed. The instinct survived in a narrower form: an agent who finds their own listing in search results can act on it there, which is a shortcut for something already in front of them rather than a second place to work.

The bulk import tool shipped unchanged from v1. In a redesign premised on treating agents as professional users, leaving one of their heaviest tools untouched is the compromise I would revisit first.

I would also have run usability sessions with agents before locking the panel architecture rather than after. The structural argument was sound, but sound is not the same as tested.