Evaluate school software through the work it must support
Turn a feature checklist into a clear evaluation of workflows, usability, governance and implementation readiness.
Choose five priority tasks, name their users and define what successful completion looks like.
A useful evaluation asks people to complete representative tasks, explains the exceptions and records the evidence behind each decision.
01
Write the outcome before the feature
“We need admissions” is too broad to evaluate. “Our admissions team needs to identify incomplete applications and give each family a clear next action” describes a task and an outcome. Write requirements in that form before assigning a priority.
Include the people who do the work, not only the people who approve the purchase. A registrar, teacher, bursar and parent will notice different friction. Gather a small set of representative scenarios rather than asking every stakeholder to produce an unranked wish list.
Put it into practice. Choose five priority tasks, name their users and define what successful completion looks like.
02
Include the exception in the demonstration
Most systems can show a straightforward happy path. Ask what happens when a document is missing, a payment is duplicated, a learner transfers mid-term or a reviewer is absent. The exception often reveals the real level of institutional control.
Keep the scenario consistent across evaluations. Use fictional records, the same starting conditions and a shared scoring method. Mark a requirement as demonstrated, explained, dependent on configuration or unresolved so confidence does not exceed the evidence.
Put it into practice. Pair every priority workflow with one realistic exception and a question about recovery.
Evaluate school software through the work it must supportWrite the outcome before the feature → Evaluate access and usability as part of the taskSEE HOW THE WORK CONNECTS
Evaluate school software through the work it must support
Turn a feature checklist into a clear evaluation of workflows, usability, governance and implementation readiness.
- 01
Write the outcome before the feature
Choose five priority tasks, name their users and define what successful completion looks like.
- 02
Include the exception in the demonstration
Pair every priority workflow with one realistic exception and a question about recovery.
- 03
Evaluate access and usability as part of the task
Record both a successful user action and a deliberately restricted action for each critical role.
Illustrative workflow · Shape the details around your institution.
03
Evaluate access and usability as part of the task
A screen can look attractive while requiring too many steps or exposing information to the wrong role. Observe whether users can identify the next action, understand a status and recover from an error. Include small-screen, keyboard and assistive-technology needs in the review.
For access, ask how a role gains and loses permission. Test campus boundaries, guardian relationships and staff changes where they matter. A role name in a presentation is not enough to establish how restricted information is handled.
Put it into practice. Record both a successful user action and a deliberately restricted action for each critical role.
04
Make implementation part of the comparison
A proposed solution includes more than software. Compare the work required to configure academic structures, prepare data, connect existing systems and train the people who will use it. Identify who supplies each input and who accepts the result.
Request a written scope that separates configuration, migration, integrations, training and recurring service responsibilities. Where a dependency remains uncertain, record the assumption and the date or evidence needed to resolve it. This makes commercial comparisons more meaningful.
Put it into practice. Compare proposals against one agreed scope, with dependencies and exclusions visible alongside cost.
05
Keep a decision record
Create a short evaluation record for each requirement: its importance, the scenario used, evidence observed, owner and open questions. Separate mandatory requirements from preferences so a visually impressive feature cannot quietly outweigh a critical gap.
Before a decision, review unresolved items with the accountable stakeholders. Agree which must be resolved before contracting, which before launch and which can belong to a later phase. The result should explain why the choice serves the institution, not simply which demo was most memorable.
Put it into practice. Finish with an evidence-based decision note and an owner for every remaining condition.
KEEP EXPLORING
Another angle on the work.
What a connected student record should actually connect
A practical way to distinguish a shared identity from unrestricted access—and a useful handover from another copy of the same data.
Read the article
Plan a phased rollout around complete workflows
Choose a first phase that delivers a usable institutional outcome while keeping data, responsibilities and support connected.
Read the articleTURN THE READING INTO A USEFUL CONVERSATION
Bring your questions. Start with your context.
Use a workflow, a checklist or an unresolved decision to shape a tailored demonstration.