What makes dashboards hard
Dashboards sit at the intersection of three disciplines: information design (how to represent data visually), interaction design (how users navigate and manipulate views), and product strategy (what decisions the dashboard supports). Most dashboards fail not because they’re ugly or broken, but because they were built feature-first instead of decision-first — someone asked “what data do we have?” instead of “what decisions do people need to make?”
The core tension is between density and clarity. Users want to see everything at once — every metric, every trend, every segment. But the human eye can only process so much before a screen becomes overwhelming noise. A great dashboard resolves this tension by using hierarchy, progressive disclosure, and careful layout to present the right amount of information at each level of attention.
Information Visualization (Topic 16) teaches you how to design a great chart. This topic teaches you how to arrange twelve of those charts on one screen so a product manager can make a decision in thirty seconds.
Why this matters for your projects
Nearly every digital product eventually needs a dashboard — an analytics view, an admin panel, a reporting page, a monitoring screen. The patterns in this topic apply whether you’re building a custom dashboard from scratch or configuring one in Metabase, Grafana, or Looker. The same principles of hierarchy, density, and state management apply regardless of the tool.
Decision-first design
Every dashboard exists to support specific decisions. Before designing any layout or choosing any widget, answer four questions:
1. Who looks at this?
A CEO, a product manager, a support team lead, and a data analyst need fundamentally different dashboards — even when they’re looking at the same underlying data. The CEO wants a five-second health check. The analyst wants raw, filterable data. Serving both on one screen serves neither.
2. What decisions do they make?
List the actual decisions: “Should we increase ad spend in EMEA?” “Do we need to hire more support agents this month?” “Is the new checkout flow performing?” Each decision implies specific metrics and comparisons. If a widget doesn’t help answer a decision, it doesn’t belong.
3. What data do they need for those decisions?
Work backward from decisions to metrics. “Should we hire more support agents?” requires: current ticket volume, trend over time, average resolution time, agent utilization, and SLA compliance. Now you have a widget list derived from need, not from “what data we have.”
4. How often do they look?
A dashboard checked hourly needs real-time data and instant scannability. One checked weekly can be denser and more analytical. One checked monthly might be better as a generated report. Frequency determines refresh strategy, data density, and the level of interactivity.
The Five-Second Test Validation
Use when: Evaluating any dashboard design before development.
Show the dashboard to a stakeholder for exactly five seconds. Then hide it. Ask: “Is everything OK, or is something wrong?” If they can’t answer that question from a five-second glance, the dashboard’s information hierarchy has failed. The most important signal — the headline health check — should be readable in under five seconds without any interaction.
Information hierarchy and the inverted pyramid
Dashboard information should follow an inverted pyramid: the most important, most summarized information at the top, with detail increasing as the user scrolls or drills down.
Level 1: The answer (hero metrics)
The top of the dashboard shows 3–5 hero metrics — single numbers with trend indicators that tell the viewer whether things are OK. These should be answerable from across the room: revenue is up, churn is down, system is healthy. No interaction required.
Level 2: The evidence (supporting charts)
Below the hero metrics, charts and graphs provide context and evidence. “Revenue is up” becomes “revenue is up 12% driven by EMEA growth.” This level answers the natural follow-up question: “why?” or “how?”
Level 3: The investigation (detail and drill-down)
The bottom of the dashboard (or behind drill-down interactions) provides the raw data, detailed tables, and filters for investigation. This level serves the analyst who needs to dig into a specific segment or anomaly. Most users never reach this level — and that’s by design.
The newspaper test
A well-designed dashboard reads like a newspaper: the headline (hero metric) tells you what happened; the subhead (trend chart) tells you why it matters; the article body (detail tables) gives you the full story. Most people read the headline. Some read the subhead. Few read the full article. Design for all three audiences in one screen.
Density vs. usability: the Tufte tension
Tufte argues for maximum data density: more information per square inch, always. Interface usability argues for whitespace, breathing room, and progressive disclosure. Both are right, and reconciling them is the central design challenge of dashboards.
The resolution is: density within widgets, breathing room between them. Each individual chart should be data-dense — maximize the data-ink ratio, strip away non-data elements, use direct labeling. But the overall layout should give each widget enough surrounding space to be individually comprehensible before the eye moves on.
Cluttered vs. dense
There is a crucial difference between “cluttered” and “dense.” A cluttered dashboard has many elements competing for attention with no hierarchy — everything is the same size, same weight, same visual treatment. A dense dashboard has many elements organized by hierarchy — hero metrics are large and prominent, supporting charts are medium, detail is small or behind interactions. The amount of information may be the same. The readability is not.
Dense: A financial terminal showing 40 data points organized in a clear grid with consistent typography, muted colors, and a clear reading order. Every pixel carries information. The operator can scan the entire screen in seconds because the hierarchy is rock-solid.
Cluttered: A marketing dashboard with 15 colorful charts of varying sizes, three different chart libraries’ default styles, decorative icons, and no consistent reading order. It has half the data of the financial terminal but feels twice as busy because there’s no hierarchy to guide the eye.
Layout systems for dashboards
Dashboard layout is not creative expression — it’s information architecture. The layout system determines reading order, visual hierarchy, and how the dashboard responds to different screen sizes.
Grid-Based Dashboard Layout Core Pattern
Use when: Designing any multi-widget dashboard. The grid is the default starting point.
Use a 12-column grid. Standard widget widths: full-width (12 cols) for hero metrics and primary charts, half-width (6 cols) for secondary charts, third-width (4 cols) for KPI cards, quarter-width (3 cols) for compact metrics. Maintain consistent gutter spacing (16–24px) between all widgets.
Row 1: Hero metrics (3–5 KPI cards)
Full-width row containing 3–5 metric cards, each showing a single number with trend. This row answers “is everything OK?” at a glance. Use quarter or third-width cards.
Row 2: Primary chart (full or two-thirds width)
The most important time-series or comparison chart. Often accompanied by a secondary chart or summary panel in the remaining space. This row answers “what’s the main trend?”
Row 3+: Supporting detail
Half-width charts, data tables, segment breakdowns. Progressively more detailed as the user scrolls. This area serves investigation and deeper analysis.
Sidebar + main content
For dashboards with heavy filtering or navigation between views, use a collapsible left sidebar (200–280px) for filters, navigation, and saved views. The main content area holds the dashboard grid. The sidebar should collapse to icons on narrower screens, giving the data maximum space.
Fixed vs. fluid width
Dashboards that must work at both 1280px and 2560px need a fluid strategy. Options: fluid grid with max-width constraints on individual widgets (prevents charts from becoming absurdly wide), or a centered fixed-width layout with a max-width of 1440px that adds margins on wider screens. Avoid purely percentage-based widths that stretch charts beyond their useful size — a line chart at 2560px width with 12 data points is mostly empty space.
Widget patterns
A dashboard is composed from a vocabulary of widget types. Understanding the strengths and minimum viable dimensions of each type prevents the most common layout mistakes.
KPI cards
Single number + trend. Minimum width: 200px. Shows one metric with a comparison (vs. last period), directional indicator (up/down arrow or color), and optionally a sparkline. The primary scanning element of any dashboard.
Time-series charts (line/area)
Trends over time. Minimum width: 400px, minimum height: 200px. Below these dimensions, the chart loses legibility. Use area charts when you want to emphasize volume; use line charts when you want to emphasize rate of change. Limit to 5 lines maximum on a single chart.
Bar charts
Category comparison. Minimum width: 300px for vertical, 250px for horizontal. Horizontal bars work better when labels are long. Sort by value unless there’s a natural order (time, severity). For dashboard contexts, consider using just the top 5–10 items with a “see all” link.
Data tables
Precise values, sortable and searchable. Minimum width: 500px (below this, switch to a card layout on mobile). Best for operational dashboards where users need exact numbers, not trends. See the Data Tables section below for detailed patterns.
Status indicators
System health, pipeline stages, task status. Can be as compact as a colored dot with a label. Use semantic colors (green/amber/red or blue/yellow/red for colorblind safety) with text labels — never color alone.
Maps
Geographic data only. Minimum size: 400×300px. Only use maps when geography is the primary dimension of comparison. If the user just needs to know “which region has the highest revenue,” a bar chart sorted by value is faster and more accurate than a map.
KPI and metric card design
Anatomy of a KPI Card Core Pattern
Use when: Showing any single metric with context at the top of a dashboard.
A well-designed KPI card has five elements, in this visual hierarchy order:
1. Current value — The number itself. Largest text element. Should be readable from 3 feet away.
2. Metric label — What the number measures. Smaller, subdued text above or below the value. Keep it short: “Revenue” not “Total Revenue for Current Period.”
3. Comparison — vs. last period, vs. target, vs. same period last year. Shows whether the number is good or bad in context. Format: “+12% vs. last month” or “↑ 12% MoM.”
4. Trend direction — Visual indicator: arrow, color, or both. Up/green, down/red (but remember colorblind users — always use arrow direction alongside color).
5. Sparkline (optional) — A tiny, unlabeled line chart showing the last 7–30 data points. Provides shape context (is this a sustained trend or a spike?) without taking much space.
When to show percentage change vs. absolute change
Percentage change is meaningful when the base number is understood by the audience. “+15%” is useful when everyone knows revenue is typically $10M. It’s meaningless when the base could be $100 or $10M. When in doubt, show both: “$1.5M (+15%).”
Thresholds and conditional formatting
Define thresholds before building: what values are healthy, warning, and critical? Use consistent color coding across all KPI cards (green/amber/red or a colorblind-safe alternative). Don’t overdo it — if every card is red, the signal is lost. Reserve red for truly critical deviations.
Filter and control patterns
Filters are the primary interaction pattern on dashboards. Get them wrong, and users either can’t find the view they need or don’t realize they’re looking at filtered data.
Global vs. widget-level filters
Global filters affect all widgets simultaneously. Place them in a persistent, visible location — a filter bar at the top of the dashboard or a sidebar. The most common global filter is date range.
Widget-level filters affect only one chart or table. Place them within the widget’s header or as a dropdown on the widget itself. Use these sparingly — too many widget-level filters fragment the user’s mental model of what they’re looking at.
Filter Bar Pattern Core Pattern
Use when: A dashboard has 2+ global filters that users change frequently.
Place a horizontal bar below the header containing all global filters: date range picker, segment dropdown, comparison toggle. Key requirements:
Persistent visibility: The filter bar should be visible at all times (sticky positioning or always above the fold). If users can’t see what’s filtered, they’ll misread the data.
Active filter indicator: When any non-default filter is active, show a clear visual indicator (highlighted pills, a “Filtered” badge, or a count: “2 filters active”).
Clear-all: A single action to reset all filters to defaults. Never make users undo filters one by one.
Saved views: For power users, allow saving filter combinations as named views (“EMEA Q4 view”, “My team only”).
The invisible filter problem
The most dangerous dashboard bug is not a crashed widget — it’s a filter the user doesn’t know is active. If a date range filter is set to “Last 7 days” but the user thinks they’re looking at “All time,” every conclusion they draw is wrong. Always make the current filter state visible and unambiguous.
Data tables in dashboards
Tables are the most information-dense widget type. When users need exact values, sorting, and row-level actions, a table beats any chart. The challenge is making tables scannable at dashboard scale.
When a table beats a chart
Use a table when: the user needs to look up specific values, compare across many dimensions simultaneously, sort by different columns, or take actions on individual rows (approve, reject, edit). Use a chart when the user needs to see patterns, trends, or distributions.
Dashboard table patterns
Sorting: All columns should be sortable. Default sort should match the most common query (usually by date descending or by the primary metric). Show the sort indicator clearly.
Pagination vs. infinite scroll: For operational dashboards where users scan a known set of items, pagination with 20–50 rows per page. For exploratory analysis, virtual scrolling (render only visible rows). Never load all rows at once for large data sets.
Sticky headers: Always. When a table scrolls, column headers must remain visible. Without sticky headers, users lose track of which column they’re reading after three rows.
Row density: Compact row height (32–36px) for data-dense operational tables. Comfortable row height (48–56px) for tables with actions or longer content. Let power users toggle density.
Inline actions: For tables where users take actions (approve, assign, delete), show action buttons on hover or as a persistent column. Don’t bury actions behind a menu for the primary action.
Responsive table strategies
Tables wider than the viewport need a strategy. Options, from most to least data preservation:
Horizontal scroll — Pin the first column (identifier), let remaining columns scroll. Best for data analysts who need all columns.
Column priority — Hide lower-priority columns at narrower breakpoints. Show a “columns” control to reveal them.
Card transformation — Below 600px, convert each table row into a card with key-value pairs stacked vertically. Best for mobile when row count is manageable.
Drill-down and navigation
Drill-down is how users move from overview to detail without losing context. The goal is to let users investigate a data point without losing their place in the broader dashboard.
Drill-down patterns
Click-to-filter: Clicking a bar in a chart filters the rest of the dashboard to that segment. The clicked element stays highlighted, and all other widgets update. Best for dashboards where all widgets share the same data source.
Slide-out panel: Clicking a data point opens a detail panel (300–500px) from the right, showing the detail view while keeping the dashboard visible behind it. Best for operational dashboards where users need detail without losing the overview.
Detail modal: A full-screen or large modal showing expanded data. Use sparingly — modals break the user’s spatial context. Best for infrequent, deep-dive investigations.
Linked dashboards: Clicking navigates to a completely different dashboard focused on that segment. Use breadcrumbs to show drill-down depth. Best when the detail view is complex enough to warrant its own full dashboard.
Context preservation
The cardinal rule of drill-down: the user must always be able to get back. Use persistent breadcrumbs (“Overview > EMEA > Germany”), a visible “Back to overview” link, or the browser’s back button (which means drill-down states must be in the URL). If clicking “back” loses the user’s filter state or scroll position, the drill-down pattern is broken.
Data states and loading
A dashboard is not a static design — it’s a living interface with multiple possible states. Designing for every state is what separates a polished dashboard from a fragile one.
The Five Data States Core Framework
Use when: Designing any dashboard widget. Every widget must handle all five states.
Loading
Data is being fetched. Show a skeleton screen (gray placeholders matching the widget’s final layout) rather than a spinner. Skeletons communicate that content is coming and what shape it will take. Each widget loads independently — don’t block the entire dashboard waiting for the slowest query.
Populated
Data is present and displayed. This is the primary design state — what most mockups show. But it’s only one of five states you must design.
Empty
The query returned zero results. Don’t show a blank space or a generic “No data.” Explain why it’s empty (“No sales in this region during the selected period”) and suggest what to do (“Try expanding the date range” or “Remove the filter on region”).
Error
The data fetch failed. Show a clear error message in the widget itself — not a toast notification that disappears. Include a “Retry” button. Other widgets that loaded successfully should continue to display normally — never blank the entire dashboard because one query failed.
Stale
Data was fetched previously but may be outdated. Show a timestamp (“Last updated 15 min ago”) and a refresh button. For real-time dashboards, use a subtle pulsing indicator when data is live, and a static indicator when the connection is stale.
Independent widget loading
Each widget should fetch its data independently and render as soon as its data arrives. A KPI card that loads in 200ms should appear immediately, not wait for a complex chart that takes 3 seconds. This creates a progressive loading experience where the dashboard “fills in” naturally rather than blocking behind a single loading screen.
Dark mode and theming
Dashboards are frequently used in dark mode — network operations centers, trading floors, presentation screens, and by users who work in low-light environments. Dark mode for dashboards has specific challenges beyond inverting colors.
Chart colors in dark mode
Colors that work on a light background often fail on dark. Saturated blues and greens that pop on white can feel harsh on dark gray. Use slightly desaturated, lighter versions of your chart palette for dark mode. Test every chart in both modes — a color that provides good contrast on white may vanish against dark gray.
Card hierarchy through background levels
In light mode, cards “float” above the background using shadows or borders. In dark mode, cards are distinguished by background level: the page is the darkest, cards are one step lighter, and interactive or highlighted elements are another step lighter. Use a 3–5 level background scale (not more — the differences become imperceptible).
Text contrast on dark backgrounds
Pure white text (#FFF) on dark backgrounds causes halation — a glowing effect that reduces readability. Use off-white or warm gray (e.g., #D8D0C4 or #E0DDD6) for body text. Reserve pure white for hero metrics and primary headings only.
Responsive dashboard design
Dashboards face unique responsive challenges. A 12-widget grid that works at 1440px can’t simply reflow to a single column at 375px — the user would scroll through 20 screens of widgets. Responsive dashboards require priority-based decisions, not just layout reflow.
Which widgets survive the small screen?
At mobile widths, show only the Level 1 information: hero KPI cards and the single most important chart. Move everything else behind a “View full dashboard” link or a tab interface. The mobile dashboard answers “is everything OK?” and nothing more — detailed analysis happens on a larger screen.
Tablet strategies (768–1024px)
Tablets can accommodate a reduced dashboard: hero cards in a single row, primary chart at full width, secondary charts at half-width (2-column). Collapse the sidebar filter panel to a filter button that opens a slide-out. This is often the “minimum viable dashboard” — functional enough for meetings and quick checks.
Swipeable widgets on mobile
On mobile, consider a horizontally swipeable card carousel for KPI metrics and a vertically scrollable list for supporting charts. Each swipeable card should show one metric with full context. Pagination dots indicate how many cards are available. This pattern preserves the density of information while respecting the narrow viewport.
Accessibility in data-dense interfaces
Dashboards pose unique accessibility challenges because they pack many data elements into a small space. The key is providing alternative paths to the same information for users who can’t access it visually.
Screen reader strategies
Reading order: Ensure the DOM order matches the visual hierarchy. Hero metrics first, then primary chart, then supporting detail. A screen reader user should get the “is everything OK?” answer first, just like a sighted user.
Live regions: For real-time updating dashboards, use ARIA live regions (aria-live=“polite”) on KPI cards so screen readers announce when values change significantly. Don’t announce every minor fluctuation — set a threshold for what constitutes a meaningful change.
Chart alternatives: Every chart should have a text summary (via aria-label or a visually hidden summary) and a “View as table” toggle. The table alternative should present the same data in a fully accessible, sortable format.
Keyboard navigation
Users should be able to tab between widgets in a logical order, activate filters and drill-down interactions, and navigate data tables entirely by keyboard. Each widget should be a single tab stop, with arrow keys for internal navigation (e.g., moving between bars in a chart or cells in a table).
Zoom and text scaling
Dashboards must remain functional at 200% zoom (WCAG requirement). This means: avoid fixed pixel heights that clip content, use rem/em for typography, and ensure layouts reflow gracefully rather than requiring horizontal scrolling. Test by setting browser zoom to 200% and verifying every widget is still usable.
Templates and checklists
- Decision clarity: can you list the 3–5 decisions this dashboard supports?
- Audience defined: who is the primary user, and what is their skill level?
- Hero metrics: 3–5 KPIs at top with trend, comparison, and directional indicator
- Information hierarchy: inverted pyramid from summary to detail
- Filter discoverability: current filter state is always visible
- Clear-all filter: one action resets to defaults
- All five data states designed: loading, populated, empty, error, stale
- Independent widget loading: no single slow query blocks the entire dashboard
- Drill-down has breadcrumbs or back navigation
- Responsive behavior: mobile shows hero KPIs at minimum
- Dark mode: chart colors tested in both themes
- Accessibility: reading order matches visual hierarchy, charts have table alternatives
- 200% zoom: layout reflows without horizontal scrolling
- Five-second test: a stakeholder can tell if things are OK in a glance
Dashboard anatomy: three case studies
Case study
Analytics dashboard (product metrics)
A SaaS product dashboard for a product manager, checked daily. Hero metrics: DAU, activation rate, 7-day retention, MRR. Primary chart: DAU trend over 30 days with cohort overlay. Supporting: feature adoption table (sortable by usage), funnel chart (signup to activation to conversion), and a segment comparison (free vs. paid users).
Why it works: The hierarchy answers three questions in order: “Are we growing?” (DAU + MRR cards), “Are users sticking?” (retention card + cohort chart), “What should we build next?” (feature adoption table). Each level provides context for the one above it. Global filter: date range. Widget-level filter: user segment on the funnel chart.
Case study
Operational dashboard (system monitoring)
An infrastructure monitoring dashboard for a DevOps team, displayed on a TV screen in the office. Hero metrics: uptime percentage (green/red), p95 latency, error rate, active incidents. Primary chart: request volume over the last hour with error rate overlaid. Supporting: server status grid (green/amber/red dots per service), recent alerts list, and deployment timeline.
Why it works: Designed for wall display: high contrast, large type for hero metrics readable from 15 feet. The five-second test is critical here — an engineer glancing at the TV while walking by must instantly know if something is wrong. Auto-refreshes every 30 seconds. Dark mode default (wall-mounted displays). No interaction required for the primary view — drill-down happens on a laptop when investigating an alert.
Case study
Financial dashboard (portfolio reporting)
A financial reporting dashboard for a CFO, reviewed weekly with the leadership team. Hero metrics: total revenue, burn rate, runway (months), revenue growth rate. Primary chart: revenue vs. plan over 12 months (actual line + forecast line + plan shading). Supporting: revenue by product line (stacked bar), expense breakdown (horizontal bar sorted by amount), and AR aging table.
Why it works: Emphasis on comparison-to-plan. Every metric shows actual vs. target. The primary chart uses the “plan as shading” technique — a filled area showing the plan range, with the actual line drawn on top. Variance is visible at a glance: the line inside the shading means on-track; the line above or below means deviation. Exported as PDF for board meetings — the dashboard works both as interactive tool and static report.
Before/after: dashboard redesigns
Redesign
The “everything dashboard” → Focused decision support
Before: 18 widgets on one screen. Three different chart libraries with inconsistent styling. No clear reading order. Six pie charts (none with fewer than 8 slices). No KPI cards — every metric was buried inside a chart title. The team added every available metric because “someone might need it.”
After: Split into three dashboards: Executive (5 KPI cards + 2 charts), Operational (8 widgets with drill-down), and Analytical (dense, filterable, for data team). Each serves one audience with one purpose. Total widgets increased from 18 to 24 — but spread across three focused screens instead of one chaotic one. Usage went from “nobody opens it” to daily check-ins by each team.
Lesson: A dashboard that tries to serve three audiences serves none. Split by audience and decision type, not by available data.
Redesign
The “beautiful but useless” dashboard → Decision-first layout
Before: Visually stunning — smooth gradients, custom illustrations, animated transitions. Won an internal design award. Nobody used it. The CEO couldn’t tell if revenue was up or down without hovering over a chart, reading a tooltip, and doing mental math. The primary metric was a donut chart with 12 segments showing revenue distribution — but not total revenue.
After: Hero row with four KPI cards (revenue, growth, burn, runway). Each card shows: value, comparison, direction. The donut chart was replaced with a sorted horizontal bar showing the top 5 segments. Total revenue added as a KPI card. Five-second test: pass. The CEO now checks it every morning.
Lesson: Decoration is not design. A dashboard’s job is to communicate, not to impress. If the primary user can’t answer “is everything OK?” in five seconds, the dashboard has failed regardless of how it looks.
Common pitfalls
Serving three audiences on one screen
A CEO, a product manager, and a data analyst need different dashboards. Cramming all three views into one screen means every user sees 60% noise. Split by audience, not by data availability.
No information hierarchy
When every widget is the same size with the same visual weight, nothing is important — which means everything is noise. Hero metrics should be visually dominant. Supporting detail should be visually subordinate. The eye should have a clear reading order.
Designing only the “populated” state
Most dashboard designs only show what happens when data is present. But loading, empty, error, and stale states are equally important. A dashboard that shows a blank white space when a query fails is broken, even if the mockup looked perfect.
Inconsistent chart styles
Mixing chart libraries (one widget using Chart.js defaults, another using D3 with custom styles, a third using Recharts) creates visual chaos. All charts on one dashboard should share the same color palette, typography, grid line style, and animation behavior.
Using pie charts for comparison
Pie charts encode data as angles, which humans are poor at comparing accurately. For comparing values across categories on a dashboard, use horizontal bar charts sorted by value. They’re more compact, more accurate, and more scannable.
Real-time data without timestamps
A dashboard showing “live” data without a visible last-updated timestamp is a liability. Users don’t know if they’re seeing data from 10 seconds ago or 10 hours ago. Always show when data was last refreshed and provide a manual refresh action.
When to use this
Decision guidance
Use this topic when: You’re designing any screen that displays multiple data elements together — an analytics dashboard, an admin panel, a monitoring view, a reporting page, or a settings overview with metrics. Applies whether building custom or configuring a tool like Grafana, Metabase, or Looker.
Pair with Information Visualization when: You need guidance on the individual charts and graphics within each widget. This topic tells you how to arrange widgets; Info Viz tells you how to design each one.
Pair with Data-Driven Design when: You need to decide what to measure. Choosing the right metrics comes before designing the dashboard that displays them.
Don’t use this for: Single-chart views, data-light pages, or editorial/storytelling data pieces. Those are Information Visualization territory, not dashboard design.
Connected topics in your library
Appendix
Extended material for when you want to go deeper. Covers widget sizing, grid configurations, frameworks, and further reading.