Nahom Kasa recently shared something that caught my attention: "Knock Knock.... brought some dope design for you. wait let me be kind of formal" - then he followed it with an honest reflection that many early designers feel but rarely say out loud. He wrote that he "never imagined" he would be designing at this level so early, and that after learning UI principles just four days ago, he spent six focused hours turning theory into a dashboard.

That mix of excitement and humility is the real story here. Nahom is not just showing a screenshot. He is describing the invisible systems that make a UI feel intentional: typography, color, and layout. And then he asks the most important question for growth: "Dear Designers: Do you see any mistakes or areas for improvement?".

Below, I want to expand on what Nahom outlined, and turn it into a practical, blog-friendly roadmap you can apply to your next dashboard.

Key insight from Nahom Kasa: growth accelerates when you move from decorating screens to building systems.

The leap from "looks good" to "works well"

Dashboards are a perfect training ground because they compress many UI challenges into one surface: dense information, hierarchy, repeated patterns, and constant tradeoffs between clarity and visual appeal.

When Nahom says this project was "a deep dive into the technical systems that make a design work," he is pointing to a mindset shift. UI design is not only about taste. It is about decisions that remain consistent under pressure:

If you add a new metric card, does it automatically fit the hierarchy?
If you introduce an alert state, does the color system handle it without improvising?
If another developer implements your design, can they reproduce spacing and alignment accurately?

Those questions are what separate a nice mockup from a scalable interface.

Typography systems: using type to drive focus

Nahom mentioned "mastering the 'when' and 'how' of font weights and scales to drive user focus." That is exactly the right framing. Typography is a control panel for attention.

What a typography system actually is

A typography system is not "pick two fonts." It is a set of repeatable rules:

A type scale (for example 12, 14, 16, 20, 24, 32)
A small set of weights (for example Regular 400, Medium 500, Semibold 600)
Line-height rules (often expressed as ratios or fixed values)
Usage guidance: where each style is allowed

For dashboards, the goal is to keep cognitive load low. Readers should not have to decode visual noise before they can interpret data.

A practical hierarchy for dashboards

If you are building a dashboard like Nahom, a simple starting hierarchy can look like this:

Page title: 24-32px, semibold
Section headers: 16-20px, semibold
Card titles and labels: 12-14px, medium
Primary values (KPIs): 24-40px depending on density
Table body text: 12-14px, regular
Helper text: 12px, regular, lower contrast

The key is to make the hierarchy obvious even in grayscale. If you desaturate the screen and it still reads clearly, your typography is doing real work.

Common mistakes to watch for

If Nahom is asking for critique, these are typical typography traps in early dashboards:

Too many sizes: six different "almost the same" font sizes makes everything feel accidental.
Overusing bold: if everything is emphasized, nothing is emphasized.
Weak number styling: metrics are the hero in dashboards, so numbers often need stronger hierarchy than labels.
Line-height issues: cramped lines reduce scan-ability, especially in tables.

Functional color: beyond aesthetics

Nahom also called out "Functional Color" and described categorizing colors into "Base, Accent, Content, and Semantic layers" with proper ratios. This is a mature approach because it ties color to meaning.

Think in layers, not swatches

A functional color system often includes:

Base: surfaces and structure (backgrounds, cards, borders)
Content: text and icons (primary, secondary, disabled)
Accent: brand or highlight (links, selected states, focus rings)
Semantic: meaning-based colors (success, warning, error, info)

What matters is not just the palette, but the rules: what each layer can do, and where it can appear.

Ratios: a simple rule that saves you

Nahom mentioned respecting ratios. A helpful guideline is that most of your UI should live in neutrals:

70-85% neutral/base
10-20% content contrast and subtle accents
5-10% semantic or strong accent

Dashboards especially benefit from restraint. If every chart is saturated and every card has a bright background, users lose the ability to spot what is actually important.

Accessibility checks that designers skip

If you want to strengthen what Nahom started, validate these:

Text contrast: body text should typically meet WCAG AA (4.5:1) when possible.
Semantic reliance: do not use color alone to convey status. Pair it with an icon, label, or pattern.
State clarity: ensure hover, focus, selected, and disabled states are all distinguishable.

If your dashboard still makes sense in grayscale, your color is likely functional, not decorative.

Layout discipline: the 12-column grid is your friend

Nahom said he implemented a 12-column grid "to ensure alignment and professional structure." This is one of the fastest ways to make a design feel "real" because alignment is the signature of care.

Why 12 columns works

Twelve is flexible. You can split it into halves (6 and 6), thirds (4 and 4 and 4), quarters (3 and 3 and 3 and 3), and many mixed layouts. Dashboards often need that flexibility because content blocks vary.

Grid details that matter in a dashboard

To level up the layout discipline, define these explicitly:

Container width (for example 1200px or responsive max width)
Gutter size (for example 24px on desktop)
Margin (outer padding, for example 24-32px)
Spacing scale (for example 4, 8, 12, 16, 24, 32)

Then enforce it. Repetition is not boring in dashboards. Repetition is usability.

If I were reviewing Nahom’s dashboard conceptually, I would look for:

Misaligned baselines: card titles, numbers, and chart edges should line up across rows.
Inconsistent padding: two cards next to each other should not have different internal spacing unless there is a reason.
Density drift: a table packed tightly next to a spacious chart feels like two different products.

Turning feedback into the next iteration

The best part of Nahom’s post is the invitation: he wants others to see the work "through the eyes of others." That is exactly how designers improve quickly.

Ask for specific critique

Instead of "any thoughts?" try prompts like:

"Is the hierarchy clear in the first 3 seconds?"
"Which element feels most distracting?"
"Do the semantic colors read correctly without labels?"
"Where does alignment feel slightly off?"

Here is a lightweight checklist aligned with the systems Nahom mentioned:

Typography: no more than 6 text styles used on the page
Color: neutrals dominate, semantics are reserved for meaning
Layout: consistent padding, consistent gutters, consistent alignment
States: hover, focus, selected, disabled accounted for
Data: labels and units are present, empty states considered

A note on Nahom’s pace: four days in, shipping work

Learning UI principles for four days and then committing six hours to a real output is a strong pattern: learn, build, reflect, repeat. The dashboard is the artifact, but the real skill being built is taste plus discipline.

Nahom is also blending identities: civil engineering, full-stack development, and design. That combination is powerful because systems thinking translates across domains. Grids, constraints, ratios, and structure are not just design concepts. They are engineering instincts applied to interfaces.

Closing: keep building systems, not just screens

Nahom Kasa’s post is a reminder that early progress can be rapid when you focus on fundamentals that scale: typography systems, functional color, and layout discipline. The next step is to keep narrowing the rules until the UI almost designs itself.

If you are on a similar journey, share your work the way Nahom did: with excitement, with honesty, and with a clear request for critique. That is how theory becomes craft.

This blog post expands on a viral LinkedIn post by Nahom Kasa, 2nd Year Civil Engineering Student @ AAU | Full-stack Developer | Building Beams & Bits. View the original LinkedIn post →