Design a data-rich dashboard or SaaS product

The brief

The problem to solve

Target users and assumptions

Users

• Network operations managers responsible for several clinics.
• Single-clinic practice managers.
• Clinic owners who check in weekly and want a summary.

Assumptions to test

• Managers care most about no-shows and empty appointment slots.
• Weekly comparisons matter more than real-time numbers.
• Managers want to act directly from the dashboard (for example send reminders), not only read it.
• Different roles need different default views.
• Managers do not trust numbers they cannot trace back to appointments.

Business goals and user needs

Scope and constraints

In scope

• Overview dashboard with role-based defaults.
• One drill-down view (for example no-shows by location, day and time).
• A data table of appointments with sorting, filtering and saved views.
• Metric definitions and empty, loading, error and partial-data states.
• Responsive behaviour for tablet; desktop first.

Constraints

• Data updates every hour, not in real time.
• Some clinics have little data (new customers), so averages may be misleading.
• Patient privacy: managers see appointment counts and times; clinical details are never shown.
• Engineers prefer a standard charting library: line, bar, stacked bar and simple tables.

Research plan

1. Interview four to six people who manage operations in any appointment-based business (clinics, salons, gyms, tutoring centres) about how they track performance.
2. Ask two participants to share (anonymised) examples of the spreadsheets or reports they use today.
3. Review dashboard and data visualisation guidance from reputable sources.
4. Analyse two or three analytics products with the competitor matrix.

Competitor analysis worksheet

Copy this grid into a spreadsheet or your design file. Fill one row per competitor you choose.

Interview questions

1. Walk me through how you check how your business is doing each week.
2. Show me a report or spreadsheet you use. What do you look at first?
3. Tell me about the last time a number surprised you. What did you do next?
4. Which numbers do you share with others, and how?
5. What questions are hard to answer today?
6. How do you know whether a number is good or bad?

Synthesis

1. List every question managers want answered; group them by frequency (daily, weekly, monthly) and role.
2. Map each question to the metric, comparison and drill-down needed to answer it.
3. Prioritise the questions for the first version with an impact and effort matrix.
4. Write metric definitions in plain language with the formula.

Problem statement and success metrics

Clinic network managers cannot see which locations and times are losing appointments until they build spreadsheets each week, so problems like rising no-shows are spotted late and staffing decisions rely on guesswork.

A starting draft. Rewrite it from your own research.

Success metrics

• In testing: time to answer three realistic questions (for example "Which clinic had the most no-shows last week?") compared with a spreadsheet baseline.
• In testing: accuracy of answers.
• In testing: participants can explain what a metric means using the in-product definition.
• After launch (planned): weekly active managers and reduction in data exports.

Information architecture and user flow

1. Define the information hierarchy: overview, then location, then day and time, then individual appointments.
2. Draw the flow from noticing an alert to taking action (for example enabling extra reminders for a location).
3. Design navigation between the dashboard, drill-down and table that preserves filters.

Sketching and wireframing

1. Sketch a "question-first" dashboard where each module answers one question in words.
2. Choose chart types for each question and justify them.
3. Wireframe the overview, drill-down and table on desktop, and the overview on tablet.
4. Wireframe empty (new clinic), loading, partial data, and error states.

UI, components and prototype

UI and component requirements

• Data visualisation guidelines: colour for categories and states, accessible palettes, labelling, number formatting.
• Components: metric card with comparison, chart module with title as a question, filter bar, date range picker, data table with sorting and column settings, saved view control, metric definition popover, alert banner.
• A density setting (comfortable and compact) for the table.
• Consistent number formats, units and time zones.

Prototype requirements

• An interactive desktop prototype covering the overview, one drill-down and the table with working filters for at least one scenario.
• Metric definitions accessible from every metric.
• An action from the dashboard (for example "Turn on extra reminders for Thursday afternoons at this clinic").

Usability testing and iteration

Testing plan

1. Recruit four or five people who manage schedules or staff in any service business.
2. Give them realistic questions to answer with the prototype, and the same questions with a sample spreadsheet.
3. Measure time, accuracy and confidence; ask them to explain one metric.
4. Note any chart that was misread.

Iteration

• Redesign any chart that was misread by more than one participant.
• Simplify the default view if participants struggled to find what needs attention.
• Retest the changed modules.

Accessibility checklist

Final deliverables

Portfolio case study outline

1. Summary: turning appointment data into weekly decisions.
2. How managers work today: spreadsheet insights.
3. From questions to metrics: the prioritisation.
4. Chart and layout decisions, including rejected options.
5. Designing for trust: definitions, drill-down and low-data states.
6. Testing: dashboard versus spreadsheet results.
7. Trade-offs with engineering constraints.
8. What to measure after launch.

Assessment rubric

Score yourself honestly, then ask a peer or mentor to score you. Aim for Competent on every row before calling the project finished.

Milestones

Tick tasks as you finish them. Progress is saved in this browser.

Optional extension challenges

• Design a weekly email summary that links into the dashboard.
• Design role permissions: what an owner, a network manager and a clinic manager can see.
• Design the compact density mode for the table and test it with power users.
• Write an analytics plan for measuring the dashboard's adoption.

Hints and worked example

Try the project yourself first. The worked example shows one way through, with illustrative content that is not real research.