Mercer University · Fall 2026 Capstone
A focused workflow for defining outage scope, coordinating approvals, and preparing accurate stakeholder notifications.
Planning documents establish the problem, represented stakeholders, project boundaries, weekly schedule, and acceptance criteria. The available files below form the current planning baseline.
View the stakeholder map SVG reference
Evaluation approach: I am the developer and a primary intended user. This capstone uses a practitioner case study, scripted functional tests, and structured self-walkthroughs. No interviews, recruited prototype testers, or participant questionnaires are planned. Other operational stakeholders are represented roles.
Keep each update so changes to the original plan remain visible. Planned hours are estimates; actual hours have not yet been logged here.
Prepared the revised proposal, scope, weekly timeline, and success-measurement PDFs. Prepared the stakeholder map and added the supplied Figma design link. The evaluation plan now reflects practitioner self-testing.
Next: Publish this package, verify document links and Figma viewer access, and complete the design deliverables due October 26.
Actual effort: Not recorded. This entry does not claim that FTP publication or testing has been completed.
Date; original planned task; actual work; actual hours; evidence/version link; schedule variance; blockers; next action. Append a new dated entry each week rather than overwriting earlier entries.
Design deliverables will translate the planning requirements into interface, workflow, and data decisions. Formal design evidence will be linked when ready.
The midterm will include all planning and design components due by this milestone.
The development record will show what was built, how it was implemented, and what changed across versions.
Evaluate prototype version 3.0 or 4.0 against the design task list and success measurements through structured self-walkthroughs and scripted tests.
Report technical correctness and case-specific findings. Self-recorded task times describe my own performance. Developer familiarity and confirmation bias limit claims about unfamiliar users or broader usability.
The practitioner evaluation approach is documented for instructor review against the course's usability-testing requirement.
Earlier feedback identified confusion between a product outage and an entire-SSP outage. I added explanations to the initial Create Outage popup. Other comments concerned UTC entry, urgent selection within the 10-day waiting period, and internal approval notifications before planned-outage customer notices.
This historical feedback informs requirements. It does not establish measured usability results or commit this capstone to further participant testing.