How I decide what a feature should actually look like

Watching the table, not just looking at it

I was working on a B2B SaaS product called 1nHealth. Like most B2B SaaS products, it had a leads table—filterable, sortable, all the standard data-table conventions you’d expect. Nothing about it looked wrong. It looked like every other SaaS table I’d ever seen, because it was built the way SaaS tables are usually built.

Then I watched the head of recruitment actually use it.

He was trying to show me how he follows up with leads—which is, in theory, the entire job this part of the product exists to do. And I watched him click into a lead, then click again to get to messaging, then again, then again—four clicks deep, a whole new page load, before he could actually see or send a message. To manage this, he’d started opening multiple tabs at once, one per lead, so he could bounce between conversations without re-navigating the table each time. It saved him clicks. It also occasionally froze his computer.

That’s the moment the table stopped looking fine to me. Not because it was ugly or badly built—it was neither. It was because I was watching a real workflow fight the software that was supposed to support it. The feature’s job was to help someone follow up with leads. What it was actually doing was making him build his own workaround, tab by tab, to get back to something close to that job.

Getting to the actual job

The standard move here would have been to make the existing table faster—fewer clicks, a slide-out panel instead of a new page, that kind of incremental fix. That’s not wrong, exactly. But I don’t think it gets at what was actually happening.

What he needed wasn’t a faster version of a data table. He needed something closer to a messaging inbox—because that’s what the job actually was. He wasn’t managing rows of lead data. He was having ongoing, threaded conversations with a list of people, over time, and needing to move between those conversations quickly. That’s not a data-table problem. That’s a messaging-app problem wearing a data-table costume.

Once I saw it that way, the shape became obvious: something closer to how iMessage or iCloud Mail handles it—a list of leads on the left, the full thread for whoever’s selected on the right, always one click away, no new page load, no new tab. Not because messaging apps are trendy, but because the underlying job—track an ongoing conversation with someone, switch between conversations fast—is the same job a messaging app is built to do. The form followed the function once I stopped assuming the function had to look like everything else in that category of software.

This is part of why I think having a wide reference library matters, even for engineering-flavored decisions—the pattern I reached for didn’t come from another SaaS product. It came from noticing that the actual job matched a completely different kind of interface than the one everyone defaults to for that category.

What it took to get there

I want to be honest about the order of operations here, because I think it matters. I didn’t propose the redesign first and go looking for a reason. I watched someone struggle first, named the actual job the feature needed to do, and only then reached for a form that matched it.

The team’s reaction was reasonable and a little cautious, which I think is the right instinct when someone proposes departing from a familiar pattern: they didn’t commit to building it outright. They gave me room to mock it up and present the reasoning—if it held up, they’d build it; if it didn’t, it wouldn’t go further than a mockup. That’s a fair bar. A good idea should be able to survive being shown, not just described.

What this means if you’re evaluating whether to trust someone with your product

Most of what I do isn’t inventing new patterns. It’s noticing when an existing pattern has quietly stopped matching the job it’s supposed to do—and being willing to say so, even when the existing version isn’t broken, exactly. It’s just doing the wrong job well.