What I did

Research & User Insights

To understand whether and how this marketplace could actually work, I ran surveys and one-on-one interviews with potential sellers and buyers, and spent a day observing a food truck owner's real working routine to see where friction showed up in practice, not just in theory. That research fed empathy maps and four user personas, giving the team a shared, evidence-based picture of who we were designing for instead of relying on assumption.

Visual Language & Design System

I built Sapi's visual identity and UI kit from scratch — color system, typography, and a custom illustration style developed through several rounds of client feedback — giving the product a warm, community-first feel distinct from a typical marketplace app. Treating this as a system rather than one-off screens meant new features could be designed consistently as the product grew beyond its first release.

Prototyping, Testing & Dev Handoff

I translated research findings into a clickable Figma prototype and ran usability testing sessions to validate direction before development began, documenting findings in usability reports that shaped revisions ahead of build. I worked closely with the startup owner and dev team throughout — running story-mapping sessions to define what belonged in the first release versus later phases — and delivered development-ready screens grounded in what testing had actually validated, rather than untested assumptions.

Sapi is a community marketplace connecting home cooks and local food sellers with neighbors looking to buy homemade meals — an idea validated only by the founder's conviction, not yet by real user evidence. Before a single screen could be designed, the product needed proof: who would actually sell food this way, who would trust buying from a stranger's kitchen, and what it would take for either side to commit.

I joined at the earliest stage, working directly with the startup owner, Head of Marketing, and Head of Dev team to take Sapi from an unvalidated concept to a research-backed, development-ready product for its first release.

The client's initial request was for the property card to surface everything at once — photos, price, map context, and agent details — all visible without scrolling. The challenge was that property listings carry a lot of inherent complexity: building details, full descriptions, and supporting information that simply don't compress into a single viewport without either shrinking everything to illegibility or overwhelming the user on first glance.

Rather than forcing every field into view, I proposed prioritizing information by what users actually need to make an initial decision — photos, price, and location — and treating the rest as content worth a deliberate scroll rather than a compromise. I walked the client through the trade-off directly: cramming everything above the fold would hurt readability for the fields that mattered most, while a short scroll preserved clarity without hiding anything. That reasoning was enough to move the design forward with a prioritized layout instead of a single dense screen.

Information hierarchy on the property card

The client's initial direction was for the map to be the dominant, full-screen element, with users drawing a search area and individual properties only appearing after clicking a specific point — treating the map as the platform's standout feature. I pushed back on the premise that this needed to be a unique differentiator at all; map-based search with a drawable radius is a pattern most real estate platforms already use, so the goal wasn't to invent something new but to make an already-familiar interaction as convenient as possible.

I proposed a layout where property cards sit in a narrower column alongside a larger map, rather than behind it — users draw or adjust their search area, and the listings update automatically in the same view, with no click required to reveal a property. This kept the interaction aligned with what users already expect from map-based search elsewhere, while removing the extra step the client's original version would have required.

Map and listings layout

Supporting four languages meant more than translating text — Hebrew's right-to-left reading direction required the entire layout to mirror, not just the copy. In the English version, for example, property cards sat on the left with supporting content on the right; in Hebrew, that whole structure needed to flip so the layout read naturally in the opposite direction.

The difficulty was less about translation and more about making sure every component — cards, filters, navigation, map controls — had a defined mirrored state, so the product felt native in Hebrew rather than like an English layout awkwardly reversed. I addressed this by building RTL support into the design system itself rather than handling it case-by-case per screen, so each new component came with both directions defined from the start, keeping the experience consistent as the product expanded across languages.

Layout mirroring for Hebrew (RTL)

Simplifying the Header and Hero Section

To validate assumptions about the existing homepage, I ran a set of five short interviews with potential agents and users, focused specifically on first-screen impressions. Several findings came out consistently: the header's two-row structure — informational links like Help, Professionals, and Articles stacked above core navigation — was described as confusing, with participants unsure where to look first. The bright green CTA button was called out as overly dominant, with its white label difficult to read clearly against it.

Participants also flagged that the hero headline, "Discover a place you'll love to live," was hard to read against the background photo, a contrast issue that undercut the first impression the page was meant to create. On top of these findings, the four-option search switcher (Buy, Rent, New Homes, Commercial) asked users to commit to a category before they'd even begun browsing, adding friction to the platform's main entry point.

