WS1.3 — Framework Pre-Filter

WS1.3 — Framework Pre-Filter: From 6 to 3

Purpose: Rigorous elimination of 3 frameworks as standalone navigation paradigms, with evidence from WS1.1 (framework analysis) and WS1.2 (workflow maps). Documents what to borrow from each eliminated framework and how the 3 surviving frameworks will be formed into hybrid candidates. Inputs: WS1.1-Navigation-Frameworks.md, WS1.2-Admin-Workflow-Maps.md, Interview Report, Capability Map Date: March 2026

Why 3 Candidates, Not 6

We have enough evidence — from the interview, capability map, framework analysis, and workflow maps — to eliminate frameworks that cannot serve as the primary organizing principle for the admin backend. This is not an abstract exercise: each elimination is grounded in specific workflow evidence and scored framework data.

The goal is not to discard these frameworks entirely, but to determine which can stand as the structural foundation of the navigation and which are better deployed as features within a different structure.

Eliminated Frameworks

1. Object-Based (Current State) — Eliminated

Verdict: Eliminated as a candidate. This is the baseline being replaced, not a candidate for selection.

Primary reason: The object-based model is the root cause of the problems this redesign aims to solve. The WS1.1 comparison matrix scored it lowest on Mental Model Match (2/5) and Billing Accommodation (2/5). The admin explicitly rejected this model's organizing logic: she thinks in "domains of responsibility, not data types" [Interview Q4].

Supporting reasons:

• Workflow evidence (WS1.2): Semester setup spans 19+ screens across 4+ sections because content types are grouped by object, not by workflow context. Student support requires 5-7 screens because student data is fragmented across People, Reports, and Appointments — each organized around its own object type.
• The Settings catch-all: Object-based navigation produces orphans — items that don't fit cleanly into any object category accumulate in Settings. The current Settings section has 11 sub-items, including Welcome Package (semester content), Teacher Assignment Criteria (TA management), and Payment Plans (billing). These are misplaced because the object model has no logical home for them [Interview Q6].
• The "Students Management" grab-bag: This screen under People contains Level 0 promotions, Live Session Holidays, and Support Links — none of which are student management. It exists solely because the object model couldn't place these items elsewhere [Interview Q6].
• No path to billing integration: Adding billing to the object model would create a "Payments" section, but billing is inherently relational — it connects students, semesters, and subscriptions. A flat object section doesn't solve the admin's need to see payment status in the context of a student profile or during semester close [Interview Q5, Q9].

Counter-argument (strongest case FOR): Object-based navigation is the simplest, most predictable model. It scored highest on Implementation Effort (5/5) because it requires zero changes. Secondary users (TAs, view-only admins) can navigate by noun recognition. If the problem were merely "things are in the wrong place," reorganizing objects would suffice. The problem, however, is structural — the model doesn't support relational workflows, and reorganizing objects doesn't fix that.

What to borrow:

• Noun-based discoverability in spoke sections. When a secondary user (TA or view-only admin) needs to find "students" or "appointments," they should be able to locate these by familiar nouns, even if the primary admin navigates by domain or dashboard. The surviving candidates should use object-like labels within their sections (e.g., a "Scheduling" domain still has "Appointments" and "TA Schedules" as recognizable sub-items).
• Stable, predictable secondary navigation. The object model's main virtue is that the sidebar never changes. Surviving candidates that include dynamic elements (hub alerts, phase-aware prompts) should keep the secondary navigation stable so occasional users aren't disoriented.

Workflow evidence for elimination:

2. Workflow/Task-Based — Eliminated as Standalone

Verdict: Eliminated as the primary organizing principle. Workflow concepts are borrowed as features within surviving candidates.

Primary reason: The admin is a power user with deep institutional knowledge who would be constrained by guided wizards for daily tasks. WS1.1 scored Workflow-Based lowest on Secondary User Fit (2/5) — TAs looking up a student's submission don't want to enter a "Handle Student Issue" flow. The framework also scored low on Billing Accommodation (2/5) because billing configuration (payment plans, coupons, family plans) needs a persistent home outside any single workflow.

Supporting reasons:

• Ad-hoc tasks resist workflow codification (WS1.2): Workflows 2 (student support) and 4 (daily monitoring) are unpredictable. "Check what TA a student is assigned to" or "look up whether a family is on a scholarship plan" are lookups, not procedures. A pure workflow model either forces these into artificial flows or leaves them homeless.
• Edge cases break workflows (WS1.2, WF3): Semester close involves teacher discretion overrides, semester length variations, and students near pass/fail thresholds [Interview Q3]. These edge cases require judgment, not a wizard step. Codifying them into a workflow produces either (a) a rigid flow that can't handle exceptions, or (b) a complex decision tree that's harder to maintain than the current system.
• Maintenance cost is high: When processes change — and the interview shows they change (automation rules evolve, semester lengths vary, new edge cases emerge) — every workflow must be updated. This is more expensive than updating data screens because workflows encode sequencing and logic, not just layout.

