Module 4 · Page 9 of 9 · 30 minutes

Use case III: Coffee shop dashboard

An agent can turn a dataset into a polished dashboard very quickly. But if you do not specify what the dashboard needs to help someone understand, it may simply generate whatever metrics and charts are easiest to produce. In this case, you will build an interactive dashboard, test whether it answers the intended questions, and compare two different workflows.

Difficulty · Beginner ~30 minutes Uses: Modules 1, 4

1. The business task

A small campus coffee shop operates three locations. Management is trying to better understand when each location gets busy and how demand changes throughout the day.

The dashboard should help answer three questions:

When is each location busiest?
Which products drive demand at different times of day?
How do demand patterns differ between weekdays and weekends?

Your task is to use the available transaction data to build a simple interactive dashboard that helps management explore these questions.

The important distinction The task is not simply to make a dashboard from the data. The dashboard is an output. The actual task is to build something that helps answer the three questions above.

2. Data available

transactions.csv — transaction-level coffee shop sales data.

The file contains fields such as:

Field	Description
`transaction_id`	Unique transaction identifier.
`timestamp`	Date and time of the transaction.
`location`	Coffee shop location.
`product`	Product purchased.
`category`	Product category, such as coffee, tea, food, or pastry.
`quantity`	Number of units purchased.
`unit_price`	Price per unit.

Notice that some of the information needed for the dashboard is not directly stored in the file. For example, the agent may need to derive the hour of day, day of week, weekday/weekend status, transaction totals, or other calculated fields.

3. Try it yourself

Start by exploring transactions.csv so you understand its structure, fields, and level of detail.

Then build the interactive dashboard using whatever workflow you are comfortable with. The finished dashboard should help answer the three business questions above. Feel free to iterate or try different approaches. Do the best job you can.

When you're finished, keep your dashboard. In the next step, you'll verify both the calculations and the behavior of the application.

4. Verify the output

A dashboard can look polished and still be wrong or unhelpful. Test your dashboard using the checklist below.

Check	Questions to ask
Purpose	Does the dashboard clearly help answer the three business questions?
Calculations	Are the metrics and derived fields calculated correctly? Is "busiest" defined consistently?
Aggregation	Are transactions, products, and time periods grouped at the correct level?
Interactions	Do filters and other controls update the relevant charts correctly, including when little or no data is returned?
Presentation	Are time periods ordered sensibly, and does each major visualization serve a useful purpose?

Does your dashboard pass all of the checks? Are there calculations, interactions, or design choices that you would want to revise before someone relied on it?

5. Two ways to build the same dashboard

Now let us compare two different workflows. Both use the same dataset and the same general task, but they differ in how much thought happens before the agent starts building.

Attempt 1 · Give the agent the data and ask for a dashboard

In the first attempt, I put transactions.csv in the project folder and gave the agent a simple instruction:

Prompt used

Using transactions.csv, build me a polished interactive dashboard
for the coffee shop.

Make it modern, useful, and easy to explore.

The result looked impressive. The agent generated summary cards, filters, and several charts. It included metrics such as total revenue, total transactions, average transaction value, top products, sales by location, and revenue over time.

What went wrong

The agent had to decide for itself what the dashboard should show. Because the prompt did not specify the business questions, it generated reasonable metrics and charts based mainly on the available fields.
A polished dashboard is not necessarily a useful one. Some visualizations were technically correct but did not help answer a meaningful business question.

Nothing about this workflow guarantees a bad result. The problem is that the instruction "build a dashboard" leaves the agent to infer what the dashboard is for. Because modern coding agents are good at producing plausible interfaces, those assumptions can be easy to miss.

A useful habit Do not start with the artifact alone: "Build me a dashboard." Start with what the artifact needs to accomplish: "Build a dashboard that helps answer these questions."

Attempt 2 · Start from the questions + Plan mode

In the second attempt, I kept the same project folder but switched to Plan mode. This time, the prompt described the questions the dashboard needed to answer and asked the agent to inspect the data before writing code.

Prompt used

I need to build an interactive dashboard using transactions.csv.

The dashboard should help management answer three questions:

1. When is each location busiest?
2. Which products drive demand at different times of day?
3. How do demand patterns differ between weekdays and weekends?

Before writing any code:

- inspect the data and understand its structure;
- identify any transformations or calculated fields that will be needed;
- propose the metrics, filters, and visualizations you would use
  to answer each question;
- identify any ambiguous definitions or implementation choices;
- ask me about those choices before finalizing the plan.

Do not build the dashboard yet.

The agent inspected the file first and surfaced choices that were easy to overlook. For example, it asked how busiest should be defined, whether product demand should be measured using units or transactions, and how time periods should be grouped.

After those questions were resolved, the plan explicitly connected each business question to the data and dashboard components needed to answer it.

Business question	Metric / transformation	Dashboard component
When is each location busiest?	Transaction count by location and hour	Hourly demand chart with location filter
Which products drive demand at different times?	Units sold by category/product and hour	Time-of-day product view
How do weekdays and weekends differ?	Hourly transaction count split by weekday/weekend	Comparative demand chart

Once the plan was approved, I asked the agent to build the dashboard according to the agreed definitions and then verify the result.

For example, after the dashboard was built, I asked:

Verify the dashboard before we consider it finished.

1. Independently recalculate the main metrics from transactions.csv.
2. Check that the filters update every relevant chart.
3. Check that hours and weekdays are ordered correctly.
4. Test combinations of filters, including cases that return no data.
5. Confirm that each major dashboard element helps answer one of the
   three original business questions.

Fix any issues you find.

This second workflow does not require a much longer initial prompt. The key difference is the sequence: understand the question → inspect the data → resolve ambiguities → plan → build → verify.

Why this matters When building an interactive application, there are more things to verify than whether the output simply "looks right." You need to check the underlying calculations, the transformations that feed the interface, and the way components behave when a user interacts with them.

The takeaway is not that you need to specify every chart before the agent begins. In fact, one advantage of working with an agent is that it can inspect the data and propose an implementation. But the agent should be proposing ways to answer the task you defined, rather than inventing the task from the data.

A good workflow keeps the human focused on the questions and important choices while letting the agent handle much of the technical execution.

Next · Module 5

Scaling up

→