TenantKey

What was already breaking before you started?

Operations don’t fail loudly. They fail quietly, spread across a dozen disconnected workflows — not a crash, not an outage, just a slow tax on every person running the property, paid in clicks, in re-checking, in remembering what the system should have remembered for them.

TenantKey is the operational backbone of a student-housing portfolio. It carries the whole resident lifecycle — prospect, application, lease, tenant, operations, accounting — for the campus teams running each building day to day. When I joined the initiative for American Campus Communities, the platform was already functionally complete. It could do everything. That was never the problem.

The problem was that doing everything had cost it a shape. And a system with no shape doesn’t announce its failures. It just makes every ordinary task a little heavier than it should be, until “heavy” is simply how the software feels.

Three roles. Three versions of the same tax.

Evaluation of a property team’s day showed the same pattern everywhere: the software was rich, and the richness had no hierarchy. Six specific things were breaking, and each one had a cost.

Managers felt it from a different angle. They’re accountable for pipeline progress, task completion, and tenant health — and the system gave them no quick read on any of the three. To learn how a property was doing, they had to go digging, the same as everyone else.

This is the business cost the way the other end of the funnel felt it: an operational platform that’s exhausting to run is one a large operator eventually looks to replace. The experience wasn’t just taxing users — it was quietly working against the product’s own stickiness.

The software could already do the work. It just made a person carry the coordination the system should have carried itself.

So the objective was never more features. It was to give the power a shape a busy person could hold.

What did you actually own here?

I owned this end-to-end as the sole designer — discovery, information architecture, interaction and visual design, prototyping, developer handoff, QA validation, and production support. Six modules, one designer, one continuous vision.

That ownership came with a real constraint that shaped how the whole thing got made. I was designing from India; my product manager was in the United States. Instead of letting the twelve-hour gap slow the work to a crawl, I turned it into a cadence: a call nearly every night, both of us on a shared online whiteboard. I’d sketch a flow live while my PM brought the business priorities and field edge cases, I’d work through them against the design on the spot — then carry the decision straight into high fidelity before the next call.

Before a single screen was designed, I aligned with my product manager on what success actually had to look like.

There were no week-long spec round-trips and no formal wireframe deliverables. The process was deliberately lightweight: the thinking happened on the whiteboard, and Figma was where it got made real. For a system this large, that mattered — the nightly rhythm kept decisions small, frequent, and shared, which is exactly what let one designer hold a coherent vision across six modules without it fragmenting between hand-offs.

Speed mattered. But not at the cost of clarity. Every decision came back to one question — does this make it easier for a developer to find a job, or a recruiter to find the right person?

Before a single screen was designed, I aligned with product stakeholders on what success actually looked like.

Who else shaped this

I was the only designer, but the product was shaped in partnership — and the working relationship that shaped it most was the nightly one with my product manager.

The PM partnership set the pace. With a twelve-hour gap between us, I couldn’t afford slow, document-heavy hand-offs. So I met with the PM on a shared whiteboard nearly every night — they brought the business priorities and the edge cases from the field; I brought the flows and the structure and made the design decisions live against their input, before the session ended. Most of the design direction on TenantKey was set in that window, then reviewed and signed off by my PM — not written up in a spec afterward.

Engineering turned decisions into a shipped system. Because there were no heavy wireframe deliverables, I worked closely with engineering at high fidelity — walking through the pattern, the states, and the edge cases directly, so the consistency I’d designed survived the build. When a screen’s reality was messier than the mockup, that surfaced in those conversations, and the pattern bent to fit rather than breaking.

QA held the line on the details. A system with one repeated pattern only stays trustworthy if the pattern is applied exactly the same way everywhere. QA validation was where that got enforced — catching the places a status chip, an empty state, or a table behaved a little differently than its siblings, so the “one pattern” promise held in production, not just in Figma.

The best design decisions on TenantKey were made live, on a whiteboard, at the one hour the two time zones overlapped.

Through all of it, one question kept every decision pointed the same way: what would success actually mean?