Older Version

Solution

I collapsed the two navigation rows into a single header, moving lower-priority links like Help, Articles, and Contact Us into the footer, where they remained accessible without competing for attention at first glance. I replaced the hero background image specifically to restore contrast against the white headline text, so legibility no longer depended on which photo happened to be live.

Search was reduced to the two highest-intent actions, Buy and Rent, with New Homes and Commercial moved into on-page filters rather than removed — preserving the same options while cutting the upfront decision users faced before searching at all. I also rebalanced the header's call-to-action hierarchy: the previous version used a bright green button for account actions, which visually outweighed everything else on the page.

Since OnMap's priority audience for registration was agents rather than casual browsers, I redesigned "Publish Property" as a white button against the dark header — giving it visual weight — while keeping Register and Sign In deliberately quieter, since those served users who were just browsing rather than the agents the platform most needed to convert.

Before

After

Mobile / Tablet Design

Over 75% of OnMap's traffic came from mobile devices, but agent behavior split differently — around 65% of agents published listings from desktop or tablet rather than mobile. That split shaped several decisions rather than a single uniform scale-down. The filter panel, shown as a row of buttons above the listings on desktop, collapsed into a condensed control on mobile to preserve space for the content users actually came for. Map and listings, shown side-by-side on desktop, couldn't hold that layout on a mobile screen — instead, users toggle between a full-screen map and a full-screen list view, rather than viewing both at once.

Publishing a property also differed by device: since most agents were already publishing from desktop or tablet, I kept the mobile publishing flow fully functional but didn't over-invest in optimizing it as the primary path, prioritizing design and testing effort on the desktop flow where agent activity actually concentrated.

The visual refresh needed a foundation that could scale — four languages, two writing directions, and both web and native apps meant screen-by-screen styling wasn't sustainable. I built the design system from the ground up in Figma, using color and typography as tokens rather than hardcoded values, so that changes to the core palette or type scale propagated consistently rather than requiring manual updates across every screen. RTL support was built into the system itself — components had defined mirrored states from the start — rather than handled as a one-off fix per screen, which is what let the four-language requirement scale without ballooning into constant rework as new screens were added.

Design System

Spacing

Colors

Bringing the system together

The redesign touched dozens of screens across search, listings, filtering, publishing, and account flows — the pages below are a small sample, not the full scope. The homepage applies the simplified header and hierarchy decisions directly; the listing feed and property detail page carry the same information priority logic worked out earlier, now applied at full content density with real photos, pricing, and agent details. The publish flow's starting screen reflects a different design problem entirely — built for agents rather than casual browsers, it prioritizes clarity and speed for a user who lists properties repeatedly, not someone browsing once.

After launch, average session duration grew from around 28 seconds to roughly 1 minute 43 seconds — a sign users were browsing rather than bouncing. The product manager also reported a drop in support tickets tied to navigation and search confusion, and agent activity grew alongside this, with more agents choosing to list on OnMap in addition to competing platforms — a meaningful trust signal in a market where agents are selective about where they invest listing effort. Traffic also rose over this period, though some of that likely reflects SEO and organic search gains rather than the redesign alone.

Outcome

What Was Done

This project combined a brand refresh with a full product redesign — rebuilding the design system from the ground up with tokens rather than hardcoded values, so a four-language, RTL-inclusive product could scale without constant screen-by-screen rework. Beyond the visual system, key decisions like prioritizing scrollable hierarchy over cramming every field above the fold, combining map and listings into a single view, and building agent-specific flows for desktop reflected a recurring pattern: choosing what a real user needed over what looked most impressive at first glance.

What Could Be Improved

With more time, I'd want proper before/after instrumentation in place from day one — session duration and ticket volume told a clear story here, but a lot of the reasoning during the project relied on qualitative interviews and judgment rather than structured A/B data. I'd also want to validate the RTL and multilingual system with real Russian and French-speaking users specifically, since most of the direct research happened with Hebrew and English speakers.

Brand Feel

OnMap's brand needed to read as credible as Israel's largest real estate platforms, without losing the approachability that built its early user base.

Logo

Colors

In a product people use daily to browse, compare, and contact sellers, color isn't decorative — it's how users tell primary actions from secondary information at a glance. The system stays deliberately small: one accent color earns all the attention, and three neutrals do the rest.