Designing A Prototype Kanban Dashboard For Real-Time Project Tracking

Project teams rarely suffer from a complete lack of information. The more common problem is that useful information is scattered across spreadsheets, email threads, enterprise systems, stand-up notes and specialist tools. A prototype Kanban dashboard can bring these signals into one visual workspace, helping teams understand what is moving, what is waiting and where delivery is at risk.

For the Chalmers Electronic Lean Research Team, or Celean, this type of work sits at the intersection of digital visual planning, lean project management and practical industry collaboration. The aim is not to create another reporting screen. It is to test how real-time project data can support better decisions while keeping the visual logic simple enough for engineers, supervisors, delivery leads and operational teams to use every day.

Start With The Decisions The Dashboard Must Support

A useful dashboard begins with decisions rather than graphics. Project participants may need to decide whether to start another task, escalate a blocked activity, move specialist capacity, change a delivery sequence or discuss an emerging dependency with a supplier. Each decision requires different information, so the prototype should first identify the questions that recur during planning meetings and daily coordination.

A Kanban board gives these questions a visible structure. Work items move through stages such as planned, ready, in progress, review and complete. The columns should reflect the team’s actual workflow rather than a generic software template. A product development group in Melbourne may need design review and verification stages, while a construction technology team in Brisbane may need procurement, site readiness and commissioning stages.

Real-time tracking does not mean every value must update every second. It means that the information is sufficiently current to support the rhythm of work. A dashboard refreshed at key events may be more trustworthy than a screen filled with constantly changing but poorly governed data. The prototype should define which signals deserve live treatment and which can be updated during a daily or weekly planning cycle.

Translate Kanban Signals Into A Clear Visual Model

The central visual model should make flow visible without overwhelming the people using it. Cards can show the task name, owner, priority, due date, work type and current status. Small visual markers can identify blocked work, external dependencies, quality concerns or tasks that have exceeded their expected cycle time. These markers should be consistent across screens and explained through a compact legend.

Work-in-progress limits are especially valuable because they show when a team has started too much work. A column that exceeds its agreed limit can change colour or display a warning, but the warning should prompt a conversation rather than act as a performance penalty. In lean software development and project environments, the purpose of the limit is to encourage finishing, collaboration and removal of constraints.

Ageing indicators provide another layer of insight. A card that has remained in testing for three days may be normal for one workflow and a serious concern for another. The prototype should therefore use configurable thresholds rather than fixed universal rules. A cycle-time view can show how long completed items took, while a cumulative flow diagram can reveal growing queues between stages.

The visual language should work on a large screen in a project room, on a laptop during a video call and on a mobile device used during a site walk. This matters in Australia, where teams may be distributed between Sydney, Adelaide and regional facilities. It also helps organisations accommodate hybrid work without making remote participants dependent on verbal updates from people in the room.

Build A Reliable Data And Integration Layer

A dashboard is only as credible as its data. The prototype should document where each field originates, who can change it and how often it is refreshed. Task status might come from an enterprise project system, delivery dates from a planning tool and dependency information from a team-maintained Kanban board. Combining these sources requires clear ownership and a visible distinction between verified data and manually entered estimates.

A lightweight architecture is appropriate for an early prototype. A data connector can collect selected records, a transformation layer can standardise names and statuses, and a dashboard service can present the information through cards, charts and alerts. The design should avoid replicating an entire enterprise resource planning system. It should expose the minimum useful dataset needed to understand flow and make timely decisions.

Identity and access controls should be designed from the beginning. A project member may need to edit a card, a manager may need cross-project visibility and an external partner may only need access to selected milestones. For Australian organisations, data handling also needs to account for the Privacy Act 1988 and the Australian Privacy Principles when personal information appears in task records, comments or user activity logs.

Integration should also accommodate imperfect connectivity. A supervisor working at a regional manufacturing or mining site may experience intermittent access, while a city-based office may operate with stable high-speed connections. A resilient prototype can cache recently viewed data, show the time of the last successful update and prevent users from mistaking a stale screen for a live operational picture.

Design The Interaction Around Team Habits

The dashboard should fit into existing planning habits rather than ask teams to maintain a second administrative system. If the daily meeting begins with blocked work, the first view should surface blocked cards and their owners. If weekly planning focuses on delivery risk, the dashboard should offer a filtered view of overdue items, ageing work and upcoming dependencies. Different roles can use the same data through tailored views.