That question became the compass for everything that followed. Next: understanding what was actually broken.

What rules did every screen have to pass?

A system this large needed a small set of non-negotiables — the tests a screen had to pass before it shipped. These four did that work, and every decision in the case study traces back to one of them.

One pattern, everywhere. A list is summary cards over a prioritized table; a record is identity, progress, status, then tabbed depth. The same anatomy in all six modules, so learning one teaches the rest.

Verdict first, evidence on demand. Every screen leads with the read a person came for — the health, the status, the number — and holds the detail one layer down for when they actually want it.

Context is carried, not re-entered. Market, property, and season are set once and travel across every module. The system never makes a person re-state where they already are.

The system remembers. Follow-ups, submissions, and status changes become a visible, timestamped history on every record — so the team stops depending on notes and memory to know what happened.

And underneath all of them, one question: does this decision make a meaningful connection between a candidate and a recruiter easier, or harder? Every trade-off in the sections that follow resolved by asking it.

With the criteria clear, the first real work was listening. What I heard reframed the problem entirely.

How did you learn what both sides actually needed?

The first real work was listening — a structured research push before any I didn't start with screens. I started by understanding how the work actually happened — who touched which module, what they were trying to finish, and where the existing experience made them stop and stitch..

The inputs were practical, drawn from the people closest to the workflow. Three of them, each answering a different question.

None of this was a controlled research programme, and I won't dress it up as one. It was the practical, in-the-room understanding you build by listening closely to the people who run the thing every day — and it was enough to point clearly at what the redesign had to fix.

One finding that changed a decision

Walking the workflow with the leasing team, the same thing kept happening in every session: an agent would open a prospect record, then immediately go back to the list to check where that prospect sat in the pipeline — because the record itself carried no sense of status or progress.

That wasn't a one-off complaint. It was a habit I watched repeat across different agents at different properties.

It's the direct reason every record in TenantKey opens with a progress track and a status baked into the header, not buried in a tab. The fix wasn't a nice-to-have — it was answering a motion I'd watched people make with their own hands.

What the category was missing

I didn't run a formal competitive teardown, and I won't pretend I did. But the category has a well-known shape, and understanding it sharpened what TenantKey needed to be. Property and lease management platforms tend to fail the same way — not on capability, but on coherence.

The pattern across the field is a system assembled module by module, each one shipped by a different team at a different time, each solving its own screen in its own way. The result is powerful software that behaves like a dozen small products sharing a login. Leasing looks nothing like accounting; a record in one module is laid out unlike a record in the next; and the person running the building pays for that inconsistency in re-learning, every single day.

None of this was a controlled research programme, and I won't dress it up as one. It was the practical, in-the-room understanding you build by listening closely to the people who run the thing every day — and it was enough to point clearly at what the redesign had to fix.

That gap was the opening. TenantKey didn't need to out-feature anyone — the features were already there. It needed to be the one platform in the category where the richness felt like a single, learnable system. The whitespace wasn't a missing capability. It was coherence itself.

To design that coherence, I had to see the journey the modules were quietly splitting apart. Which meant naming exactly who I was designing for.

So what was the big reframe?

The bet was simple to state and hard to earn: take a system rich enough to run an entire housing portfolio, and make it feel learnable — without removing an ounce of what it could do.

The assumption going in was that the problem lived in individual screens — that some were badly designed and needed fixing. What I actually found was different. No single screen was bad. Every screen solved its layout problem differently, so the system read as six products stapled together. My job was to make it read as one. The problem wasn't quality. It was coherence.

So I set a single organising rule: one pattern, everywhere. If a leasing agent learned how a record page behaved in Leasing, that knowledge had to transfer — unchanged — to Tenants, Tasks, Operations, and Accounting. Consistency here wasn't a matter of taste. It was the mechanism that would lower cognitive load, raise discoverability, and cut onboarding time. Get the pattern right once, and every module inherits the fix.

Where the seams were

