Case study / 10 — SaaS · Dashboard

DATA SAAS management dashboard.

A SaaS data-management dashboard — dense information organized into decisions, not decoration.

Role
UI/UX Designer
Platforms
Web · SaaS
Category
SaaS · Dashboard
Type
Data Dashboard
0
Platforms
0
Process phases
0
Key decisions
0
Research insights

OVERVIEWThe idea

Data dashboards fail when they display everything and explain nothing. This concept organizes a data-management product around the decisions users actually make.

THE PROBLEMWhat had to be solved

Users drowning in tables need hierarchy: what changed, what needs action, what can wait. Charts must earn their pixels.

MY ROLEWhat I owned

Dashboard IA, data-visualization choices, table systems, and the component patterns that keep dense screens readable.

DESIGN PROCESSFrom idea to interface

01 User task analysis
02 Information hierarchy
03 Layout system
04 Data-viz selection
05 Component library
06 High-fidelity UI

METHODThe workflow, end to end

01
Step 01
User task analysis
02
Step 02
Information hierarchy
03
Step 03
Layout system
04
Step 04
Data-viz selection
05
Step 05
Component library
06
Step 06
High-fidelity UI

KEY DECISIONSWhat made it work

🚦

Action-first overview

The landing view answers “what needs me today?”

📋

Progressive tables

Summary rows expand to detail — density on demand.

📈

Honest charts

Visualizations chosen for the question, not the aesthetic.

🔍

Global search & filters

Any record reachable in two interactions.

RESEARCH & INSIGHTSWhat shaped the direction

Discovery focused on the jobs users hire the product for: what decision does this screen serve, what action follows, what can wait behind a click. Auditing comparable SaaS tools showed the same trap everywhere — dashboards that display everything and prioritise nothing.

🚦

Action first, data second

Users open the product to do something. The landing view must answer “what needs me today?” before showing anything else.

📉

Density needs hierarchy

Dense tables are fine — undifferentiated dense tables are not. Summary first, detail on demand.

🧭

Predictability is speed

In daily-use tools, users get fast by building muscle memory; consistent patterns are a performance feature.

WHO IT'S FORDesigning for real people

PRIMARYThe daily operator

Lives in the product, values speed and keyboard-friendly flows, and notices every inconsistency. Needs dense-but-ordered screens that reward familiarity.

SECONDARYThe occasional decision-maker

Drops in weekly for status and numbers. Needs summaries, trends and export — without relearning the interface each visit.

DESIGN LANGUAGEThe visual system

A restrained interface where colour means something: neutrals for structure, one accent for primary actions, and semantic colour reserved for status. Tables use progressive disclosure, cards summarise before they detail, and every component comes from a documented library so new screens ship consistent by default.

Semantic colour only
Progressive-disclosure tables
Summary-then-detail cards
Documented component library
Keyboard-friendly flows

TESTING & ITERATIONPressure-testing the design

Prototypes were tested against realistic data volumes — hundreds of rows, awkward edge cases, long names — because SaaS designs that demo well often collapse under real data. Iterations tightened empty states, loading states and error states, the three screens teams usually forget.

PROJECT SCREENSInside the design

Data SaaS — sign in Data SaaS — edit profile Data SaaS — settings Data SaaS — insights dashboard Data SaaS — voters list Data SaaS — districts

Auto-scrolling — hover any screen to pause & lift

OUTCOMEThe result

A dashboard that turns data into next steps — full case study on Behance.

View full project on Behance

KEY LEARNINGSWhat I'd carry forward

01 Design with real data volumes from day one; lorem ipsum lies.
02 Empty, loading and error states are where products feel professional — or don’t.
03 A dashboard’s job is decisions per minute, not charts per screen.
← Previous
Social Media Chat App