Counter-argument (strongest case FOR): Workflow-based navigation is the only framework that eliminates multi-screen hopping by definition — the workflow brings the screens to you. For semester setup (WF1), a wizard that walks through content creation, schedule setup, and email configuration would reduce 19+ screens to a guided sequence. For semester close (WF3), an enforced sequence of promotions-before-payments would prevent the cascading corrections that are the admin's biggest pain point [Interview Q3]. The workflow model's strength is transformative for infrequent, high-stakes, multi-step tasks.

What to borrow (these are concrete features, not vague concepts):

1. Semester setup checklist. Not a wizard that forces sequential completion, but a checklist dashboard that shows "Content: 5 of 8 types configured, Schedules: not started, Emails: 3 of 7 updated." The admin completes items in any order but can see what's missing. This borrows the workflow's completion-tracking without imposing its sequencing constraint. → Goes into all 3 candidates as a feature of the semester management area.
2. Sequenced semester close workflow. A lightweight workflow page for semester close that enforces: EOC review complete → promotions finalized → payment setup begins → deactivation. Not a rigid wizard, but a gated sequence where payment setup is literally blocked until promotions are marked complete. This directly solves the premature payment setup problem [Interview Q3]. → Goes into all 3 candidates as a feature within semester close.
3. Onboarding mode for new admins. If a secondary admin or replacement is using the system, workflow-style guided introductions per section can help them learn. This is a training feature, not a navigation structure. → Goes into all 3 candidates as an optional overlay.

Workflow evidence for elimination:

3. Phase-Based / Temporal — Eliminated as Standalone

Verdict: Eliminated as the primary organizing principle. Phase concepts are borrowed as features within surviving candidates.

Primary reason: WS1.1 scored Phase-Based lowest overall (8/20) and worst on Secondary User Fit (1/5). A navigation that changes based on the semester lifecycle is actively confusing to TAs and view-only admins who log in irregularly and expect a stable interface. The admin confirmed that phases overlap in practice — semester close preparation begins during the active semester, and setup for the next semester overlaps with close of the current one [Interview Q3].

Supporting reasons:

• Phase boundaries are blurry (WS1.2, WF3 + WF1 overlap): The workflow maps confirmed that Workflow 3 (semester close) and Workflow 1 (semester setup) overlap temporally — the admin is simultaneously closing one semester and setting up the next. A phase model that shows setup tools OR close tools, but not both, forces the admin to switch phases mid-task or maintain both simultaneously, negating the simplification benefit.
• The persistent layer problem: Items like student lookups, billing, and reports are needed in any phase. If these move to a persistent layer (always visible), the persistent layer grows large, undermining the phase model's core benefit of reducing visible options. WS1.1 identified this explicitly: billing is relevant across all phases and doesn't fit cleanly into any single phase.
• Phase detection is fragile: The system must know what phase it's in — either through automatic date-based detection (which interacts with the already-problematic manual semester status switching [Interview Q1]) or through manual admin toggling (which adds friction). The interview revealed that semester status switching is "manual and risky" — adding another layer of temporal state management compounds this risk.
• Phase-based navigation would be unique and unfamiliar: Unlike domain-based (standard sidebar), entity-centric (CRM-like), or hub-and-spoke (dashboard-first), a phase-adaptive nav has no widely-used precedent in admin tools. There's no mental model for users to import from other tools they've used.

Counter-argument (strongest case FOR): The admin naturally describes her work in three phases [Interview Q1, Q2, Q3]. The interview was literally structured around setup, active, and close phases because that's how she thinks about her year. A phase-based system would legitimately reduce cognitive load during any single phase by hiding irrelevant tools — during active semester, the admin doesn't need content upload tools; during setup, she doesn't need promotion tools. The framework also naturally produces the temporal awareness needed for automatic semester transitions [Interview Q1 wish: auto-activation based on dates].

What to borrow (concrete features):

