Continuous Training Management for the Portuguese Scout Association

The Problem

Being a leader in CNE requires training, and maintaining it. Credits accumulate, unlock the next stage, and fall behind if they aren't renewed. The process existed, but there was nowhere to see where anyone stood. Leaders asked someone; coordinators did the maths by hand.

The structure had to be respected. Pathways (Educadores I–IV, Gestores Locais, Regresso ao Ativo) are made of Tronco Comum and Formação Específica modules, each with editions: city, dates, format, places and price.

One screen, two jobs. The leader asks where am I and what do I do next? The coordinator asks who needs my attention? These are different questions answered from the same data.

The existing workflow was email, spreadsheets and people's memory. We matched the spreadsheet on recording and differentiated on the one thing it can't answer: who's close to qualifying?

My Role

Product Designer for this module at AppX Digital, end-to-end on the design: information architecture, state model, flows, high-fidelity UI and handoff. That meant ten documented variants, with each filter and CTA tied to the business rule that governs it. I brought the alternatives and a recommendation; decisions were made with the team and the client.

The three-signal separation is the one I argued for hardest.

I updated the platform's existing visual language rather than creating a new one, because a module joining twelve others shouldn't bring a second grammar.

The System

Credits, eligibility and status are three separate signals.

A leader can have enough credits and still be NOT ELIGIBLE because a prerequisite module is missing, or be ELIGIBLE and enrolled in nothing. Collapsing those into one indicator produces wrong readings with real consequences: someone who believes they're halfway may actually be stopped.

Access cascades. Each level sees its own scope and everything below it.

The same three signals are the filters. What you read is what you filter.

Decisions

Three signals, three columns. Credits as a number with colour, ELIGIBLE or NOT ELIGIBLE, enrolled or not. When prerequisites are missing, the interface says how many modules are outstanding and keeps enrolment inactive.

Two panels in one view. Pathway and catalogue sit side by side, because the task is cross-referencing one against the other.

Signals before interaction. Every module shows whether it's mandatory or optional, whether dates are available, and its state, before any click. The CTA lives on the edition, because the real action is always enrolling in a specific one.

Ordered by proximity. The management view privileges closeness to the next pathway, and charts above the list give the overall picture before digging.

The question moves from “who's here?” to “who's closest to advancing?”

Excel export at the top. Mandatory adoption guarantees people open the system, but it doesn't guarantee they work inside it. A product that tries to erase the old tool just pushes the work out of sight.

Trade-offs

Tabs → both panels visible at once.
Costs: density. Watch: whether a leader can pick an edition without leaving the view of what's missing.

Always expanded → progressive disclosure.
Costs: one interaction for detail. Watch: whether people expand everything anyway.

One progress indicator → three separate signals.
Costs: three columns and three filters. Watch: whether they read as redundancy rather than distinction.

Alphabetical list → proximity to eligibility by default.
Costs: the interface assumes a priority.

Watch: the people furthest from eligibility, who most need help and are exactly who this ordering pushes down. This is the choice I'd watch first.

Testing & Metrics

To test the decision I was least certain about, proximity ordering, I ran a 20-minute usability test with five coordinators on the management view.

Who's closest to the next pathway? — 5/5 correct, average 46 seconds.
Who's falling behind and needs help? — average 1 min 47 s, 2.3× slower. 2/5 looked for the lowest credits first and missed people blocked by a prerequisite. This was exactly the risk I was testing.
Why can't this person enrol? — 4/5 found the missing prerequisite; one assumed credits alone were enough.

Spreadsheet counter-metric: asked whether they'd still keep their spreadsheet, 3/5 said yes, for planning and notes rather than out of trust. The product can replace the calculation without replacing every surrounding workflow.

What changed: proximity stays the default, plus a dedicated Needs attention filter for people who are overdue, blocked or behind.

Still to instrument (not running yet)

Hypothesis — explicit eligibility shortens the time to act.
Metric — days from ELIGIBLE status to enrolment in the next pathway.

Hypothesis — Needs attention produces action as well as visibility.
Metric — % of overdue credits brought current within 60 days; if this stays flat while the spreadsheet keeps circulating, visibility isn't converting into action.

Learnings & What's still open

Designing for the decision. The brief could have produced a list of leaders. The coordinator's job was deciding where to focus, so the decision came first and the data second.

The spreadsheet stayed. In a mandatory internal system, the risk is that people comply with the record and keep working somewhere else. So the export went inside the product.

I tested the decision I most wanted to test, and it confirmed the risk. The same ordering that helped 5/5 find who's closest slowed “who needs help” by 2.3×.

Still open: 20 minutes of comprehension isn't weekly use. The ten state variants hold in documentation, not in a running system. The Needs attention fix is untested, because it doesn't exist yet.