WS1.5 — Candidate Evaluation

WS1.5 — Candidate Evaluation

Purpose: Systematic evaluation of 3 navigation candidates by walking each through 6 real admin workflows, scoring on 7 criteria, and producing a data-driven recommendation with sensitivity analysis and risk assessment. Inputs: WS1.2 (workflow maps), WS1.3 (pre-filter), WS1.4 (candidate structures), Interview Report Date: March 2026

Part A: Workflow Walkthroughs (6 Workflows x 3 Candidates)

Each walkthrough traces the exact screen path an admin would follow using the candidate's navigation tree from WS1.4, then measures screen count, click estimate, information co-location, external tool dependencies, billing accessibility, and improvement over the current state documented in WS1.2.

Workflow 1: Set Up a New Semester

Current state (WS1.2): 19+ screens | 50-80+ clicks | 3 external tools (Vimeo, Sheets, InfusionSoft) | Pain: Critical

Workflow 2: Handle a Student Support Issue

Current state (WS1.2): 5-7 screens | 15-25 clicks | 3 external tools (Stripe, Sheets, Email) | Pain: High

Workflow 3: Close a Semester / Promote Students

Current state (WS1.2): 8+ screens | 40-70+ clicks | 3 external tools (Stripe, Sheets, Email) | Pain: Critical

Workflow 4: Daily Monitoring / Operations

Current state (WS1.2): 4-5 screens | 12-18 clicks | 3 external tools (Stripe, Sheets, Email) | Pain: High

Workflow 5: Manage Appointments / Scheduling

Current state (WS1.2): 4-6 screens | 12-20 clicks | 2 external tools (Sheets, Email) | Pain: Medium

Workflow 6: Onboard / Manage a TA

Current state (WS1.2): 6-8 screens | 20-35 clicks | 1 external tool (Sheets) | Pain: Medium

Part A Summary: Screen Count Comparison

All three candidates achieve near-identical external tool elimination. The differentiation is in screen consolidation and click reduction.

Part B: 7-Criterion Scoring Matrix

Each criterion is scored 1-5 (5 = best). Every score includes evidence from the walkthroughs and source documents.

Criterion 1: Screen-Hop Reduction

Metric: Average screen count across all 6 workflows compared to current state. Lower screen count = higher score.

Rationale:

• Candidate C (5/5): Achieves the lowest average screen count because entity pages absorb screens as tabs. WF1 (semester setup) drops from 19+ to 4-5 — the single largest improvement of any candidate on any workflow. WF6 (TA onboarding) drops from 6-8 to 1-2. The entity model's strength is depth — everything about a student, semester, or TA on one page.
• Candidate A (4/5): Rich entity pages within domains consolidate well for entity-centric workflows (WF2, WF6), but content screens remain standalone items in the Content domain, preventing the deep consolidation C achieves for WF1.
• Candidate B (3/5): Standard list/detail pages in spokes mean less consolidation. WF6 is particularly weak — 5-6 screens because TA-related tools remain separate pages within the Teachers spoke. The hub model optimizes WF4 (monitoring) but doesn't reduce screens in other workflows.

Criterion 2: Mental Model Match

Metric: Does the candidate's top-level navigation match the admin's Interview Q4 description? Her proposed structure: (1) Student Management, (2) Semester Management, (3) Content, (4) Scheduling, (5) Teacher Management, (6) Reporting, (7) Misc/Admin.

Rationale:

• Candidate A (5/5): The sidebar is an almost exact implementation of the admin's Q4 description. The 8 domains (Dashboard + Student Management + Semester Management + Content + Scheduling + Teacher Management + Billing & Payments + Reporting + Admin & System) map directly to her seven categories, with Billing added as the new domain she explicitly requested [Q5, Q9]. The labels match her vocabulary. A TA or view-only admin can navigate by recognizing the same domain names the admin uses in conversation. This is the only candidate whose top-level structure was proposed by the user.
• Candidate B (4/5): The spoke sections use the same domain labels as A (Students, Semesters, Content, Scheduling, Teachers, Billing, Reports, Admin), so the vocabulary matches. However, the primary interaction model is dashboard-first — the admin's Q4 description was about sections she would navigate to, not about a dashboard she would monitor. The hub model changes the way she interacts with the system (reactive/alert-driven) rather than mirroring how she thinks about it (domains of responsibility). She described wanting "restructuring by the six domains" [Q9], not "a dashboard that tells me what to do." Partial credit because the spokes do match.
• Candidate C (3/5): The top-level navigation (Students, Semesters, Teachers, plus cross-entity sections) does not match the admin's Q4 vocabulary. She proposed "Content" as a standalone domain; in C, content is absorbed into the Semester Entity Page. She proposed "Scheduling" as a standalone domain; in C, scheduling is a cross-entity section. She proposed "Semester Management" as a domain with its own tools; in C, everything about a semester lives on one entity page, and the top-level nav item is just "Semesters" (an entity list, not a management domain). The entity-centric model is structurally sound, but the admin would need to learn a new mental model — "which entity am I working with?" — rather than using the domain-based model she already carries.

Criterion 3: Secondary User Learnability

Metric: Simulate "I'm a TA, I need to check a student's submission status." Score the discoverability path.

Rationale:

• Candidate A (5/5): TA sees reduced sidebar: My Students, My Schedule, My Groups, Recordings. "My Students" is immediately recognizable. Click a student name → Student Detail Page → Submissions tab. The noun-based labels ("Students," "Submissions") provide clear affordance. The TA never needs to understand the domain concept.
• Candidate B (5/5): TA sees filtered Dashboard with their own alerts ("3 submissions awaiting review >48hrs") plus My Students, My Schedule, My Groups. The alert on the Dashboard may actually make this the fastest path for a TA — they see the submission count without navigating. If they want a specific student, "My Students" is equally obvious.
• Candidate C (5/5): TA sees My Entity Page (their TA profile), Student List (filtered to their students), Dashboard. The Student List → click student name → Student Entity Page → Submissions tab. Noun recognition works. The entity model is intuitive for TAs because a TA's natural question is "which student?" — they already think in entity terms.

All three candidates achieve high learnability for this specific task because all three use recognizable noun labels ("Students," "Submissions") and because the TA view is role-filtered to show only relevant items. Differentiation on this criterion is negligible.

Criterion 4: Billing Accommodation

Metric: Does billing fit naturally into the navigation model? Assessment considers (a) student-level billing accessibility during workflows, (b) aggregate billing placement, and (c) whether billing feels native or bolted-on.

Rationale:

• Candidate A (5/5): Billing fits at two levels. Student-level: the Student Detail Page's Payments tab embeds full Stripe data, family plans, and scholarship/deferment information directly in the student context — the admin never leaves the student profile for billing questions [directly solves Q2, Q5]. Aggregate-level: the Billing & Payments domain is a natural peer to the other domains (Student Management, Semester Management, etc.) and houses Payment Overview, Family Plans, Scholarships & Deferments. The domain model naturally accommodates billing because billing is a domain of responsibility [Q9: "if adding one thing: billing and payment management"].
• Candidate B (3/5): Billing lives in a standalone Billing spoke (aggregate views) and as an enhanced field on student detail pages (student-level). The gap is depth: student detail pages show a payment status summary but not full billing data — detailed investigation requires clicking through to the Billing spoke, breaking the student context. During WF2 (student support), this adds 2-3 clicks and a context switch. During WF3 (semester close), payment verification requires spoke-switching. The dashboard surfaces billing alerts well (failed payment tiles), so detection is strong, but resolution requires navigation. Billing is workable but not seamlessly integrated at the student level.
• Candidate C (5/5): Billing fits most deeply. Student-level: the Student Entity Page's Payments tab is the richest of any candidate — full payment history, subscription management, family plan details, and inline actions. This is the deepest billing-in-context integration. Aggregate-level: Cross-Entity Billing section provides overview and configuration screens. The entity model naturally accommodates billing because billing is a property of the student entity — it answers the question "what is this student's financial relationship with us?" directly on the student page.

Criterion 5: Scalability

Metric: Test by adding 3 hypothetical features: (1) Student App Issue Reporting, (2) TA Performance Reviews, (3) Content Versioning. Assess where each feature goes and whether the placement is clean.

