Modern Care Homes

Two people, one search

Modern Care Homes is a senior living platform for the Phoenix metro. Families search independent living and assisted living homes across Phoenix, Scottsdale, Peoria, Paradise Valley, Queen Creek and Surprise, compare what they find, and contact a home directly.

What makes it a hard design problem is that two pretty different people use it for the same task. There's the resident, usually over 70, on a tablet or a desktop with the browser zoomed way in, trying to figure out whether a place looks like somewhere they could actually live. And there's their adult child, on a phone, often in the middle of something stressful, trying to compare six homes and find cost and care level fast.

They don't have much in common except that neither one has any patience for an interface that gets in the way. Pretty much every decision I've made on this project comes back to that.

There's a second product behind the public site, which is the platform agents use to manage their listings. That matters more than it sounds like it should, because the same components run in both places. A change to a button is a change in two products, and the design system has to be good enough to survive that.

Three rules I work from

Design it, then build it

I'm the design engineer here, which means I do the design and then I build the front end of it. Four things, roughly in order. Work out what the problem actually is, design the interfaces, turn whatever survives into a system, then ship it.

Research and strategy

Senior living is a marketplace problem before it's a healthcare one. That framing decides a lot, because it means the products worth studying aren't other care sites. They're the marketplaces that already spent years and a lot of money on search, comparison and listing quality.

• Pattern research. I spend a lot of time in Mobbin pulling apart how real estate marketplaces handle search and discovery. Filters, result density, map and list views, saved comparisons, what a card shows at a glance.
• The same thing for the agent side. Getting a home listed is a long form with photos, pricing and details, and the closest good version of that problem is Airbnb's listing creation flow. I pulled it apart screen by screen and mapped what someone is doing, seeing and thinking at each stage, then marked what works and where the openings are. It's a teardown I keep coming back to, because listing creation is the same problem in every marketplace I work on.
• What transfers and what doesn't. Most of what those products landed on carries over. Some of it doesn't, because our filters are care levels rather than bedrooms and bathrooms, and the person deciding often isn't the person moving in.
• Where the effort goes. The core flow is search, then compare, then contact. Compare is where people actually get stuck, so that's where the work goes.

Designing the interfaces

Two kinds of design sit next to each other here and they don't always want the same thing. Product design decides whether someone can finish what they came to do. Web design decides whether they trust the place enough to keep going. This one needs both.

Product design

• What a listing shows and in what order. Care level, setting, cost, what's included. A family is mostly trying to rule homes out, and I'd rather help them do that quickly than pad the page.
• Content design. Senior living has a lot of jargon and most families are learning it while they shop. Independent living, assisted living, levels of care. If the words on the page assume you already know the difference, the page failed.
• The unglamorous states. Filters, no results, and listings that don't have every field filled in. Those are most of the real sessions and none of the pretty screenshots.

BeforeFull sizeAfterFull size

Web design

• Brand and visual direction. Type scale, color, and the layout and photography language that makes a directory feel like a place instead of a spreadsheet.
• Page design across pretty different jobs. Marketing pages get to be expressive. Search results have to get out of the way. The editorial side with the posts and resources sits somewhere in between.
• Responsive behavior. This gets used on a phone in a parking lot and on a desktop at 200% zoom, so a layout that only works at one size isn't done.
• Pacing. How much a page gives you before you have to scroll, and what earns the top of it.

BeforeFull sizeAfterFull size

Building the design system

Every interface above has to survive being used twice, once on the marketplace and once in the agent platform. That's the job the system does.

• Tokens, foundations, components. Foundations are locked. Components are still in progress and I'm publishing them as they get done.
• The accessibility floor lives in the components rather than in a checklist. 18px base type, 48 by 48 targets, AA contrast as the minimum. Baked into the component, I can't accidentally undo it on page eleven.
• Storybook, which is where components get built and argued with before they go anywhere near a page. I can put a component in every state it has, at every size, at 200% zoom, and see it fail on its own instead of finding out inside a layout.
• The two-product test. Storybook is also how I know a component is ready for both the marketplace and the agent platform, because I can look at it outside of either one. A change to a button is a change in two products.

Shipping the front end

I build what I design, which is the part that removes the most steps.

• Components, layout, responsive behavior and motion all ship as code from me instead of as a spec I hand to someone else.
• Accessibility gets verified on the real build. Contrast, focus order, keyboard paths, zoom and target sizes, because a mockup can't tell you what happens at 200 percent.
• Whatever I learn shipping goes back into the system, so the next screen starts further along than the last one did.

The part I like most is that I never have to defend any of it in a handoff meeting. If something needs to change, I go change it.

Collaboration

I build this with Spencer Grzincich, the Software Engineer on the project.

He owns the data layer and the infrastructure. How home data gets modeled, stored and served, the integrations, and everything that has to stay up. I own everything a family or agent sees and interacts with.

The stack

Tool	Layer	Why
Next.js	Framework	Server rendering, because a lot of this traffic is a phone on cell service. Typed routes help as the directory grows.
React TypeScript	UI	TypeScript catches the things I'd otherwise find in the browser.
Tailwind CSS	Styling	Tokens live as CSS variables, so a system change is one edit instead of forty.
shadcn/ui	Components	I own the source instead of importing it, so when I need to fix an accessibility issue I fix it inside the component.
Figma	Design	Where foundations and components live. Tokens map one to one with the CSS variables.
Storybook	Components	Where components get built and tested in isolation, in every state, before they land in either product.
Vercel	Deployment	A preview build per branch, so I can look at a change on a real phone before it merges.
GitHub	Version control	Where the design and the code actually meet.
Mobbin	Research	Search and discovery patterns from real estate marketplaces, which are further along on this problem than senior living is.
	Analytics	Events and funnels for the search, compare, contact flow, so I can see where families actually stop. Session replay for the part the numbers only hint at.
Spencer's side	Data and infrastructure	Home data, integrations, and everything that has to stay up.

What's next

• Publishing the component library once the foundations settle.
• Better comparison. Cost and care level side by side is the decision families are actually making, and it isn't solved yet.
• More editorial. The resources and posts answer the questions people have before they're ready to tour.