ONISEP · Avenir(s) national programme
Avenir(s) national career-guidance platform
Designing the foundation of a public-service product used by students, teachers and school psychologists — under the constraints of a government design system and statutory accessibility.
01
Context & problem
Avenir(s) is the national career-guidance programme run by ONISEP, the French public agency for education and career information. The ambition: give every student a space to build their path over time — not another directory of job descriptions, but a tool usable in class, at home, and by the adults who support them.
The existing product had grown by accretion: every new module brought its own components, its own navigation and its own rules. That produced three problems at once.
- A usage problem. Students did not come back. The service was consulted like documentation rather than used like a tool.
- A systems problem. No shared interface language across modules, so design and engineering costs rose with every iteration.
- A regulatory problem. As a State operator, ONISEP is bound by RGAA — the French accessibility standard. Accessibility could not stay an end-of-cycle task.
How do you design a shared interface foundation, strictly compliant with the French State Design System, that accelerates teams instead of constraining them?
Three audiences, three logics of use
The student wants to project themselves forward and gives up quickly if the effort is not immediately rewarded. The teacher needs to review a whole class in minutes, between lessons. The school psychologist works on individual situations and needs depth, not summary. One design system had to serve all three without fragmenting.
02
Research & insights
The diagnosis was run with mixed methods, so that every design decision could be defended with evidence rather than opinion.
Semi-structured interviews — students, form teachers and school psychologists across 3 regional authorities, five-part guide
Survey responses, stratified by authority and academic track, ±2.8% margin of error at 95% confidence
Contextual-inquiry observations, in classrooms and guidance rooms
What the data showed
- 62% drop-off before the third screen. The journey demanded a long commitment before returning anything to the student.
- 1.4 sessions per student per term. Occasional use, never sustained tracking — even though the product was designed as a logbook.
- 71% of form teachers kept a parallel spreadsheet. The clearest signal of all: when users rebuild the tool next to the tool, that is not an adoption problem, it is a design problem.
Verbatims were coded through affinity mapping, surfacing four friction themes: unrewarded effort, no continuity between sessions, illegible progress, and the tracking burden on teachers.
“I fill it in, and then I don't know what it gives me. So next time, I don't fill it in.”
Competitive analysis
Benchmarking of French and European guidance platforms, alongside consumer products that get progression mechanics right (guided journeys, milestones, immediate feedback). The main lesson: perceived value has to arrive before the end of the journey, not at the end.
03
Exploration & solution
The redesign was organised around three design principles, agreed with Product Owners in framing workshops that brought together the product team, domain experts and representatives from schools.
1. Give something back at every step
The journey was re-cut into short sequences, each producing immediately visible output. Students no longer “fill in” a long form: they build a profile that sharpens as they go and stays available between sessions.
2. Make progress legible
A persistent progress state, visible on arrival, with explicit resumption where the student left off. Continuity between sessions became a property of the interface rather than an act of memory.
3. Give teachers the view they were rebuilding elsewhere
The most debated feature was settled by data: since 71% of form teachers kept a parallel spreadsheet, the interface had to provide a native, sortable class view, readable at a glance, that surfaces students who need support.
A rich onboarding flow had been proposed in workshop. Testing showed it moved drop-off rather than reducing it, so it was replaced by a genuinely useful first sequence under two minutes. The data overruled the team's intuition — mine included.
Prototyping and validation
High-fidelity prototypes in Figma, tested in three successive waves with students, form teachers and school psychologists. Each wave ended with a SUS measurement and a journey adjustment before the next.
04
UI & design system
As a State operator, ONISEP had to apply the DSFR — the French State Design System. That was not a constraint to work around but a foundation to exploit: proven components, documented accessibility, and consistency with the other public services users already know.
What I built on top of the DSFR
- Foundations respected to the letter: DSFR colours, typography, spacing and native components, with no fork and no cosmetic override.
- Product-specific patterns: the domain objects the DSFR does not cover — student progress card, teacher class view, assessment sequence — designed as compositions of DSFR components rather than as new components.
- Usage documentation: for each pattern, when to use it, its states, its edge cases and its accessibility criteria, so engineering never had to reinterpret a mockup.
Accessibility built into the foundations
RGAA criteria were treated as design criteria, not as a QA checklist: heading hierarchy defined in the mockup, tab order specified, contrast verified at source, text alternatives written by design rather than engineering, and focus states drawn explicitly.
Of applicable RGAA criteria met across the 7 audited screens
Screens put through a compliance audit
DSFR forks — every product pattern is a composition
Handoff
Specs written in Jira and Notion, continuous coordination with engineering, and deliverables adapted to technical constraints without compromising experience quality. Compliance QA ran on staging builds before release.
05
Impact & learnings
SUS score across 3 iterations — from “barely acceptable” to “excellent”
Applicable RGAA criteria met
Audiences served by a single interface foundation
What I took away
A regulatory constraint is an accelerator when taken on early. The DSFR could have felt like a creative ceiling. Treated as a foundation, it removed weeks of debate about already-solved components and concentrated design effort where it created value: the product's own domain objects.
A user rebuilding the tool next to the tool is the best brief you will ever get. Those 71% of parallel spreadsheets moved the design forward more than any ideation session.
Measuring is what lets you defend. Presenting a SUS score and a completion rate changes the conversation with non-designer decision-makers: you stop debating taste and start debating results.
What I would do differently. I would run the SUS measurement from the very first test wave rather than the second: the baseline would have been firmer, and the onboarding trade-off could have been settled an iteration earlier.