PropertyCard’s users were 40 to 75 years old, and most of them couldn’t find the home button.

PropertyCard · PRODUCT DESIGN · WEB · RESPONSIVE-FIRST

Neither could I, and I have a computer science degree.

An 8-month redesign of a property-management platform for landlords and tenants, rebuilt around three interaction rules and a 200+ component design system, so that people with zero technical background could manage their properties without ever feeling lost.

SNAPSHOT

Role

Product Designer — research, UX, visual design, prototyping

Team

Solo designer working with a team of 2 engineers

Timeline

8 months, 2021

Platform

Web, responsive-first

Status

The company later shut down. I’ve kept this case study honest about what that means for outcomes; see the end.

01 — What PropertyCard was

PropertyCard was a platform for landlords and tenants to display properties and manage the recurring monthly and yearly services attached to them. Property managers used it too, some handling large portfolios.

The problem wasn’t the idea. It was that when I joined, the existing design demanded real technical expertise just to navigate. Our actual users were homeowners and landlords between 40 and 75 years old, many of whom described themselves as uncomfortable with technology. The product was built for people who don’t exist and sold to people who couldn’t use it.

That gap became the design brief: a platform that requires almost zero technical ability.

02 — The evidence

Between my own audit of the product, watching people use it, and what the team knew from customers, the problems clustered into five:

03 — The constraint that made every decision

Designing for people with limited technical ability sounds like simplification. It’s actually constraint design: every screen has to answer “what can go wrong for someone who has never used software like this?”

Watching users interact with the product during testing, I kept seeing the same two failure patterns: people got overwhelmed by unfamiliar interaction types, and people panicked the moment they felt lost. So the redesign was built on three rules.

Rule 1: Only three interaction types exist

• Switches → for toggling
• Buttons → to navigate or trigger actions
• Forms → only when input is absolutely necessary

Everything a user encounters either flips, goes somewhere, or asks for something. These mimic real-life behavior — a light switch, a doorway, a paper form. No surprises, no novel widgets to learn.

Rule 2: Always a way back

One of the first things testing taught me: people panic when they feel lost. So every screen, every step, every click got a clear path backward. No dead ends. Clean, reversible flows that respect human error — because for a 70-year-old landlord, an unrecoverable mistake isn’t a UX flaw, it’s the reason they stop using the product.

Rule 3: Everything lives in cards

Each action opens a new card instead of replacing the whole screen. In testing, users responded strongly to this — the experience stayed modular and digestible, and users never lost the context of where they were. It also happened to fit the product’s name, which made the pattern easy for the whole team to rally around.

04 — The design system

The redesign wasn’t a facelift, it needed to hold up at scale. In 2021, the private rented sector accounted for 30.1% of all households in London, equating to over one million occupied dwellings, and a single property manager could be handling 40–200 properties. Whatever I built had to stay consistent across thousands of screens I would never personally design. (source: Trust for London)

So I built the system atomic-first: components at the bottom, patterns built upward, 200+ custom components by the end, every one of them encoding the three rules above, so consistency wasn’t a style guide anyone had to remember. It was the only way the tools worked.

Responsive was the other structural bet: start small, scale up, with auto layout doing the enforcement.

One component, anatomized

05 — Designing with a technical mindset

My Computer Science background influenced how I structured the work. I treated Figma components as behavioural systems rather than decorative assets. Auto Layout rules were designed to mirror frontend layout logic:

• Vertical and horizontal flow
• Content-based sizing
• Fill-container behaviour
• Consistent gaps
• Edge-to-edge media
• Row-level alignment
• Responsive reflow

The parent card remains tightly stacked. justify-content: space-between is used at the row level, where labels and values sit on opposite sides.

06 — What I couldn’t measure, and what I’d have measured

Here’s the honest part: the company shut down before the redesign’s impact could be measured over time, so I can’t show you a retention curve. I was only able to confirm my design choices by testing it out on fellow teammates, older family members, and friends — but they were not the target users, so those observations only speak to a certain extent to verify the need for change. What I can tell you:

• Users were able to complete most of the journeys, and when asked to retrace their steps, they did without getting lost or confused.
• Stakeholders approved the design change stating “Seeing the property, finally makes it feel real.”

If the product had lived, these problems gave me the scoreboard I’d have watched: onboarding completion rate (against “users quit halfway”), time-to-first-successful-task for new users (against the learning curve), and support contact volume (the cheapest proxy for “people feel lost”).

Knowing what you would have measured is the difference between decoration and design. I didn’t get the numbers. I know exactly which ones I wanted.

07 — Reflection

• If I did this again: I’d document research as I went. The original findings lived on a whiteboard in 2021 and were never written down properly — a mistake I haven’t repeated since. What survives is what mattered: every finding is still legible in the decisions it produced.
• I’d also test with actual target users earlier, instead of relying on proxies like teammates and family. And today, AI would let me analyze market data and user complaints before ever walking into an interview — better prepared, not replaced.
• What surprised me was how difficult it was designing for non-technical people. There are sections where it would be obvious for me, but when I needed a quick test, I would put the product in front of my dad and ask him to go through it — and he would get stuck. It helped me build the skill of putting myself in the user’s shoes.
• 5 years later, and unfortunately it seems that the website is no longer operational, as is the company. I left the company due to contractual differences but I do not regret it — my time there was fun, a constant move, working remotely was awesome, and the people I met were great! I hope that the company regains itself and the product launches again!

This project is where I fell in love with design systems, and looking at it now 5 years later, with the help of AI, a design system can be the base of an evolving product.