2,880 possibilities. How many should the user see?

28th September 2026

Postgraduate research management is complicated.

In our previous white paper, Why PGR Management Is Deceptively Difficult, we used a deliberately simple model to illustrate how quickly that complexity can multiply. Just six ordinary dimensions of a research candidature produced 2,880 theoretical combinations.

That wasn’t an argument for 2,880 workflows. Quite the opposite.

It raised another question: If the software needs to understand all that complexity, how much of it should the user actually experience?

Our answer is: as little as possible.

The scarce resource is attention

Computing power isn’t generally the limiting resource in a modern university system. Human attention is.

Every notification asks somebody to stop what they’re doing and decide whether it matters. Every item on a dashboard competes with every other item. Every status requires interpretation. Every choice creates a small decision. And every unnecessary reminder makes it slightly easier to ignore the next one.

This matters particularly in postgraduate research because most of the people interacting with a PGR system have another primary purpose. Researchers are there to conduct research. Supervisors are there to supervise. Academic leaders are there to exercise judgement.

Administration is necessary, but proficiency in administration is not necessarily the desired outcome for these users. Learning how to operate the machinery should not become another task.

When helpful becomes noise

Notifications provide a good example. Imagine an institution with 9,000 users and 20 genuinely important PGR milestones. If each milestone generates three reminders before it is resolved, that’s already 540,000 milestone reminders not including repeat reminders. Now add candidature changes, forms, signatures, supervision, researcher development, thesis submission and examination. Then imagine treating every internal process step as something that should also be individually monitored, reminded and escalated. The numbers quickly become enormous, 10s of millions.

But the more important issue isn’t the number of emails. It’s the number of times we’re asking a human being to divert their attention. Automation doesn’t make attention free.

The reminder paradox

Reminders work. People forget things. People get busy. Emails get overlooked. Some deadlines are important enough to justify repeated prompting. But the relationship isn’t linear.

A second reminder may significantly increase the chance of action. A twentieth reminder is unlikely to be twenty times as effective. Worse, if a system routinely sends messages that users learn can safely be ignored, it begins teaching them something: messages from this system can safely be ignored. That reduces the value of the message that genuinely matters.

Good notification design therefore isn’t simply about sending fewer messages. It’s about preserving the signal.

Quiet → Nudge → Escalate → Conversation

We think there’s a useful way of thinking about this.

When everything is progressing normally, the system can remain quiet.

When useful action is approaching or overdue, it can nudge.

When something becomes materially overdue or risky, it can escalate.

And when repeated automated reminders are unlikely to change behaviour, perhaps the answer isn’t reminder number 17. Perhaps it’s a conversation.

The software can then do something much more valuable: give the person having that conversation the history, evidence and context they need. The white paper develops this four-stage intervention model explicitly. SkillsForge White Paper 2880 Po…

Busy underneath. Quiet on top.

Think about a modern car. It continuously monitors an extraordinary number of things: engine conditions, braking systems, tyre pressures, safety systems and much more. It doesn’t continuously tell the driver: Everything’s fine. It generally stays quiet until something requires attention.

Good PGR software can work in much the same way. Underneath the interface it can calculate dates, preserve regulatory history, monitor deadlines, evaluate states, manage permissions and identify exceptions. The sophistication is still there; the user simply doesn’t need to see all of it.

A mature PGR platform should be busy underneath and quiet on top.

A different test for PGR software

This also suggests some different questions universities might ask when evaluating systems. Rather than only asking “What can your system do?”, ask:

What does your system deliberately choose not to ask the user to do?

Ask what information it deliberately doesn’t show researchers and supervisors.

Ask when it stops sending reminders and escalates to a person.

Ask whether researchers, supervisors, administrators and institutional leaders each receive a deliberately simplified view of the same underlying candidature.

And ask whether automation has actually reduced administrative friction — or merely digitised it.

Because software sophistication shouldn’t be measured by how much machinery we expose. It should be measured partly by how much machinery users never need to think about.

Our latest white paper explores this argument in more detail:

2,880 Possibilities. One Simple Experience.

The complexity of PGR management is unavoidable. The experience of that complexity is not.