UI consistency was the assignment. A shared institutional memory was the problem.

I was hired to create a design system to make all the elements work together for development. A scoped job, with a clear deliverable and a clear end date.

Fixing components meant looking closely at what those components were actually displaying, and what they were displaying was a landowner relationship, structured like a document library. Internal product notes from that period say it plainly:

“The entire system is built around the landowner relationship. Everything about the relationship is in one place.”

That's not a UI observation. It's a mismatch between the interface model and the business it was supposed to represent: the product's core object was never really “the document.” It was the relationship the documents existed to support. Once that was visible, a harder question followed:

“Why landowner and not land? If land is the constant, then if the land is sold or passed on, the history would move to the next owner.”

That's a decision about what a platform is willing to remember, and for whom, across an event most interfaces never have to survive: inheritance, sale, subdivision. Get it wrong, and the system doesn't just look inconsistent. It quietly loses institutional memory at the exact moment a family transition makes that memory most valuable.

What kept repeating

That question wasn't isolated to one account. Across operations with no relationship to each other, the same failure kept surfacing: critical knowledge scattered across people, files, systems, and legal structures, with no single to hold it together.

One operator comment exposed the severity of what  happens when the one person holding an operation's institutional memory is suddenly unavailable:

“If I get struck by lightning, he's screwed.”

A professional farm manager, unprompted, mid-conversation about lease renewals, reaching for the identical fear from a different angle:

“Let's say I got hit by a truck and somebody was coming into this position not knowing all those personalities… I could see where that would be nice”

The same fragmentation showed up in daily habit:

“I have a Google Drive. I have a OneDrive… sometimes I'm just saving fast enough. I don't remember where it got saved.”

And in legal structure: a single landowner relationship can carry seventeen family members with different payouts, with land, lease, and ownership all needing to change independently without the others collapsing.

Different people, different pressures, no reason to compare notes, and the same underlying failure every time: institutional memory with no place designed to hold it.

The question that changed

That recurring evidence reframed the actual question. It stopped being how should this interface work and became what should this product actually remember, and what needs to stay continuous when the owner, the lease, the people, or the responsibilities change. Not a UI question, but a decision about the system underneath.

The product consequence followed from it. A transactional system of record, one built to log payments and store documents, answers a different question than a system built to preserve institutional memory: who this relationship is, what's been agreed, what's fragile, and what a successor needs to know without having lived it. Oaken could have been built as the first kind of system. It would have shipped faster and demoed just as well. What the recurring evidence argued for was the second kind, and that argument didn't come from a strategy session.

Beyond the data model

That frame didn't stay contained to architecture. The same underlying question, what does this decision assume the product needs to remember, started showing up in design conversations that had nothing to do with landowners on the surface: which columns a payment table actually needs to prove, how a crop-share split should display without inventing a new unit, whether a customer importing three hundred backdated documents would ever know a request had gone through. Eventually those decisions stopped requiring me in the room. Engineers and a product manager who absorbed the same frame applied it on their own, including to a roadmap direction, that would classify notifications by relationship risk rather than by transaction type. That's an inference, not a shipped result: payment and lease data that started as a plain digital replacement for paper compounds, over time, into something that can describe the health of a relationship, not just the state of an account. That's the argument for building it, not proof that it works yet.

It's worth being precise about what this reframing has and hasn't proven elsewhere. In a few operations, it has, over time, absorbed a role once carried by a family member managing bookkeeping, not eliminated a job so much as let someone stop having to hold it alone. That's a slow, second-order effect.

The proof

The clearest evidence that the reframing mattered didn't come from a research session. It came from an ordinary support conversation, months later.

One of the growers on the platform had an office employee, the person who did the bookkeeping, kept the notes, carried the relationship history, go on leave for a personal matter, gone for a couple of months unexpectedly. In a system built only to log documents and payments, that's the emergency this entire case study has been about: a binder no one else could read, a head no one else had access to. Instead, the owner's son logged in. He could see the notes, the payments, what was going on. No one had to walk him through anything.

That's the proof, and it isn't dramatic. The success here is the failure that didn't happen: institutional memory that was supposed to walk out the door for two months, and instead just kept working.