Small interaction details influence whether the tool becomes part of normal work. Updating a card should require a few clear actions, with sensible defaults and keyboard support. A user should be able to open the relevant task record, identify the latest change and see its history without navigating through several unrelated screens. Colour should reinforce meaning, not carry meaning alone, since accessibility and varied display conditions must be considered.

The prototype can include comments, activity trails and lightweight notifications, but these features need discipline. Too many alerts create noise and encourage users to ignore the system. Notifications are most useful when they relate to a decision or obligation, such as a blocked item requiring an owner, a review waiting beyond its threshold or a dependency that has changed.

Australian working patterns add practical design considerations. Daylight saving differs between states, so timestamps should display clearly with the relevant local time zone when teams span New South Wales, Victoria, Tasmania and Queensland. Public holidays and shutdown periods also affect cycle-time calculations. A dashboard that treats every calendar day as a normal working day will produce misleading forecasts for many local teams.

Test The Prototype Through Real Project Scenarios

Prototype testing should use realistic work items rather than polished sample data. Select a small project with varied task types, dependencies and changing priorities. A product engineering team might provide design tasks, supplier decisions, testing activities and release milestones. A project delivery team could contribute procurement, installation, compliance and handover work. The point is to observe whether the visual model reflects actual coordination.

Run short sessions in which participants perform familiar activities: reviewing the board, identifying a stalled item, changing a priority, locating a dependency and explaining a delivery risk. Watch for workarounds. If people export the dashboard into a spreadsheet before making decisions, the prototype may be missing context. If they argue about data accuracy rather than discussing flow, governance and update responsibilities need attention.

Evaluation should combine usage evidence with qualitative feedback. Useful measures include the time needed to find a blocked item, the percentage of cards with current owners, the number of overdue tasks resolved and the frequency of manual corrections. These measures should support learning rather than become a simplistic scorecard for individuals.

Research and case material can help connect the prototype to established lean practice. A relevant lean software case study can provide context for examining flow, waste, feedback loops and the relationship between visual management and software delivery. The prototype then becomes a testable research artefact rather than just a custom reporting interface.

Connect The Dashboard To Governance And Improvement

A real-time project view changes how an organisation sees accountability. When a blocked item is visible, the system should help identify the constraint and the next responsible action, not simply expose the person associated with the card. Governance rules should define how status changes are recorded, how exceptions are escalated and how long historical data is retained.

Safety and compliance information deserves particular care. In sectors covered by Australian work health and safety obligations, a dashboard should not replace formal risk assessments, permits or incident systems. It can show that a safety review is required or that a control is incomplete, while the authoritative record remains in the appropriate specialist system. This separation prevents a visual planning tool from becoming an accidental substitute for regulated processes.

The research value of a prototype lies in comparing intended behaviour with observed behaviour. Teams may discover that a board encourages earlier escalation, reveals bottlenecks or exposes inconsistencies between planning systems. They may also find that some information is too sensitive, too volatile or too difficult to maintain. Documenting these findings is as important as refining the interface. Project updates, publications and industry collaboration records can help connect local observations with broader digital lean research; interested organisations can use the Celean contacts page to locate the appropriate project or research contact.

Practical Design Recommendations

A focused prototype can produce useful evidence without attempting to solve every project-management problem. The following principles keep the design grounded in flow, trust and everyday use:

• Begin with two or three recurring project decisions, then select only the data needed to support them.
• Model the team’s real workflow, including review, waiting, rework and external dependency states.
• Display data freshness, ownership and source information so users can judge whether a signal is reliable.
• Use work-in-progress limits, ageing markers and blocked-item views to make constraints visible.
• Test the dashboard with Australian time zones, public holidays, uneven connectivity and mixed office-site conditions.
• Measure whether the tool improves coordination and learning, rather than treating screen activity as productivity.

The strongest prototype is usually modest in scope. It may cover one project, a handful of workflow stages and a small set of trusted integrations. That narrow boundary makes it easier to compare the dashboard with existing meetings and reports, identify which visual signals change behaviour and decide which capabilities deserve further development.

A practical takeaway is to treat the dashboard as a shared decision surface: connect only trustworthy data, show the state of flow plainly, and make every visual signal useful during the next real project conversation.