TenantKey isn't six tools. It's one journey — a person moving from stranger to resident to line item — that the software had split into six modules. Mapping that arc showed exactly where the seams were, and why crossing them by hand was the core tax.

Each hand-off between stages was a place the old system asked a person to leave one module, find the matching record in the next, and rebuild the context themselves. A prospect who becomes an applicant who becomes a tenant is one person — but the software treated each stage as a fresh start. The redesign's job was to make those hand-offs disappear, so one arc felt like one arc even though it spans six modules underneath.

From insight to design problem

The old system treated every screen as a place to store information. I decided every screen should be a place to make a decision — leading a person toward the read they came for, then holding the detail one layer down for when they want it. It's the same move whether the decision is "is this pipeline healthy," "should this application advance," or "does this batch balance."

A screen isn't a filing cabinet. It's a recommendation about what to do next.

I stated the problem across four lenses to keep a wide stakeholder set honest about whose problem this actually was:

Which let me frame a year of decisions as one question:

How might we help campus teams read and act on a rich operational system at a glance, so completing a workflow stops meaning stitching five screens together by hand?

The framing statement every module answered back to — who it serves, what it changes, and why it mattered.

Now I could see the journey whole, and I knew what to solve. The next question was who exactly I was solving it for.

Who were you actually designing for?

Five distinct roles. One shared surface. Each living in a different corner of the same system, each needing it to behave differently.

TenantKey isn't a tool for one kind of user — it's the shared surface for an entire property operation. Naming the roles precisely was how I kept the redesign from drifting into everyone's wish list at once.

The central tension ran between the first two. The agent wants depth on one record — everything about this prospect, right now. The manager wants breadth across hundreds — the shape of the whole pipeline at a glance. Serve only the agent and the manager is blind; serve only the manager and the agent drowns. Resolving that tension — summary on top, depth one layer down, on every screen — became the backbone of the entire system.

The tension was real. Leasing agents needed depth on one record; managers needed breadth across the whole pipeline. Property managers needed a complete lifecycle view, while operations needed immediate task context and residents needed transparency. The shared system had to serve all five without becoming five different products.

A pipeline the agent can't read fast stalls before it reaches the manager. A summary the manager can't trust sends him straight back into the agent's screens. Serve both — verdict on top, depth one layer down — and the whole system works.

Representative personas synthesised from the workflow analysis and stakeholder sessions.

With the people clear, I could see the whole arc they were moving through. The next question was how to structure a system that large.

How do you structure a system this large?

Before touching a single module, I fixed the frame they would all share. Three architectural decisions did most of the work, and every screen in the system inherits them.

Two questions guided this phase — what does the platform need to contain, and what does moving through it actually feel like? The architecture answered the first. Mapping the lifecycle answered the second.

What the platform needed to contain

Six modules. One shared frame. Every module uses the same list-and-record anatomy, so the knowledge transfers instead of resetting.

A persistent context bar

Campus teams don't work on "the system" — they work on a property, in a season. So Market, Property, and Season live in a fixed bar at the top of every list, and they never reset as you move between modules. Set your context once, and all six modules speak about the same building. It quietly removes a whole category of "wait, which property am I looking at" errors.

Summary first, evidence on demand

Every list opens with a row of summary cards — the numbers a manager needs before the table beneath them. Every record opens with an identity header, a live progress track, and a status, then tabs the depth one layer down. The verdict is always on the surface; the detail is always one click away, in the same place, every time.

The earliest whiteboard version put status and progress inside the first tab, not the header — keeping the identity block lean felt right on paper. It fell apart the same night. Every time I walked a record on the shared call, my PM's first question was "wait, where is this one at?" — and they'd have to click into the tab to find out, every single time. I moved status into the header the next session, and it never moved back.

The activity feed as shared memory

The tribal-knowledge problem — teams remembering what happened through notes and hallway conversations — got answered structurally. A right-rail activity feed on every record turns follow-ups, submissions, and status changes into a visible, timestamped history. The system remembers, so the team doesn't have to.

