Discover what a requested dashboard is really for

“We need a dashboard” describes a possible interface, not the work it must support. The first conversation should establish what people do with the information after they see it. Otherwise a new screen can reproduce the visible numbers while losing the notes and decisions that make the current process useful.

In this fictional project, a supplier coordination team requests a weekly dashboard of open reviews. The initial feature list includes counts, coloured states and a filter. During discovery, the team brings the pack used in its last meeting, with private details replaced by fictional records.

Follow the information beyond the display

The meeting pack contains ten open requests. Beside Q-31, staff have written that a drawing question must be answered before the next review. Beside Q-32, they have recorded an agreed follow-up owner and the reason the item remains open. At the next meeting, those annotations are the starting point for discussion.

The current export is awkward, but its value is not just a view of the application. It provides a stable meeting record and carries staff annotations forward. A live dashboard that refreshes the same rows without a place for those notes would leave the team maintaining a second document anyway.

The conversation therefore separates three objects: the current application state, the meeting's selected set of records and the annotations produced during that meeting. They should be related, but they are not interchangeable. A request may change after the meeting without making the earlier discussion record false.

Inspect the available route

The fictional application already supports a documented export containing stable request identifiers and current review states. The team can produce that export without a new provider subscription. It does not support the desired meeting annotations inside the application, and implementing a full collaboration interface would exceed the first release's agreed scope.

The developer prepares a small candidate pack from that export. Each row retains its request identifier, the state at preparation time and a separate annotation area. The pack records the meeting date and preparation time. The process carries unresolved annotations into the next pack through an explicit review, rather than assuming that every old note is still current.

This route does not automatically write meeting decisions back into the source application. That remains a named staff action through the existing approved process. The limitation is visible in the proposed scope, so a reader will not mistake a written note for an application state change.

Choose the first result through a worked meeting

The coordinator uses the candidate with Q-31 and Q-32. Q-31's drawing question remains unresolved and is carried forward with its original note and a current review decision. Q-32's follow-up has been completed, so the next pack retains the earlier meeting record but does not present the old action as still outstanding.

A new request Q-33 appears without inherited notes. Its blank annotation area does not receive Q-31's text merely because it occupies the same row position in the refreshed export. Stable request references allow staff to associate the right discussion with the right work.

The team selects the bounded pack and annotation handoff for the first release. Counts and filters remain useful but secondary. A live collaborative dashboard is deferred until the team can justify simultaneous editing or direct application updates that the pack cannot provide.

Capture what the conversation established

The resulting brief names the user, the weekly task, the existing export capability, the annotation requirement and the explicit boundary around source updates. Acceptance includes one carried-forward action, one resolved action and one new request. The future operator receives the preparation and review steps.

This is a better starting record than a list of dashboard components because it explains why the proposed result is useful. It also makes later expansion easier to assess: a new feature must improve a named part of the task, not merely make the interface more elaborate.

For your first conversation, bring an example of the output people actually use, including their handwritten or separate notes. Ask what must survive the next iteration and who decides whether it remains current. Send a project inquiry with that task, or organize it with the project brief.