Rationale:

Student App Issue Reporting:

• A: Goes under Student Management (student-facing) or Admin & System (system-level). Clear placement, slight ambiguity between two domains.
• B: Goes into Admin spoke as Issue Queue, with a Dashboard alert tile. This is the cleanest placement — B already specifies an Issue Queue in WS1.4 and surfaces it as a dashboard tile. The hub model is purpose-built for surfacing new alert types.
• C: Goes into Admin Tools or as a new cross-entity section. Slightly awkward because issue reporting does not attach to a single entity — it crosses students (who report) and admin (who resolve). Would need a new cross-entity section.

TA Performance Reviews:

• A: Goes under Teacher Management, as a sub-item alongside TA Reports. Or as a new tab on the TA Detail Page. Clean — the domain already has a "TA Reports" screen and a Performance tab on the TA Detail Page.
• B: Goes under Teachers spoke, as a new screen or enhancement to TA Reports. Also links from Dashboard as a tile ("2 performance reviews due this week"). Clean.
• C: Goes as a new tab or sub-tab on the TA Entity Page. The entity page is already large (5 tabs); adding another tab or deepening the Performance tab is feasible but begins to stretch the entity page's tab count.

Content Versioning:

• A: Goes under Content domain as a version management feature per content type. Clean — content has its own dedicated domain section with standalone screens per type.
• B: Goes under Content spoke, same as A. Clean.
• C: Content is absorbed into the Semester Entity Page's Content Status tab. Content Versioning would need to be either (a) a feature within the Content Status tab, making the already-complex Semester Entity Page even more complex, or (b) a new cross-entity Content Management section, which partially reverses the entity model's design decision to embed content in semesters. This is the messiest placement.

Scoring:

• Candidate B (5/5): The hub-and-spoke model is the most extensible because new features can be added as spoke items (low disruption) and surfaced on the dashboard as alert tiles (high visibility). The dashboard is a natural aggregation point for any new monitoring need. The spoke structure is flat — adding a screen to a spoke requires no restructuring.
• Candidate A (4/5): The domain model accommodates new features cleanly when they belong to an existing domain. Slight ambiguity arises when a feature crosses domains (Issue Reporting: Student Management vs. Admin), but this is a minor judgment call, not a structural problem.
• Candidate C (3/5): The entity model is constrained by entity page complexity. Each new feature that relates to an entity either adds another tab (increasing tab count) or requires a new cross-entity section (increasing the number of cross-cutting areas). Content Versioning is the clearest problem — the design decision to absorb content into the Semester Entity Page creates friction when content-specific features are added. The entity model's depth advantage becomes a scaling liability when entity pages accumulate too many responsibilities.

Criterion 6: Catch-All Risk

Metric: Count orphan items — items that do not fit cleanly into the candidate's primary organizing framework and must be placed in a residual "other" section.

Rationale:

• Candidate A (4/5): The Admin & System section contains Admins, Settings (General), Notifications, and Support Links — 4 items that are system-level utilities, not domain-specific. This is a smaller catch-all than the current 11-item Settings, but it still exists. Logs going to Reporting is somewhat orphan-like (system logs are not analytics). Total ambiguous placements: 2-3 items.
• Candidate B (5/5): The Admin spoke has the same items as A's Admin & System section (Admins, Settings, Notifications, Support Links, Issue Queue), but the hub-and-spoke model treats the Admin spoke as a legitimate spoke, not a catch-all. The dashboard provides a universal entry point for any item that is hard to categorize — if something doesn't fit in a spoke, it can still surface on the dashboard as a tile. The hub acts as a structural pressure valve, reducing orphan pressure on spokes. Total ambiguous placements: 1-2 items.
• Candidate C (3/5): The cross-entity sections (Scheduling, Billing, Reports, Operations, Admin Tools) total 5 sections, meaning roughly half the top-level navigation is cross-entity material that does not fit the entity model. Operations is a single screen in its own top-level section — an orphan by definition. Cross-Entity Reports contains 7 items (Student Report, Promoted Students, Failed Sign Ups, Referrals, Specific Reports, Student Composition, Logs) — this is a large residual section. The entity model's strength (deep entity pages) creates its weakness (everything that does not attach to an entity needs a cross-entity home). Total orphan items: 4-5 (Operations as a standalone section, the entire Reports cross-entity section being a residual catch-all, Logs).