Read as one change, those three decisions rewrite the path a person walks to get something done:

None of these are decoration. Each is a direct answer to a line in the problem — fragmentation, click overhead, missing prioritisation, no hierarchy, tribal knowledge. Fix the frame once, and every module gets the fix for free.

The structure was set. The journey was mapped. The next question was how to turn it into something I could actually test.

How did you go from idea to something testable?

A structure on paper is a hypothesis until you trace the paths through it.

On TenantKey, the flow wasn't a branching diagram of edge cases — it was one repeated shape, walked hundreds of times a day: land on a list, read the summary, open a record, act. Getting that single loop right was the whole game, because it's the loop every role runs in every module.

So I designed it as two reusable surfaces that compose into everything else. Prospect, application, lease, tenant, task, request, batch — every one of them is just these two, filled with different content.

There was no formal wireframe or flow-diagram stage that survived. The flows were worked out live on the nightly whiteboard and taken straight into high fidelity — so the “flow” here is the list-and-record pattern itself, which is the reusable path through every module. I'd rather show the real repeated structure than reconstruct diagrams after the fact.

Filled with real content, across six modules, that pattern looks like this.

What did you actually ship?

The same pattern — shared context bar, summary-first lists, verdict-first records — applied across six domains as different as a leasing funnel and a reconciliation batch.

Walk them in order and the argument makes itself: this is one system wearing six hats.

Dashboard — a building at a glance

The home screen answers a manager’s first question — how is this property doing? — before they open anything.

Leasing — from a stranger to a signed lease

Leasing is the front door. I structured it as three states of one journey — Prospects, Applications, Leases — each list opening with the funnel metrics that state matters by, then a prioritised table.

Open a single applicant and the record surface appears in full — identity header, progress track, status, and the depth tabbed below, with the activity feed pinned alongside. This is the anatomy every record in the system reuses.

A verdict, then the evidence. Results read as a status; guardian, document, and academic checks break out as their own progress states below.

Messy choices made legible. Priced toggles for add-ons; floor-plan choices laid out in ranked order.

When an application becomes a lease, the same record shell carries forward — nothing about how the screen works has to be relearned at the most important moment in the funnel.

Tenants — the resident lifecycle, unified

Split by lifecycle stage — Current, Future, Past — so a manager reasons about who’s here, arriving, and gone, each as its own clean view rather than one filtered mega-list.

The tenant profile is the densest record in the system, where the consistent pattern does its heaviest lifting: even at maximum density, it reads, because it behaves like every other page.

Tasks — tribal knowledge, made a system

The direct answer to “teams rely on follow-ups and memory.” Every list opens with the status breakdown a lead needs to run a day: all, open, completed, in progress, overdue.

Operations — getting to the resident faster

For a technician, the job is triage. The request list leads with request health and puts priority, unit, and assignee right in the row.

Accounting — reconciliation without the dread

The least forgiving corner of the system — money has to balance. I led with an insights row that reads a period’s financial health at a glance, then a batch list, each batch clearly open or closed.

The hard states: When the data isn’t clean

A system this operational is only trustworthy if it holds up when the data is ugly — and a lot of the design judgment lived in the states a happy-path mockup hides.

Outcome: The full system, in one view

TenantKey is designed, built, and live in production at American Campus Communities — in daily use across the roles it was designed for: leasing teams, property managers, operations and maintenance staff, and accounting.

It didn’t ship as a single screen or a one-off feature. It shipped as a coherent system carrying the complete student-housing lifecycle, end to end — one pattern holding six modules together:

Because these are live enterprise operations, exact performance figures aren’t mine to publish, and I won’t invent numbers to fill the gap. What I can state plainly is what the redesign was built to move: fewer clicks per workflow, faster task completion, better information discoverability, less context switching between modules, clearer visibility into the leasing and operational pipelines, and greater consistency across the enterprise experience. Business-impact measurement was owned by the Product and Operations leadership teams; when a confirmed figure is cleared for sharing, it belongs here.

