Skip to main content
~/hanru

Feature Toggles for AI Tools

Snapshot

Admins needed to turn AI features on and off for individual students, but the request arrived as two incompatible asks: a competitor-style profile system from marketing and exec, and the groups system the squad had already built. Shipped as an extension of groups: an org-wide baseline with group-level overrides.

Genio Admin is the tooling academic institutions use to manage how their students are supported. This work covered per-student control of the AI features in Genio Notes, plus filtered exports for reporting.

TO ADD, Product, role, timeline and stakeholder list to confirm, names, dates and exact titles.

Problem

AI tools in Genio Notes can conflict with a course’s academic policy, while some students genuinely need that support to work. Admins had no way to draw the line, they needed to switch AI features on and off per student, plus filtered exports showing where they were on.

Partway through, the shape of the work changed rather than the problem. Our PM went on leave, priorities moved while they were out, and the input arriving in their absence pointed two ways: leadership on when the work should happen, marketing and exec on what form it should take.

Constraints

The roadmap was already locked in. Our PM had nailed it down before going on leave. Feature toggles were on it, but further out.

A quarterly review moved them up. Leadership signalled that toggles were now the priority, with no PM in the room to translate that into something the squad could act on.

Marketing and exec wanted to match a competitor. They wanted feature management as a standalone “profile” system: a different architecture from the groups system the squad had already built.

TO ADD, Exact names, dates and roles for the review and the marketing/exec ask.

Turn an ambiguous priority signal into scoped work

The review produced a direction, not a brief: toggles matter more than the roadmap says. Normally a PM absorbs that before it reaches the squad; with no one in the seat it arrived raw, and the gap between “this is the priority” and “this is what we build next” had to be closed before any design work meant anything.

So I worked back from the signal: which parts were actually being asked for first, what that displaced on the locked roadmap, and what could ship without discarding work underway. That gave the squad a scope to commit to rather than a priority to interpret.

TO ADD, The specific asks and who they came from, quotes or notes from the quarterly review, and what was displaced on the roadmap.

Extend the groups system instead of building profiles

The ask was concrete: a standalone profile system, matching a competitor. But profiles meant a second parallel architecture for the same job: a rebuild alongside the groups system the squad had already built.

I argued for extending groups instead, on the grounds that the intent was competitive capability rather than that specific structure: managing AI features above the individual student. Groups already expressed that relationship.

So the gap between what was requested and what shipped was architectural, not functional, no profile system, but the capability the request was after.

TO ADD, The synthesis artefact, profile system vs. groups extension, weighed against what exec and marketing actually needed. To find or rebuild.

Ideation: the profile system explored: named presets, each toggling the same set of features.
Ideation, assigning a profile to selected users, with Profiles standing as its own section alongside Groups.

Split control into an org baseline plus group overrides

Inside that scope, a two-tier model across the three AI features Notes ships: an org-wide baseline plus group-level overrides. Institutions set policy once, and a course or cohort with different needs can depart from it without that call being made for everyone.

Ideation, configuring several groups at once, with features sorted into categories and settings copyable between groups.
Ideation: the case a group-based model has to answer: which settings win when a student belongs to two groups.
Ideation, showing the org-level and group-level state of each feature side by side on a single user.

Treat the toggle screen as an opportunity for delight

The control model answered the policy problem, but the screen was also a chance to push Admin past a purely utilitarian feel, so rather than fit the toggles into the existing page structure, I built a new layout for them.

TO ADD, Context for this section, what the delight opportunity actually was, and what specifically the new layout set out to fix.

Before: the organisation form as it stood: one long stacked column, with nowhere for feature management to live. The overhauled version is under Shipped.

Shipped

Feature toggles shipped as an extension of the existing groups system: an org-wide baseline for each of the three AI features in Notes, with group-level overrides on top, alongside the filtered exports admins needed for reporting. No parallel profile architecture was built.

Shipped: the organisation baseline, in the overhauled two-column layout: section intent on the left, controls on the right.
Shipped: the group override. Each feature carries its organisation default in the label, so an admin can see what they're departing from.

Outcome

A student who needs the support isn’t blocked by a blanket policy set elsewhere in the organisation, and an institution can restrict a feature without handling exceptions one student at a time.

TO ADD, Adoption or usage figures, if any are available.

Reflection

Most of this wasn’t interface work. Leadership set the timing, marketing and exec set the architecture, they pointed different ways, and the person who’d normally reconcile them was on leave. What I did was turn that into one direction the team could commit to.

The useful question turned out not to be “profiles or groups” but “what is the profile system actually for”: the request named a solution, and its intent was reachable another way. Asking that sooner would have got us here faster.