Criterion 7: Implementation Effort

Metric: How much development effort is required beyond sidebar reorganization? Categories: Nav-only (lowest), Moderate restructuring, Significant rearchitecture (highest).

Rationale:

• Candidate A (3/5): WS1.4 estimates 70% of placement changes are nav-only. New development: Student Detail Page (high effort — 6-tab multi-tab page with Stripe integration), Semester Hub Page (high effort — multi-tab with setup checklist and close workflow), TA Detail Page (medium effort), Dashboard (medium-high effort), Billing screens (high effort — shared across all candidates), Calendar View (medium effort). Total new screens: 13. The three entity pages are substantial but can be built incrementally.
• Candidate B (4/5): WS1.4 estimates 70% of placement changes are nav-only (same sidebar reorganization as A). New development: Dashboard alert system (high effort — the centerpiece, requiring alert detection logic, Stripe webhooks, threshold configuration), Semester Setup Checklist and Close Tracker (medium effort each), Calendar View (medium effort), Billing screens (high effort — shared), Issue Queue (medium effort), enhanced student/TA detail pages (low-medium effort — adding fields, not multi-tab rebuilds). Total new screens: 10. The dashboard alert system is the single largest investment but is one focused subsystem rather than three separate entity page rebuilds. Entity pages are simpler (enhanced list/detail, not multi-tab), reducing per-page complexity.
• Candidate C (2/5): WS1.4 estimates only 40% of placement changes are nav-only — 60% involve embedding existing screens as tabs on entity pages, requiring new page architecture. New development: Student Entity Page (high effort — the most complex single deliverable), Semester Entity Page (very high effort — embeds 7 content types, email management, tags, welcome package, and close workflow; described as "essentially a mini-application" in WS1.4), TA Entity Page (high effort — absorbs schedules, reports, assignment criteria), Global search (medium effort), Dashboard (medium effort — lighter than B), Billing screens (high effort — shared), Calendar View (medium effort). Total new screens: 14. The Semester Entity Page alone is the highest-effort single screen across all candidates. Three complex entity pages must be built, each aggregating data from multiple backend services.

Scoring Matrix Summary

Part C: Preliminary Recommendation

Recommended Candidate: A — Domain-First with Rich Entity Pages

Candidate A scores highest overall (30/35) and — critically — achieves the highest or tied-highest score on the two criteria that most directly address the admin's stated needs: Mental Model Match (5/5) and Billing Accommodation (5/5).

Where Each Candidate Has a Decisive Advantage

Trade-Offs of the Recommended Candidate (A)

1. WF1 (semester setup) is not as consolidated as C: Candidate A reduces WF1 from 19+ to 10-12 screens, but Candidate C achieves 4-5 screens by absorbing content into the Semester Entity Page. A's Content domain keeps content screens standalone, meaning the admin still navigates between Semester Management and Content during setup. Mitigation: The Setup Checklist tab on the Semester Hub Page provides a monitoring surface that tracks progress across content types, reducing the cognitive overhead of visiting separate screens even if the screen count is higher.

2. WF4 (daily monitoring) is not as strong as B: Candidate A's dashboard is secondary — alerts and phase prompts exist but the dashboard is not the operational nerve center B achieves. A's monitoring circuit requires 2-4 screens vs. B's 1-3. Mitigation: A's dashboard can be iteratively enhanced toward B's vision. The structural difference is emphasis, not architecture — A has all the same alert capabilities, just with less prominence on the dashboard.

3. Implementation effort is moderate (3/5), not the lightest: Three multi-tab entity pages (Student, Semester, TA) are substantial development investments. Mitigation: Entity pages can be built incrementally — Student Detail Page first (highest daily-use impact), then Semester Hub Page (highest setup/close impact), then TA Detail Page. The 70% nav-only changes can ship immediately, delivering value before entity pages are complete.

Elements to Incorporate from Other Candidates

From Candidate B, incorporate into A:

• Enhanced dashboard alert logic: Strengthen A's secondary dashboard toward B's hub capabilities — particularly the failed payment tile with student names, the TA response time tile with overdue counts, and the pre-filtered deep links. A's dashboard should be more than phase prompts; it should be a monitoring surface with configurable thresholds.
• Issue Queue: B includes an Issue Queue in the Admin spoke surfaced as a Dashboard tile. A does not specify this. Add it to Admin & System, with a Dashboard alert tile.

From Candidate C, incorporate into A:

• Global search: C's entity-centric model relies on global search as a primary navigation mechanism. A should add a global search bar (accessible from any screen) that resolves to Student Detail Pages, Semester Hub Pages, or TA Detail Pages. This provides C's fastest-path-to-entity benefit without restructuring A's navigation.
• Deeper Content Status integration on Semester Hub: C's Content Status tab on the Semester Entity Page provides inline content management within the semester context. A's Setup Checklist tab should go beyond status tracking and allow direct navigation to (or inline previewing of) content for each type, reducing the friction of navigating to the Content domain during semester setup.

Part D: Sensitivity Analysis

Testing whether the recommendation changes when individual criteria are double-weighted.

Scenario 1: Mental Model Match weighted 2x

Result: Recommendation unchanged. A's lead widens from 1 point to 2 points. This is expected — mental model match is A's strongest criterion. C falls further behind because its entity-centric structure departs the most from the admin's Q4 description.

Scenario 2: Implementation Effort weighted 2x

Result: Recommendation changes to a tie between A and B. If implementation speed is the dominant concern, B's lighter entity pages (enhanced list/detail vs. multi-tab rebuilds) and focused investment profile (one dashboard system vs. three entity page rebuilds) make it equally attractive. C falls to a distant third — its significant rearchitecture requirement is penalized heavily. If implementation effort is the deciding factor, B should be selected because it delivers the same nav-only benefits as A with lower custom development per screen.

Scenario 3: Screen-Hop Reduction weighted 2x

Result: Recommendation unchanged — A still wins, though the margin narrows to 2 points over B and 3 over C. Even with screen-hop reduction double-weighted, C's penalties on mental model match (3), scalability (3), catch-all risk (3), and implementation effort (2) outweigh its perfect screen-hop score. A's balanced profile holds up under this weighting.

Sensitivity Summary

Candidate A is robust — it wins or ties in all four scenarios. The only scenario where B catches A is when implementation effort is double-weighted, producing a tie. Candidate C never wins under any weighting scenario, because its penalties on mental model, scalability, catch-all risk, and implementation effort accumulate across all weightings.

Part E: Risks of the Recommendation

Risk 1: Content Domain Friction During Semester Setup

Failure mode: The admin finds it tedious to navigate between the Semester Hub Page (Setup Checklist) and the standalone Content section (6 separate screens) during semester setup. She compares the experience unfavorably to Candidate C's integrated approach, where all content is managed within the semester context. Over time, she avoids using the Setup Checklist and reverts to her current approach of manually tracking what has been configured.

Likelihood: Medium. The Setup Checklist reduces cognitive load (she can see what is missing), but the physical navigation to Content screens remains a source of friction — 10-12 screens vs. C's 4-5 for WF1.

Mitigation: Enhance the Setup Checklist tab to include direct deep links to each content type's create/edit screen with the semester pre-filtered. Add a "return to checklist" affordance that returns the admin to the Setup Checklist after saving a content item. Consider allowing inline content previewing (thumbnail + title) within the checklist tab so the admin can spot-check without navigating away. These enhancements bring A closer to C's consolidation without restructuring the Content domain.

Risk 2: Dashboard Remains Underinvested

Failure mode: Because A treats the dashboard as secondary (not the hub), it receives lower development priority and ships as a minimal implementation — alert counts without context, no deep links, no configurable thresholds. The admin continues using the dashboard as she does today: ignoring it. Daily monitoring (WF4) does not materially improve despite the structural capability.

Likelihood: Medium-High. Development teams naturally prioritize the primary organizing element. If A's primary investment goes to entity pages and domain reorganization, the dashboard may be deprioritized.

