What we learned about color, density, drawers, dark mode, and motion while designing the UI for a real trading journal SaaS — practical lessons for any data-heavy interface.
Most "Good UI" Advice Is Written for the Wrong Apps
Most "good UI" advice is written for marketing sites and consumer apps. It tells you to use generous whitespace, stick to one font, keep your color palette to three colors, and never put more than five elements on a screen.
That advice is correct — for marketing sites and consumer apps. It is actively wrong for the category of interfaces this article is about: data-dense dashboards. Trading platforms, analytics tools, observability dashboards, fintech back-offices, dev consoles — anything where the user's job is to scan, compare, and decide across many rows of structured information at once.
We spent the last year designing one of these: a trading journal for prop firm traders called Trader's Second Brain. The single hardest UX problem we kept solving over and over was the same one — how do you show this much information without making the page feel like a tax form.
These are the eight design lessons that survived the most rewrites. They apply to any interface where the data itself is the product.
Disclosure: This article references Trader's Second Brain, a trading journal SaaS we built ourselves. We use it as a worked example because we know its tradeoffs intimately. Every token, pattern, and counter-example below comes from our actual production CSS — not a hypothetical case.
1. Default to Dark, Even in 2026
The dominant color preference for SaaS landing pages is light. The dominant color preference for SaaS applications — the part the user actually works in for hours at a time — is dark. Every serious data tool we admire (Linear, Notion's database views, the Bloomberg Terminal, Vercel's dashboard, Datadog) ships dark by default and treats light as the toggle.
Our tokens reflect this:
:root {
--bg-void: #0a0a0a;
--bg-primary: #111111;
--bg-secondary: #161616;
--bg-surface: #1c1c1c;
}
[data-theme="light"] { --bg-void: #fafafa; --bg-primary: #ffffff; --bg-secondary: #f5f5f7; --bg-surface: #f0f0f2; }
Dark is the source of truth. Light is the override. This is the inverse of the common pattern (light defaults, dark via media query) and we did it deliberately. The reasoning is not aesthetic — it's about who you're designing for. A user who opens the app at 7am and closes it at 11pm is reading green and red numbers for fourteen hours. Pure white backgrounds are exhausting at that volume. Dark surfaces let the colored data carry the visual weight without the page itself shouting.
If your app is going to be open in a tab next to a chart for hours, ship it dark. If your app is a quick-action consumer flow used twice a week, ship it light. The right default depends on session length, not on what's trendy.
For a deeper take on dark mode as a system rather than a toggle, our guide on implementing dark mode the right way walks through the full token approach.
2. One Semantic Role, Two Color Scales
The number one beginner mistake in dashboard color systems: defining --green: #22c55e once and using it in both themes.
It looks innocent:
/ Wrong — one green for both themes /
:root {
--green: #22c55e;
--red: #ef4444;
}
The same hex value hits human eyes very differently on white versus near-black. On a dark background, #22c55e reads as a saturated, energetic green — "this is a winning trade." On a white background, the same hex looks neon, harsh, and slightly off-brand. Vivid greens and reds need to be darker in light mode to match the perceptual weight they carry in dark mode.
The fix is two scales for the same semantic role:
:root { / dark /
--green: #22c55e; / vivid /
--red: #ef4444;
}
[data-theme="light"] { --green: #16a34a; / one notch darker / --red: #dc2626; }
Same meaning, different optical weight. The user perceives "profit" and "loss" with the same intensity in both themes, even though the hex values are not the same.
This holds for every semantic color in your system — warning, info, accent — but it's most visible with the high-frequency P&L colors that dominate trading and analytics UIs, because those colors appear hundreds of times on a single page. A small perceptual mismatch on every cell adds up to a screen that feels "off" without the user being able to articulate why.
Our broader take on building color systems lives in color theory for web developers.
3. Build a Four-Step Elevation, Not Two
In light-mode design you can usually get away with two elevation steps: a page background and a card. Maybe a third for modals.
In dark-mode design, two steps is not enough. Without enough elevation contrast, every panel bleeds into every adjacent panel, and the page becomes one undifferentiated black void. The user can't tell where one card ends and the next begins.
We landed on four:
--bg-void: #0a0a0a; / page — furthest back /
--bg-primary: #111111; / main app shell /
--bg-secondary: #161616; / cards, panels /
--bg-surface: #1c1c1c; / hover states, popovers /
Each step is small — only six or seven hex points apart. But together they create just enough visual separation that the eye can parse panel boundaries without harsh borders. We layer subtle borders (rgba(255, 255, 255, 0.06)) on top of those elevations for additional definition where needed.
The light-mode equivalent compresses this back to roughly two-and-a-half meaningful steps (#fafafa → #ffffff → #f5f5f7 → #f0f0f2), because white-on-white needs much less contrast difference to read as separate surfaces.
The general rule: the darker your base, the more elevation steps you need.
4. Two Fonts, Not One
Conventional UI advice: pick one good sans-serif and stick to it. For most apps, this is correct. For data-dense apps, it's wrong.
Tabular numbers are a different reading task than prose. Numbers need to be:
- Monospaced so columns of P&L line up vertically without
font-variant-numeric: tabular-numsworkarounds that don't always work - Slightly heavier than surrounding text so they pop in scan mode
- Visually distinct from surrounding UI text, so the reader's eye can switch reading modes between "label" and "value" without conscious effort
@import url('https://fonts.googleapis.com/css2?family=Instrument+Sans:wght@400;500;600;700&family=DM+Mono:wght@400;500&display=swap');
This split is invisible to the user but immediately legible. It's the difference between feeling like you're using a tool versus a marketing page. Sportsbooks, exchanges, and financial terminals have known this for decades — it's why they all look like they share a designer.
If you ship a data tool with a single rounded geometric sans for both labels and numbers, your dashboard will feel friendly and unfocused, no matter how good the data underneath it is.
5. The Drawer Pattern Beats the Detail Page
When you have a list of items the user needs to compare (trades, orders, alerts, log entries, transactions), the worst possible interaction is: click a row → navigate to a detail page → use the back button to return.
We tried this. It killed the journal review flow. Every "back" press lost the user's place in the list — pagination state, scroll position, applied filters, all gone.
The replacement that worked: clicking a row opens a drawer that slides in from the right, covers about 50% of the screen on desktop and 100% on mobile, and dismisses with Esc or a backdrop click. The list stays mounted behind it. Filter state, scroll position, sort order — all preserved. The user can keyboard-navigate through the list with the drawer open and the detail panel updates in place.
The browser already gives you 90% of this with :
No library needed. Native focus trap, native escape-to-close, native backdrop. Style the ::backdrop pseudo-element and you're done.
The mental shift: stop thinking of detail views as separate pages. They're inspector panels for an item the user is already looking at. The list is the page; the drawer is just a closer look.
6. Conditional Density: Not Every Green Needs to Scream
A common mistake in P&L UIs is using the same vibrant green for every winning value, no matter where it sits on the page. The result: every cell shouts, and nothing actually catches the eye.
The fix is a two-tier emphasis system:
/ High emphasis — hero values, summary stats, daily totals /
.pnl-large { color: var(--green); font-weight: 600; }
/ Low emphasis — repeating cells inside a long table / .pnl-cell.win { color: rgba(34, 197, 94, 0.85); } .pnl-cell.loss { color: rgba(239, 68, 68, 0.85); }
Same semantic, different visual weight. The summary number at the top of the page screams; the same number repeated 80 times in a table whispers. The user's eye still parses both — winning rows are clearly green — but their attention isn't fragmented across every cell.
The same logic applies to charts. A 600px equity curve at the top of a page deserves full color treatment, axes, gridlines, hover tooltips. The same data shrunk into a 60×24px sparkline beside each strategy row should be a single one-pixel line, no axis, no label, no hover state. Same dataset, different consumption mode.
If everything is emphasized, nothing is. Density discipline is what separates an "intense" dashboard from a useful one.
7. Mobile: Collapse, Don't Shrink
The honest truth about data-dense apps on mobile: you cannot fit the desktop table on a 390px screen. Trying to is the most common failure mode.
The two wrong approaches:
- Horizontal scroll — the user has to swipe sideways through a 12-column table, never seeing the whole picture. The comparison value of the table is lost the moment you can only see four columns at once.
- Tiny font, tight columns — every cell becomes a 9px squint, tap targets vanish, and the keyboard covers half the screen the second the user tries to filter.
@media (max-width: 768px) {
table.trades { display: block; }
table.trades thead { display: none; }
table.trades tr { display: grid; grid-template-columns: 1fr auto; gap: 8px 16px; padding: 16px; border-bottom: 1px solid var(--border-default); }
table.trades td { display: contents; } table.trades td::before { content: attr(data-label); color: var(--text-tertiary); font-size: 12px; } }
You lose horizontal comparison. You gain readability. For 80% of mobile usage of a data tool — a quick check, log a trade, glance at today's P&L — readability is what matters. The deep review session always happens on desktop anyway. Don't design the mobile view to do the desktop's job; design it to do the mobile job.
8. Motion Is for Confidence, Not Decoration
The temptation in 2026 is to layer motion onto everything. Page transitions, list reorderings, count-up number animations, float-in cards. For consumer apps, this can work. For data tools, it's friction.
Our entire motion system has three durations and one easing curve:
--duration-fast: 120ms; / button press, toggle /
--duration-normal: 200ms; / drawer open, modal /
--duration-slow: 350ms; / page-level route change /
--ease-out: cubic-bezier(0.16, 1, 0.3, 1);
That's it. No bounces inside the trading UI itself (we keep spring easing for the marketing site only). No staggered list animations on table render. No skeleton loaders that animate independently per row.
The principle: motion should confirm a user's action, not entertain them. A 120ms acknowledgment that their click registered is useful — it tells the brain "the thing happened." A 600ms swooping reveal of the panel they just summoned is not — it makes the app feel slow because the user's reaction time is faster than the animation.
The test: if a motion ever takes longer than the time the user needs to dismiss it, the animation is too long.
When the Rules Don't Apply
Every lesson above assumes the user is here to do work. If you're building a portfolio dashboard for a once-a-month-checking retail investor, most of this advice is wrong — that user wants delight, not density. Light theme, generous spacing, big friendly numbers, a single beautiful chart, and no monospaced fonts will outperform our entire token system for that audience.
Know which side of the line your product sits on. If your users open the tab daily and keep it open all session, design for sustained reading. If they open it once a week to feel reassured, design for the moment.
For us, the answer was clear from day one: a trading journal is a sustained-reading product, and so is most of analytics SaaS. The rules above came out of that constraint, not out of personal taste.
If you want to see how all of this comes together in production, the journal we built — Trader's Second Brain — is online and free to try. The patterns above are not theoretical; they're the actual production CSS the app ships with. We rebuilt several of them three or four times before they felt right, and we'll probably rebuild them again. Data-density design is a craft you don't finish — you just keep narrowing what "enough density" means for your specific user.