1. Phase-aware dashboard prompts. Dashboard tiles that say "Semester close approaching: 4 items need attention" or "Setup progress: 5 of 8 content types configured." These surface temporal context without changing the navigation structure. → Goes into Candidate B (Hub-and-Spoke) as dashboard tiles, and into all candidates as contextual banners within relevant sections.
2. Automatic semester status transitions. The phase model requires temporal awareness infrastructure — knowing where the system is in the lifecycle. This same infrastructure enables the auto-activation/deactivation the admin requested [Interview Q1]. Building this capability doesn't require a phase-based nav — it just requires date-aware logic on the semester record. → Goes into all 3 candidates as a semester management feature.
3. Seasonal tool highlighting. Instead of hiding tools by phase, the nav can highlight phase-relevant tools without hiding others. A visual indicator (badge, color, pin) on "Promotions" during close phase, or on "Content Upload" during setup, provides temporal awareness without instability. → Goes into all 3 candidates as a UI enhancement.

Workflow evidence for elimination:

Surviving Frameworks

Domain-Based → Candidate A: Domain-First with Rich Entity Pages

Why it survives: Highest Mental Model Match (5/5) — the only framework the admin herself proposed [Interview Q4]. The WS1.1 analysis confirmed it dissolves the Settings catch-all, separates Students and Teachers into logical domains, and naturally accommodates billing as a new domain. It scored 16/20 overall, tied for the highest.

Key risk to monitor: Cross-domain workflows still exist. Semester close touches Student Management, Billing, and Semester Management — three domains. The domain model reduces section hopping compared to the current object model but doesn't eliminate it entirely. Watch for this in the WS1.5 walkthroughs.

Hybrid formation: Domain-Based provides the navigation structure. Entity-Centric concepts provide depth within domains — rich student profiles, semester hubs, TA dashboards. Workflow concepts provide the semester setup checklist and sequenced close workflow. Phase concepts provide seasonal highlighting within sections.

Hub-and-Spoke → Candidate B: Hub-and-Spoke with Domain Sections

Why it survives: Scored 16/20 overall (tied highest), with the best Secondary User Fit (5/5) and Billing Accommodation (5/5). WS1.2 showed that Daily Monitoring (WF4) — the most frequent workflow — is currently the most broken because the dashboard provides zero actionable data. Hub-and-spoke directly addresses this by making the dashboard the operational nerve center. It also scored highest on billing because failed payment alerts are the most natural dashboard tile possible [Interview Q7].

Key risk to monitor: The hub is only as good as the alert logic behind it. Planned work (semester setup) is proactive, not reactive — the dashboard model is weakest for the admin's most painful workflow (WF1). Watch for whether the hub actually reduces clicks for all 6 workflows or just for WF4 (monitoring).

Hybrid formation: Hub-and-Spoke provides the dashboard layer. Domain-Based concepts provide the spoke sections' organization (not just flat object lists). Phase concepts provide phase-aware dashboard tiles. Workflow concepts provide guided checklists that appear as hub tiles during relevant phases.

Entity-Centric → Candidate C: Entity-Centric with Contextual Navigation

Why it survives: Scored 4/5 on Mental Model Match — the admin's most concrete, specific request in the entire interview was a consolidated student profile showing "level, TA, gender, semester history, submission count, and payment status" on one screen [Interview Q2]. WS1.2 confirmed that Student Support (WF2) is the workflow where entity-centric shines most: the admin already follows an entity-centric pattern (find student → investigate → act) but must traverse 5-7 screens to do it. The entity model collapses this to 1-2 screens.

Key risk to monitor: Implementation effort scored 1/5 — the highest development cost of any framework. Cross-entity workflows (semester close, daily monitoring) are awkward because they involve bulk operations across multiple entities. The framework needs supplementary structures for aggregate/bulk work.

Hybrid formation: Entity-Centric provides the depth layer — rich entity pages for Students, Semesters, and TAs. Domain-Based concepts provide the top-level navigation for cross-cutting areas (billing overview, reports, admin tools). Hub-and-Spoke concepts provide a lightweight dashboard for alerts and monitoring. Workflow concepts provide sequenced operations pages for bulk tasks.

Transition to Step 1.4: How Each Candidate Is Formed

The three candidates are not pure implementations of their surviving framework — they are hybrids that incorporate borrowed elements from all frameworks:

Each candidate emphasizes a different layer of the experience:

• Candidate A emphasizes organizational structure — the right things in the right places, with depth where it matters.
• Candidate B emphasizes operational awareness — the system tells you what needs attention, then you resolve it.
• Candidate C emphasizes entity depth — everything about a student, semester, or TA in one place.

These are not competing philosophies — they are complementary emphases. The evaluation in WS1.5 will determine which emphasis produces the best outcomes across all 6 workflows.

Borrowed Elements Summary

Every surviving candidate should incorporate these features regardless of which framework provides the structural foundation: