Team 4: Human Centered Incident Reporting Dashboard
October, 2025
Problem Statement:
The Incident Reporting Gap: Fear, Fragmentation and Failure
THE PROBLEM - Low employee engagement and a culture of blame lead to delayed, incomplete, or omitted security reports. The current process is intimidating and inefficient.
THE IMPACT - Critical security incidents are missed, creating major risk. Cybersecurity efforts are hindered by poor data quality, slowing response and preventing proactive defense.
THE SOLUTION - Implement a Human-Centered Dashboard designed for trust and anonymity to drive up reporting volume and standardize data, ultimately establishing a proactive, blame-free security culture.

Kanban (Agile)
A Kanban board is a visual project management tool that uses cards and columns to represent tasks and workflow stages, allowing teams to clearly see progress, manage work-in-progress (WIP) limits, and quickly identify bottlenecks. It serves as a dynamic, transparent, and collaborative system that ensures continuous flow, promotes process improvement, and enables teams to deliver value more efficiently by visualizing the entire project from start to finish.
Lessons Learned: Limiting WIP
Effective Kanban maintenance requires strictly limiting Work-In-Progress (WIP) to prevent context switching and drive faster delivery of value. The Backlog must be continuously refined by Business Analysts, ensuring the next stories are always "ready" with clear acceptance criteria to avoid team stalls. Critically, the board must function as an instant communication tool, requiring the team to standardize card information and immediately visualize and flag Blockers with clear requested actions to resolve bottlenecks swiftly.
Project Deliverables - By the Project Manager
The Project Timeline is a fundamental visual schedule that organizes and illustrates the sequence of tasks, milestones, and dependencies over a defined period, providing a clear roadmap from initiation to completion. It serves as a critical control and communication tool that enables the project manager to track progress, anticipate potential delays, manage stakeholder expectations, and ensure the project remains on schedule and within scope.
Lessons Learned: A living tool
Effective project calendar management hinges on making sure the timeline is a living, visible tool for accountability and for mitigating unforeseen setbacks. A crucial lesson learned was the necessity of proactive risk mitigation; when a developer unexpectedly failed to show up for the development phase, the team had to swiftly adjust the deliverables to a non-clickable prototype of the website. This decisive action ensured the project could maintain its overarching timeline, emphasizing that delivery dates must be prioritized over scope when facing resource constraints.

Project Deliverables - By the Product Owner
A Product Canvas is a one-page visual tool that captures the essence of a project—its purpose, scope, stakeholders, success criteria, risks, and more. It’s designed to foster shared understanding and alignment across teams, especially at kickoff or during major transitions.
Lessons Learned:
-
Additional details at this level lead into the User Story refinement and establish references to scope to keep focused and prevent scope creep.
-
This is the interim stage between the Project Charter and the details within the tasks and roles.

Project Deliverables - By the Product Owner
The Project Charter is a foundational document that strategically defines the purpose, structure, and operating norms of a team by outlining its mission, goals, roles, responsibilities, and decision-making processes. Serving as a crucial reference, the charter establishes a shared understanding of expectations, aligns team members around a common vision, and promotes accountability and transparency throughout the project lifecycle.
Lessons Learned:
Clarity in goals and testable results are critical for success.
RACI approach for the overall project begins at this level and is refined in the execution stages.
Identification of Users highlight the various security implications and functionality impacts.

Project Deliverables - By the Business Analyst
The Human-Centered Incident Reporting Dashboard Use Case diagram was designed to visualize how incidents are reported, assigned, escalated, resolved, and how the overall team performance are monitored across different roles in the organization. This visibility helps decision-makers identify bottlenecks, monitor response efficiency, and ensure accountability across teams.
Lessons learned:
-
Collaboration is key to every project success. Frequent validation sessions prevented misalignment and helped the team build something everyone trusted.
-
Early discussions revealed hidden needs, like escalation visibility and assignment tracking, reminding us that elicitation is never one-and-done.
-
Using use case and data flow diagrams made it easier for non-technical stakeholders to visualize the system and give meaningful feedback which in turn sharpened our skills.
-
Mapping how data moves between actors helped align the dashboard metrics with actual user actions.

Project Deliverables - By the Business Analyst
The Data Dictionary serves as the central repository for all data elements used across the project. It provides a standardized definition for every field, including its technical characteristics, acceptable values, data type, and business rules. Its primary purpose is to ensure data quality and consistency across the entire project, allowing the Business Analysts to align requirements with the development team, and ultimately guaranteeing that the cybersecurity team receives accurate, structured information for analysis.

Key Lesson Learned: Continuous Modification and Alignment
A critical lesson learned is that the Data Dictionary is not a static document but a living artifact that requires continuous, active maintenance. Because user requirements and business needs are often updated during the iterative prototype development process, the dictionary must be continuously modified to reflect these changes. This ensures that the technical development team (Developers) and the requirements gathering team (Business Analysts) remain perfectly aligned on what data is collected and how it is defined, preventing costly rework and maintaining the integrity of the structured input needed for the Admin Review Dashboard.
Project Deliverables - By the Business Analyst
User Stories are short, non-technical descriptions of a feature written from the perspective of the end-user (e.g., Employee, Cybersecurity Analyst). They what is needed and why (e.g., "As an Employee, I want the form to offer optional anonymity so that I report concerns without fear of blame."). The Acceptance Criteria are the detailed, testable conditions written by the Business Analysts that specify how the system must behave for the story to be considered complete and ready for the QA team (e.g., "The 'Submit Anonymously' checkbox must be functional"). Together, they ensure that the solution is built to meet the core business and user needs.
Key Lesson Learned: Testable Clarity Drives Quality
A critical lesson learned is that the true value of User Stories lies in the clarity and testability of their Acceptance Criteria. Poorly defined criteria lead to ambiguity, resulting in developers building the wrong feature and requiring significant rework. By ensuring that every criterion is verifiable and tied to a specific business need empower the QA team to write accurate test scripts, and ultimately ensure the final prototype meets the high standards for data quality and user experience.

Project Deliverables - By the UI/UX Designer
Wireframes (created using Balsamiq Cloud) serve as the essential, low-fidelity blueprints for the dashboard. They represent the skeletal framework of each page—including the Landing Page, Incident Report Form, and Status Tracking Page—focusing purely on layout, navigation, and content placement without any visual design elements. Their purpose is to quickly define the structure and user flow, ensuring that key elements, such as the option for optional anonymity on the form or the status updates on the tracking page, are strategically placed before investing time in the final, high-fidelity design.

Key Lesson Learned: Early Validation Prevents Costly Rework
A core lesson learned is that conducting early and frequent validation using low-fidelity wireframes is essential to prevent costly rework in later development phases. By keeping the wireframes simple, the UI/UX Designer can rapidly test the fundamental user flow and information hierarchy with key stakeholders. This process quickly identifies usability issues, such as confusion in the reporting steps or difficulty locating the Admin Review Dashboard features, ensuring that the final clickable prototype is based on a validated structure that effectively meets the goals of trust and efficiency.
Project Deliverables - By the QA/Tester
Testing Scripts
Test Scripts are the detailed, step-by-step instructions (created by the QA Team) used to verify that the dashboard meets the agreed-upon Acceptance Criteria for every User Story. They translate the requirements into actionable verification steps, ensuring features like the Incident Report Form and the Admin Review Dashboard function correctly. The scripts are crucial for systematically validating the solution, confirming the system is free of defects, and verifying that the final product adheres to the established business rules and user expectations.

Key Lesson Learned: Traceability and The Value of Backlogging
A critical lesson learned is that the effectiveness of testing is entirely dependent on traceability and the disciplined use of backlogging. While every test script must be directly traceable to specific Acceptance Criteria, the QA process often identifies features that are desirable but out of the current scope (e.g., advanced security controls like MFA). Backlogging these non-critical features is not only alright but essential during the prototype stage, as it keeps the team focused on validating the minimum viable product without getting stalled by larger, lower-priority tasks, ensuring the final deliverable meets the core business needs on time.
Solution: Reporting Dashboard
Landing Page
Starting with the Landing Page, the dashboard's purpose is to build user trust and encourage engagement by explaining its function and ensuring users that they are in a blame-free environment. Its features are built with clear instructions and non-technical language to simplify the reporting process, thereby achieving the goal of transforming passive employees into active participants in the organization's defensive measures.
Key Lesson Learned: Prioritizing Core Functionality
A key takeaway or design principle of this project is the prioritization of core functional flow over advanced features. A base level of functionality, such as the incident form and admin review process, is included. However, since the goal is to deliver a clickable prototype, essential real-world security enhancements like user authentication and system integration are explicitly out of scope.