Mitigation: Explicitly include dashboard alert logic in the MVP scope, not as a Phase 2 enhancement. Define the minimum viable dashboard as: (1) failed payment alerts from Stripe, (2) TA response time flags, (3) students-behind-on-submissions count, (4) semester phase prompt. Each alert must have a deep link to the resolution context. Borrowing B's dashboard specification as the target ensures the dashboard delivers value from launch.

Risk 3: TA/Support Staff Navigation Confusion During Transition

Failure mode: TAs and view-only admins who are accustomed to the current navigation struggle to find things in the new 8-domain structure. The domain labels (Student Management, Semester Management) are meaningful to the primary admin but may not be immediately clear to occasional users who thought in terms of "People" and "Program." Training materials are needed, and without them, support tickets increase.

Likelihood: Low-Medium. WS1.4 specifies role-based sidebar filtering — TAs see only 4 items (My Students, My Schedule, My Groups, Recordings), which is simpler than the current full sidebar. View-only admins see all 8 domains but with action buttons disabled. The simplification for TAs actually reduces confusion. The risk is primarily for view-only admins who see the full structure.

Mitigation: The Criterion 3 analysis showed all three candidates score 5/5 on secondary user learnability for the tested task. The domain labels use familiar nouns (Students, Appointments, etc.) within sections, which supports discovery. Provide a one-page orientation guide mapping old locations to new locations for view-only admins. Consider inline tooltips ("formerly under Program") during the first 30 days after launch.

Part F: Convergence Preview — Billing Integration (Previewing Workstream 2)

Workstream 2 will focus on billing integration — bringing Stripe data, family plans, scholarships, and deferments into the admin backend. This section previews how well each candidate's structure accommodates that integration.

Candidate A: Natural Billing Home

Billing in Candidate A has a dedicated domain (Billing & Payments) with 6 screens: Payment Overview, Payments history, Payment Plans, Coupons, Family Plans, and Scholarships & Deferments. Student-level billing is embedded on the Student Detail Page's Payments tab.

Convergence strength: The Billing & Payments domain provides a natural top-level home for all aggregate billing features, including future additions like revenue dashboards, payment analytics, refund management, and dunning workflows. The Student Detail Page's Payments tab provides the student-level integration point. The dual-level design (domain for aggregate, entity tab for individual) means Workstream 2 development has clear architectural targets — aggregate features go to the Billing domain, student-level features go to the Payments tab.

Convergence risk: The Billing domain is a new section that does not exist today. Workstream 2 must build both the domain screens and the Stripe API integration simultaneously. If the Billing domain is deprioritized or descoped, the structure degrades gracefully — Payment Plans and Coupons can remain in Settings temporarily, and the Student Detail Page's Payments tab can be released without the full domain.

Score: 5/5 — The strongest billing convergence because billing has a first-class structural home at both the aggregate and individual levels.

Candidate B: Dashboard-First Billing Detection, Spoke-Based Resolution

Billing in Candidate B lives in a standalone Billing spoke (aggregate) with the same 6 screens as A. Student-level billing is an enhanced field on the student detail page (payment status) that links to the Billing spoke for detail.

Convergence strength: The Dashboard's failed payment tile and billing alert integration means billing exceptions are immediately visible. Workstream 2's alert-related features (failed payment detection, expiring subscription warnings, dunning triggers) plug directly into the hub as new tiles — the easiest integration path for billing monitoring.

Convergence risk: Student-level billing is shallow. When a support staff member needs to investigate a student's billing issue, they must navigate from the student detail page to the Billing spoke, losing student context. Workstream 2 would need to either (a) deepen the student detail page with a billing tab (moving toward A's model) or (b) accept the spoke-hop for billing investigation. Option (a) is the likely outcome, which means B naturally evolves toward A's entity page depth over time.

Score: 3/5 — Billing detection is strong (dashboard tiles), but billing resolution is structurally separated from the student context. Workstream 2 will likely need to add entity-page-level billing tabs, partially negating B's lighter entity page design.

Candidate C: Deepest Student-Level Billing, Cross-Entity Aggregate

Billing in Candidate C is embedded most deeply at the student level — the Student Entity Page's Payments tab includes full payment history, subscription management, family plan details, and inline actions. Aggregate billing lives in the Cross-Entity Billing section.

