Case study
38Screens
LANDLUST is a dashboard for people who let property: listings, applications, tenancies, rent, agents and the money that moves between them, in one place.
This case study covers a full UI/UX pass over a file that had no design system at all: no variables, no text styles, no paint styles, no effect styles. An audit, thirty copy defects fixed, a token layer and type ramp built from the values already on the canvas, the analytics screen the sidebar had been pointing at since day one, and a prototype.
Client
The client's name and internal figures are confidential. Everything shown here is the design work itself: a UX audit of the source file, the design system built on top of its existing library, and the dashboard design that followed.
Process
This file had dozens of hand-typed colors, 26 font sizes and six typefaces, and not one style or variable to name any of them. Building the analytics screen first would have added another set of hard-coded values, so the system came first.
Problem
Zero variables, zero text styles, zero paint styles, zero effect styles, against 89 fill colors, 53 stroke colors, 26 font sizes and 33 corner radii. Every value on every screen was typed by hand.
“Insight” sat in the menu of all thirty-seven screens and led nowhere. “App Pages” was a leftover section header from the starter component library, still there as a nav item. Meanwhile Calendar and Integrations existed as screens the navigation never mentioned.
Frames had been scaled rather than resized, so font sizes and corner radii came out as long decimals instead of clean values a developer could build from.
“Recent Transition list”: the word is transaction, and it was in the heading users read. “Ye-ar Built”. “Contract Us”. “@2024 Landlust . All Right Reserved.” Thirty-six nodes reading “Est arcu pharetra pellentesque”.
User persona
The manager works the queues: applications waiting, rent overdue, tenancies expiring. The owner wants four numbers and no table at all. That split is why the dashboard leads with KPI cards and a revenue chart, and why Insight had to exist as its own screen rather than more widgets bolted onto Home.
Goals
Eighty-nine fills and twenty-six font sizes are not a palette and a ramp, they are a symptom. Nothing new ships until each one resolves through a token or a style.
Every item leads somewhere; everything that exists is reachable. Both halves failed here, in opposite directions, on the same sidebar.
One thousands separator, one decimal mark, one date format, one ellipsis. A dashboard is mostly numbers, and inconsistent numbers read as unreliable ones.
The file was light-only with no way to become anything else. Binding to two-mode tokens makes dark a switch rather than a second file.
Research
Before a single tenancy screen changed, we opened each of the thirty-seven original frames and logged every color, size and radius a letting manager would see. Thirty-three different corner radii on one dashboard is a fix list, not an impression.
Primary flow
Everything in LANDLUST is a step on the way from an empty property to money arriving on the first of the month. The flow below is the product's actual spine, and the two screens where it used to break (an analytics dead end and an orphaned calendar) are marked.
Grid system
LANDLUST is a desktop tool and only a desktop tool: all 38 screens (37 original plus the new Insight screen) are 1920 wide. The rail is fixed at 264px and owns its width; the remaining 1656 carries a 12-column grid with 24px gutters that every card, table and modal snaps to.
Components
The screens are built from an existing component library. We built a token layer on top of it so it can be themed and maintained: the layer this file was missing entirely.
Feature 01
Sign in, sign up, forgot password, OTP, new password. Each is its own screen rather than a modal, so a landlord or agent who reloads mid-verification lands back on the right step. The footer link on Sign In read “Don’t have an account yet? Sign In”, pointing at the page you were already on. It now reads “Don’t have an account yet? Sign Up”, and Forget became Forgot.
Feature 02
Four KPI cards and a revenue chart sit above the fold for someone with ten seconds. The rental application queue and the activity feed sit underneath for someone with all day. Notifications, wishlist and profile are overlay states on the same screen rather than separate destinations, so the numbers never leave the screen.
Click map
A design-intent click map of the dashboard: heat sits only on interactive targets (buttons, tabs, links, menus), weighted by how central each action is to a letting manager's day. It maps layout decisions, not recorded sessions.
Notifications, wishlist and profile are overlay states on the dashboard, so a manager can check them in one click without ever leaving the numbers.
The rental application queue is where the manager’s day happens, and its “See All” is the main route from the summary into the full table.
The Monthly period selectors and global search change what the dashboard shows rather than taking the user away, so they draw steady, mid-weight clicks.
Dashboards, My Listing, Rent Application, Transaction and Message are wayfinding: frequent but low-stakes, so they stay one click away on every screen.
Most rows are read, not acted on, so only the first row’s “…” menu and the current page marker carry heat. Charts, KPI figures and the activity text carry none.
Design-intent map, not recorded data.
Feature 03
It is the one nav item an owner would click first, and for thirty-seven screens it did nothing. The screen now exists, built from the dashboard's own KPI cards, chart and table components: occupancy, average days to let, renewal rate and arrears across the top, revenue against forecast, portfolio mix, top-performing properties and an alert feed of what actually changed.
Feature 04
The listing detail leads with photography because that is what lets a property, then the numbers a manager needs (rooms, living space, year built, tenants, requests), then the agent card with a direct message button. Available rooms shows as a filled bar rather than a fraction, because two of four reads faster as a bar than as text.
Feature 05
A property is listed, someone applies, a tenancy starts, rent arrives, and the transaction list records it. Each of those screens uses the same table component with the same status chips (success, pending, canceled) so a manager learns one pattern and reads all four. The heading on the transactions screen said “Recent Transition list” until this pass.
Feature 06
Calendar and Integrations had been designed and then stranded: no sidebar entry pointed at either. Meanwhile the rail carried “App Pages”, a section header left over from the starter component library, sitting there as a menu item with nothing behind it. That slot is now Calendar, and Integrations is reachable from Settings.
Feature 07
General, account, linked accounts, languages and password; support tickets and the FAQ. These are the screens a landlord opens when something goes wrong with a tenancy, so they have to sound like a letting agency. Before this pass the footer said “@2024 Landlust . All Right Reserved.” and the FAQ asked “What is the Criminal Mind Analysis Results?” on a property platform.
Responsive
All 38 screens are 1920 and nothing else. For a tool a letting manager uses at a desk all day that is defensible, but the owner persona checks the portfolio weekly and would do it on a phone. Below is what the layout has to become, not what it is: the rail becomes a drawer, the KPI row wraps to two, and the tables become cards.
Visual language
Eighty-nine fills became twenty-two semantic tokens built on a deep navy (#100A55) and a soft purple (#867DF2), with a warm orange accent and status colors reserved so they never appear as decoration. Twenty-six font sizes became a twenty-nine-style ramp in Inter: the sizes the screens were already using, named at last.
Inter, one family
Regular · Medium · SemiBold · Bold | 29 text styles, 6 typefaces reduced to 1
Before / After
Three places carried most of the damage. Each is shown as it was in the source file, and as it works now.
“Insight” sat on all thirty-seven screens and led nowhere, a leftover section header posed as a menu item, and two finished screens had no entry at all.
Every item leads somewhere and everything that exists is reachable. The App Pages slot is now Calendar.
Every value on every screen was typed by hand, and scaled frames had left font sizes and radii on uneven decimals.
Every color resolves through a named token with a dark mode behind it, and every size through a style.
Thirty copy defects, one of them in a page title, plus a Sign In footer link that pointed at the page you were already on.
All thirty defects fixed, including the heading users read first; the Sign In footer now links to Sign Up, and “Forget” became “Forgot”.
Results & Impact
A file with no design system now has one: every color resolves through a named token with a dark mode behind it, every size through a style, and the navigation finally agrees with the screens that exist.
Design-level outcomes measured against the source files. Live product data will follow launch.
Learnings
Every audit we run checks that each nav item has a screen. This file taught us to check the reverse as well: Calendar and Integrations had been designed, paid for in effort, and stranded because nothing pointed at them. Orphaned screens are invisible in a way dead links are not.
The screens are built on an existing component library, so we built a token layer on top of it. Colors and sizes can now be themed and maintained from one place instead of screen by screen.
“Recent Transition list” sat in a page title through every review this file had. Headings get read as shapes once they are familiar, which is exactly why a copy pass has to start with the largest type on the screen rather than the smallest.
Nothing in the file said whether 1920-only was a considered scope or an unfinished one. The Responsive section now states it plainly and shows what the other four widths have to become, because an undocumented gap reads as an oversight.
Let's work together
Team up with us
Have a product like this? Let's talk. Book a call
Devoq Design · [email protected]
Or see more case studies, including WorkHub, an HR platform designed on the same template.
PDF, 3 MB
Get a free UI/UX audit and discover what’s holding your site back