Solution: Security Team Works Case
How the Team Works on the Incident Case
The incident reporting workflow begins with an Employee submitting an incident using the user-friendly Incident Report Form, which captures structured, category-based data and assigns a unique ID. The case is then routed to the Cybersecurity Analyst via the Admin Review Dashboard, which serves as the team's central workspace. The analyst reviews and logs the report and prioritizing the response. Once the analyst updates the report's status, the Employee can track the progress in real-time on the Status Tracking Page, ensuring transparency throughout the entire resolution process.
Key Lesson Learned: Workflow Visualization and Efficiency
A key lesson learned is the importance of workflow visualization to drive operational efficiency and clarity. The project requires the creation of Workflow Diagrams to map out and communicate the entire reporting and resolution process visually. This upfront effort ensures that the structured input from the report form directly translates into a faster, more consistent response time for the team.
Figma Link: https://www.figma.com/design/2ATTIZkYORVah5PPEnTBTn/Incident-Report-Dashboard?node-id=212-4801&t=JtDk9uETgF91pHJl-1
Solution: Reporting & Analytics
The Admin Review Dashboard ensures security teams receive complete and accurate information by standardizing input, which is essential for detailed analysis. For high-level leaders, the system must provide summary reports with charts and the ability to analyze trends over time. These analytics features are necessary to understand the organization's overall security posture, measure the impact of potential threats, and inform strategic defensive decisions.
Key Lesson Learned: Data Quality and Strategic Value
A key lesson learned is that improved data quality is the foundational requirement for providing strategic analytic value. The project's emphasis on a simplified, category-based report form directly addresses the stakeholder need to move beyond simple case counts to capture complete, consistent information. This focus ensures the data is of high enough quality to spot trends and prevent future issues, thereby directly satisfying the business objective of delivering actionable insights to Executives/ Managers and justifying the entire dashboard initiative.

Role of the Developer
The Developer role, although ultimately unfilled in practice for this iteration, was crucial for providing the technical context necessary to build the project deliverables. The Developer was responsible for implementing and maintaining the system, ensuring it was technically feasible and manageable. Specifically, their task was to take the annotated wireframes and requirements (User Stories) to build the functional prototype. Their input was required to ensure the design elements—like the simple form structure and the admin filtering interface—could actually be translated into a working model, even though the final output had to be adjusted to a non-clickable prototype due to resource constraints.
Key Lesson Learned: Mitigating Developer Absence and Scope Control
A critical lesson learned was the severe impact of a resource constraint and the immediate need for scope control. When the designated Developer did not show up to build the website, the team had to make a swift, high-stakes decision. The lesson is that maintaining the project timeline must take precedence over the original scope; the team opted to pivot the final deliverable from a fully clickable prototype to a non-clickable prototype supported by wireframes and documentation. This decisive action prevented a total project failure, highlighting the importance of having contingency plans and the willingness to adjust deliverables when essential team roles are unexpectedly unfilled.
Impact of the SDLC Experience Workshop
Team Impact
The Human-Centered Incident Reporting Dashboard project provided a high-impact, practical simulation of the SDLC, primarily demonstrating how structured methodologies manage scope, risk, and especially cross-functional communication. The experience highlighted a crucial lesson: while the weekly check-in is vital for overall alignment, the team identified an essential need for separate, role-specific meetings to effectively manage deep domain knowledge. For example, the Business Analysts needed dedicated time to refine the Data Dictionary and User Stories, the Developers and UI/UX Designer needed technical sessions to finalize wireframe feasibility, and the QA team required separate time to align Test Scripts with the latest requirements. This structure ensured that specialized teams could achieve focused clarity without wasting the time of the whole group on technical details that didn't pertain to them.
Key Takeaways Reinforced by the Experience
-
Risk Mitigation and Scope Control: The dramatic lesson of the Developer absence taught the team to prioritize the project timeline over the original scope, forcing the pivot to a non-clickable prototype to maintain commitment.
-
Validated Requirements and Traceability: The upfront effort of meticulously defining User Stories and Acceptance Criteria proved essential, creating an unbroken chain of traceability that verified the solution was constantly being built against core business objectives.
-
Reinforced Agile Disciplines (Kanban): The practical exercise of using the Kanban board confirmed that limiting Work-In-Progress (WIP) and continuously refining the Backlog are necessary to maintain efficient flow and prevent bottlenecks.