Shipping something this large, solo, wasn’t clean. The honest half of the story is what was hard.

What did this actually change?

TenantKey is live in production at American Campus Communities, in daily use by leasing teams, property managers, operations staff and accounting. What changed isn't a percentage — it's what the work now takes.

The scope that shipped

It didn't ship as a screen or a feature. It shipped as a system carrying the complete student-housing lifecycle — prospect to application to lease to tenant to operations to ledger — on one pattern a person learns once and reuses everywhere.

The change worth claiming isn't a number. It's that the coordination the software used to push onto people now sits inside the software: context carries across modules instead of being re-entered, records answer where is this on arrival, and history stays with the record rather than in somebody's memory. The people running the building got to go back to running the building.

These are live enterprise operations, so exact performance figures aren't mine to publish — and I won't invent numbers to fill the gap. What the redesign was built to move: fewer clicks per workflow, faster task completion, better discoverability, less context switching, clearer pipeline visibility, and greater consistency across the enterprise. Measurement was owned by the Product and Operations leadership teams; when a confirmed figure is cleared for sharing, it belongs here.

Shipping something this large, solo, wasn't clean. The honest half of the story is what was hard.

What was the hardest part?

Every honest case study has a second half. This is mine.

The difficulty on TenantKey wasn't a fight over any one screen — the nightly-whiteboard rhythm kept those small. The hard parts were structural, and they're worth naming plainly.

The bet was that one pattern could hold six very different jobs. Every module was a test of whether it would bend — or break.

Holding one pattern across six very different jobs

The tenant profile's density

Designing across a twelve-hour gap

Pressure-test the densest record first, not last The constraint forced a discipline that served the work — decide clearly, decide once, carry it forward. But it was a constraint I had to design around, every day, not one I could ignore.

Name where the pattern is allowed to bend “One pattern, everywhere” is a powerful rule, but a rule that can never flex becomes a cage. A few screens genuinely wanted to be a little different, and I'd have benefited from deciding up front where deviation was allowed and where it wasn't — so consistency stayed a tool, not a constraint I was fighting.

Plan the mobile story as a commitment, not a someday This is a desktop-first enterprise tool, and rightly so — the work happens at a desk. But “desktop-first” is only a smart constraint if the mobile follow-up is a dated commitment rather than an open question. I'd treat that second phase as a promise with a timeline, not an assumption.

Even with those, the thing I carry from this is bigger than any one screen. — Which is the last, and most personal, part of the story.

What did this build in me?

This was the largest single system I've owned end to end — six modules, five user types, one designer, live at a real enterprise.

It taught me that at this scale, the deliverable isn't a set of screens. It's a pattern disciplined enough to survive being applied a hundred times, in corners as different as a leasing funnel and a reconciliation batch, without cracking.

What I Learned

Consistency is a feature, not a finish: On a system this large, one repeated pattern does more for a user than any amount of per- screen polish. Sameness is what made it learnable — and learnability is what a person running a building actually needs from software they open forty times a day

Subtraction disguised as structure: When a product is already powerful, design's job is rarely to add. It's to give the power a shape a busy person can hold. Almost nothing was removed from TenantKey — it was reorganised until the same capability stopped feeling like a burden.

A rhythm beats a spec: Nightly whiteboard calls — decide small, decide often — held a coherent vision across six modules better than any document could have. Across a twelve-hour time gap, the cadence was the alignment mechanism.

Honest about what I can claimt: I stand behind the pattern and the architecture. The numbers belong to the teams who measure them — and I'll wait for a real one rather than reach for a convenient one.

The outcome, in one honest paragraph

TenantKey took a platform that could already do almost anything a student-housing operation needed, and made it feel like a single system rather than six that shared a login. It shipped as one pattern carrying the full lifecycle — prospect to application to lease to tenant to operations to ledger — designed alone across eleven months, from discovery through production support, and it's in daily use at American Campus Communities today.

That's what I take from it. And it's what I bring to the next system this size.