Convergence strength: The Student Entity Page's Payments tab is the most complete billing integration of any candidate at the individual student level. For Workstream 2 features that are student-centric (payment plan adjustments, refund processing, subscription status changes), the entity page provides the richest context.

Convergence risk: The "Cross-Entity" label signals that billing is a second-class citizen in the entity model — it does not have its own entity, so it lives in a cross-cutting section. If Workstream 2 introduces complex billing features (revenue analytics, payment gateway management, billing rules engine), they must go into the cross-entity section, which is already the model's weakest structural area. The cross-entity sections are C's catch-all, and adding more billing complexity there increases the orphan/catch-all pressure documented in Criterion 6.

Score: 4/5 — Deepest student-level integration but weaker aggregate-level structural home. Workstream 2's complex billing features would strain the cross-entity architecture.

Convergence Summary

Candidate A provides the cleanest path for Workstream 2 because billing has a first-class structural home at both the aggregate level (Billing & Payments domain) and the individual level (Student Detail Page Payments tab). Development teams can build aggregate billing features into the domain and student-level billing features into the entity tab, with the dashboard surfacing exceptions — a clear separation of concerns that maps directly to the billing integration work.

Enhanced Candidate A: The Final Recommendation

After incorporating the best elements from B and C, the recommended "Enhanced Candidate A" has these characteristics:

From Candidate A (core):

• 8-domain sidebar structure matching the admin's mental model (Student Management, Semester Management, Content, Scheduling, Teacher Management, Billing & Payments, Reporting, Admin & System)
• Rich multi-tab entity pages for Students (6 tabs), Semesters (4 tabs + setup checklist + close workflow), and TAs (4 tabs)
• Billing as a first-class domain with dual-level integration (domain for aggregate, entity tab for individual)
• Role-based sidebar filtering for TAs and view-only admins

Incorporated from Candidate B:

• Enhanced dashboard: Promoted from secondary to operational nerve center with configurable alert tiles (failed payments with student names, TA response times with overdue counts, students behind on submissions, appointment utilization), pre-filtered deep links, and quick actions. Not as hub-dominant as B, but significantly stronger than A's baseline.
• Issue Queue: Added to Admin & System section, surfaced as a Dashboard alert tile. Creates the student-to-admin communication channel.
• Phase-aware dashboard tiles: Semester lifecycle prompts ("Setup: 5 of 8 content types configured", "Close: 4 items remaining") with direct links to Semester Hub.

Incorporated from Candidate C:

• Global search: Accessible from any screen. Resolves to Student Detail Pages, Semester Hub Pages, or TA Detail Pages. Provides the fastest path to any entity without requiring sidebar navigation.
• Deeper Content Status integration: Setup Checklist tab on the Semester Hub Page includes direct deep links to content creation screens with the semester pre-filtered, inline content previews (thumbnail + title) for spot-checking, and a "return to checklist" affordance after saving content items. Approaches C's consolidation without absorbing content screens into the entity page.

Estimated workflow improvements (Enhanced A vs. current state):

External tool reduction: From 15 external tool dependencies across 6 workflows to 1 (Vimeo for video URLs, which is structural and cannot be eliminated by nav redesign). Google Sheets eliminated entirely. Stripe dashboard eliminated entirely.

Summary

Candidate A (Domain-First with Rich Entity Pages) is recommended based on the following evidence:

1. Highest overall score (30/35 at equal weight), winning or tying on 4 of 7 criteria.
2. Robust under sensitivity analysis — wins or ties in all four weighting scenarios.
3. Best mental model match — the only candidate whose structure was proposed by the primary user.
4. Strongest billing convergence for Workstream 2 — billing has a first-class home at both aggregate and individual levels.
5. Balanced improvement across all 6 workflows (average screen reduction of 48%) without the implementation risk of Candidate C's rearchitecture or the monitoring overemphasis of Candidate B.

Key elements to incorporate from the other candidates: B's dashboard alert depth and Issue Queue; C's global search and deeper content status integration on the Semester Hub.

The primary risks — Content domain friction during semester setup and dashboard underinvestment — are mitigable through targeted enhancements that do not require structural changes to the recommended navigation architecture.