Turning
problems
into usable
products.

Hudl is the dominant video analysis platform in high school and collegiate athletics. Coaches use it to review game film, tag statistical events, cut highlight clips, and share footage with players and recruiters. The platform is deeply embedded in team workflows at thousands of programs around the world.

However, a persistent and well-documented friction point (see sources below) affects the most time-constrained segment of Hudl's user base — the high school and club coach who does not have access to a video coordinator, analytics staff, or dedicated film time. For these coaches, the post-game film workflow requires a minimum of two complete passes through game footage: one to tag statistics, and a second to cut and assign clips. For a 90-minute soccer match, this routinely means three or more hours of solo post-game work before a single coaching insight reaches players.

This concept project proposes a redesigned tagging interface that enables coaches to simultaneously tag statistics, cut clips, and assign playlist destinations as a single unified operation during one playback pass — reducing post-game film processing time by an estimated 50% or more for the time-pressured teacher-coach persona.

The coach using Hudl alone. The popular image of Hudl is a college football program with a dedicated analyst tagging every snap during the game. That user exists. But Hudl's market penetration is deepest at the high school level, where the reality is significantly different. The typical high school or competitive club coach using Hudl is a full-time teacher, administrator, or working professional who coaches on the side. They have no video staff. They arrive home after a Friday night game — sometimes past midnight — and face a backlog of film work that must be completed before the next session.

The double-tagging problem — mechanics. Hudl's current film review interface separates two logically related operations into distinct modes that cannot be performed simultaneously:

The compounding effect is significant: a coach who wants to use both stat analysis and player-specific clip sharing must invest three or more hours per game. For a program playing 15–20 games per season, that is 45–70 hours of post-game film work. Most coaches are not spending that time — they are choosing between stats and clips, or abandoning both in favor of simply sharing the raw game film link.

Four personas drive this project. Full persona documents are a deliverable in Step 02. Summaries below are for brief context only.

The core hypothesis is structural: the reason coaches cannot tag stats and cut clips simultaneously is not a technical limitation — it is a modal interface architecture that treats these as separate tasks. They are not separate tasks. They are the same task: identifying a meaningful moment in the film and attaching multiple attributes to it simultaneously.

Measured through prototype testing and qualitative research. The following criteria define a successful outcome:

Constraints

• Visual design must work within Hudl's existing dark UI visual language to be credible as a proposed feature rather than a competing product.
• The mobile design must function on tablet (primary film review device for mobile coaches) and be usable on phone.
• The interaction model must not require keyboard shortcuts as the primary input method — many coaches are not keyboard-shortcut users.
• The interface must remain accessible to non-expert Hudl users — the tech-reluctant veteran persona must not be confused or disrupted by the new controls.

Assumptions

• Hudl's tagging API can associate multiple metadata types (stat type, clip boundaries, playlist IDs) with a single event object. This is assumed to be technically feasible; it is not confirmed.
• Post-game is the primary use context for the redesigned interface. Live in-game tagging has different latency and attention constraints not addressed here.
• Coaches in the target user population own or have access to a computer for post-game film review, even if they also review film on mobile.

The following questions are unresolved at the start of this project and will be addressed through research, testing, and design iteration:

1. What is the minimum viable interaction for marking a clip boundary during live playback? Does the coach need to define both the in-point and out-point before moving on, or can the system infer a default clip length based on sequence type?
2. How do coaches currently prioritize which moments to tag when time-constrained? Is there a natural hierarchy (goals first, shots, turnovers) that the interface should surface?
3. What proportion of coaches use playlist assignment at all? If adoption is low, is it because the feature is genuinely low-value, or because the workflow makes it inaccessible?
4. Is there a mobile-first coach population that would use a redesigned interface on a tablet at the venue rather than returning home to review on desktop?
5. How does the proposed interface interact with Hudl's existing sequence and moment data model? Is the unified tagging concept additive, or does it require a restructuring of the underlying event object?

This scope definition establishes the precise boundaries of the redesign effort — what is being designed, what is explicitly excluded, and what assumptions are being carried into execution. It exists to prevent scope creep and to give any product or engineering reviewer a clear picture of what a real sprint or project plan would need to contain.

• Interface only, not service. The redesign must work for a coach who cannot or will not pay for Hudl Assist. It solves the same output problem Assist solves, but through interface design rather than outsourced labor or AI.
• No new data model required. Hudl Assist already delivers stats and clips as simultaneous properties of a single tagged event, which means the back end demonstrably supports this association. The scope assumes the interface can map to the existing event object structure without requiring architecture changes.
• Additive, not disruptive. Coaches who currently use the basic clip-sharing workflow (the tech-reluctant veteran persona) must not find the new tagging interface harder or more intimidating than what they use today. The redesign is an upgrade path, not a replacement mandate.
• Soccer primary, sport-agnostic by design. The interface pattern should be sport-agnostic in its underlying logic even if soccer is the test case — the tag types change by sport, but the interaction model (mark a moment, attach attributes, assign to playlist) is universal.

These criteria define what a successful outcome looks like for this project, measured through usability testing in Steps 05 and 09. Each criterion is tied to a specific measurement method and a target threshold. They exist so that the design evaluation is not subjective — the redesign either passes or it doesn't.

These criteria are the limit of what speculative concept work can prove. They cannot measure real-world adoption at scale, long-term behavior change, or the business impact of cannibalizing Assist revenue. Those questions require a shipped product and instrumented usage data — the kind that FullStory and Sigma would provide in a real product context. The open questions log in Step 10 will name these explicitly.

• Primary goal: Deliver targeted clip packages to individual players within 48 hours of the game, before the next practice.
• Secondary goal: Generate shot maps and pass completion stats for his own game-to-game coaching decisions without spending hours on data entry.
• Core pain: The two-pass requirement means he routinely has to choose between sleep and clips. Clips lose every time. Key features go unused not because of disinterest, but because the workflow is structurally incompatible with his schedule.
• Workaround: Shares full game film link with timestamps typed in a group text message. Players have to find their own moments. He knows this is a worse experience but has no time for the alternative.
• Risk if not addressed: Will abandon Hudl's advanced features entirely. "I don't know why I tag stats if I never have time to do anything with them."

• Walk me through exactly what you do the night of a game, from final whistle to when you go to sleep. When does Hudl enter that picture?
• How often do you complete both stat tagging and clip cutting after a game? What causes one to get skipped?
• When you skip cutting clips, how do you share the film with players? What do they miss when you do that?
• Describe the last time you felt like your film work really had an impact on a player's development or your team's preparation. What made that possible?
• If you had an extra 45 minutes after each game — only for film work — what would you do with it?
• What parts of the Hudl interface feel designed for someone else? Who do you think it was built for?
• Have you ever tried to use Hudl on your phone after a game? What happened?
• If Hudl could do one thing automatically without you having to do anything, what would it be?
• How do you feel when Sunday rolls around and the clips didn't get done? Do your players say anything?
• What would it mean for your coaching — practically — if you could tag stats and cut clips in the same pass through the film?

• Primary goal: Send each player 3–5 specific clips from every game — individual moments with individual context — before the next training session.
• Secondary goal: Build recruiting highlight reels for her college-bound players without paying for external video editing services.
• Core pain: High tech literacy makes her acutely aware of how unnecessary the two-pass workflow is. She can clearly articulate why it's broken and would immediately adopt a single-pass solution.
• Workaround: Uses the Hudl share link with timestamp notation in a WhatsApp group. Also screenshots specific moments and overlays coaching notes using Canva before sending to parents. This is a faster workaround than Hudl's clip system.
• Recruiting pressure: College coaches have asked her for specific clip packages for individual players. She currently exports full game film and manually cuts with iMovie. This takes hours and is the most painful part of her workflow.

• You mentioned sending timestamps instead of clips. Walk me through the last time you did that — from the moment you decided not to cut clips to hitting send. What was going through your head?
• Have you ever had a parent or college coach ask for a clip package you couldn't easily produce? What did that feel like and what did you do?
• You travel to tournaments most weekends. What does your film workflow look like on the road — hotel room Sunday night, multiple games in the day? What tools are in reach?
• You're a high-tech user. Where does the Hudl interface make you feel like it was designed for someone less technically sophisticated than you? And where does it make you feel the opposite?
• Tell me about the Canva workaround. When did you start doing that? What does it give you that Hudl doesn't?
• If you could tag one moment during live playback and have a clip, a stat entry, and a player playlist assignment all complete at once — would you trust that, or would you want to double-check it? Why?
• How much time does the recruiting clip request add to your workflow? What would change if you could build those clips during your normal game review?
• On a scale of 1–10, how much of Hudl's feature set do you actually use? What's in the 10 that you don't use and why?

• Primary goal: Watch film. Understand what his unit did well and poorly. Communicate corrections to players before Thursday practice.
• Actual Hudl use: Opens the film link shared by the head coach. Plays it back in the team meeting room. That is the full extent of his Hudl interaction.
• Core concern for this project: He is the user who must not be made worse off by a redesign. The Scope Definition in Step 01 names him explicitly: the redesign must be additive, not disruptive. His basic workflow (click link → watch film) must remain zero-friction.
• Design implication: New unified tagging features must not add visual clutter, required steps, or onboarding friction to the basic film-watching experience. The advanced workflow should layer on top of what he already does, invisibly.
• Relationship to interface complexity: If a new interface makes him feel confused or incompetent during the team film session, the head coach will get complaints — and that is a real stakeholder concern for any product team shipping this change.

• Tell me about the first time you used video review software — any platform. What was that transition like? What made it work or not work?
• When you open Hudl in a team meeting setting, what do you see first? What do you do with it?
• Has there ever been a moment in a Hudl session where you felt lost or unsure what to press? What did you do?
• What would make you feel comfortable using more of Hudl's features on your own — outside of team meetings?
• If the interface changed tomorrow and some of the buttons looked different, how would that affect you? What would you need to feel confident again?
• You mentioned that [head coach] handles all the tagging. What would it look like if you had to do that yourself? Walk me through how you'd approach it.
• What coaching information do you wish you had faster after games that you currently don't get?
• If you could give Hudl's design team one piece of feedback, what would it be?

• Primary goal: Coaching preparation — scheme analysis, opponent scouting, player development. She wants to spend film time on decisions, not mechanics.
• What Assist solves: The routine post-game breakdown — stat compilation, player auto-playlists. Eliminates the two-pass problem for the majority of her weekly film work.
• What Assist does not solve: Custom clip packages (theme-based, not player-based). Recruiting reels. Specific play-sequence illustrations for practice installation. All of this still requires manual work in the base interface.
• Price sensitivity: Frames Assist as a cost she accepts because "it buys back 4–5 hours per game week." Would switch to a base-platform solution immediately if it delivered equivalent time savings at no added cost.
• Design implication: This persona validates that the two-pass problem is real and worth paying $1,400/year to outsource. She is also the clearest signal that even with Assist, the base interface has remaining gaps — making the design project's value proposition real even for coaches who could afford Assist.

• Walk me through your film workflow from Friday night to Monday practice — specifically where Assist comes in and where you're still doing things manually. Be as specific as possible about what you actually click and when.
• What was the film workflow like before you had Assist? What tipped you into paying for it?
• Describe a moment in the last month where you needed something from the film that Assist's breakdown didn't give you. What did you do?
• How do you feel about the $1,400/year? Is it a no-brainer or something you debate every year? What would make you cancel?
• If the base Hudl interface could tag stats, cut clips, and assign playlists in a single pass — at no additional cost — would that change your Assist decision? What would you want to try first?
• What does Assist do better than you could do yourself? What does it do worse or differently than you'd want?
• Do your players notice a difference in what they receive from you compared to coaches who don't use Assist? What do they say?
• If Hudl offered a lighter version of Assist — just the stat auto-tagging, not the full human analyst service — for a fraction of the price, would that interest you?

Research was conducted across 11 coaching interviews — 3 teacher-coaches, 2 club coaches, 2 tech-reluctant veterans (observed in team meeting context), and 4 Assist subscribers — supplemented by structured analysis of 47 publicly available reviews from G2, the Hudl community forum, App Store reviews tagged with workflow-related keywords, and the coaching subreddits r/bootroom and r/SoccerCoaching. The interview protocol was semi-structured, 45–60 minutes, conducted over video call. Participants were recruited through Liverpool FC International Academy Utah, coaching networks in Utah and Nevada, and a publicly posted screener.

Interviews were recorded with participant consent and transcribed. Affinity diagramming was used to identify themes across participants. The synthesis below is organized by finding, not by persona, because the most useful patterns emerged across persona boundaries.

Every non-Assist participant described film work as a time competition — a fixed window between game end and the next team interaction where coaching insights have to be extracted, organized, and delivered. The window varies (Friday night, Saturday morning, Sunday evening) but its compression is constant. The critical finding: coaches do not lack motivation to use advanced features; they lack time to make two passes. This distinction matters because it changes the design question. The problem is not feature discoverability or interface learnability — it is workflow structure.

Three of 5 non-Assist participants described a specific pattern: stat tagging happens in session one (often very late at night, while fatigued) and is completed at a low level of detail. Clip cutting, requiring a second full pass, is deferred and frequently abandoned. The result is an asymmetry: stat data accumulates in Hudl but never converts to player-facing film content.

All 5 non-Assist participants had developed workarounds for the clip-delivery problem — and none had labeled them as workarounds until directly prompted. Sharing a game link with timestamps in a group text was the most common (4 of 5). Screenshot-plus-annotation via Canva or Notes appeared in 2 cases. One coach printed still-frame grabs from the film and taped them to a whiteboard for the team meeting. These workarounds represent Hudl feature abandonment, not coach failure. Coaches adapted to the interface's constraints rather than fighting them — but in doing so, they reduced Hudl to a video hosting service, not a coaching tool.

Assist subscribers described near-unanimous satisfaction with the core value proposition — getting a tagged breakdown without doing the tagging themselves. All 4 confirmed it had eliminated the two-pass problem for routine post-game review. However, all 4 also described a second layer of manual work that Assist does not address: theme-based clip packages (e.g., "all our transition moments from the last three games"), recruiting reels for individual players, and play-sequence illustrations for upcoming opponent preparation.

Assist delivers player-by-player clip playlists — every moment a specific athlete appears. What it does not deliver is intent-based clip selection: a coach pulling the 6 moments that illustrate a specific tactical concept for a specific practice session. That work still happens in the base interface, still requires a manual pass, and still takes the same amount of time as before Assist.

Six of 7 non-Assist coaches reported doing their primary film work between 10pm and midnight the night of the game. Task completion quality at this time was described by all 6 as "lower than I want it to be." Specific behaviors reported: tagging fewer event types than intended, using generic catch-all tags rather than granular ones, stopping before the end of the film, and skipping documentation of opponent patterns entirely. The fatigue-degradation loop is self-reinforcing: low-quality tags reduce the analytical value of the data, reducing the coach's confidence that the stat tagging is worth doing at all.

Design implication: the interface must support high-quality output with low cognitive load at 11pm on a Friday, not just at 9am on a Thursday. Every additional decision the interface requires is a decision that fatigued coaches simplify or skip.

Both observed tech-reluctant veterans operated inside programs with staff structures that insulated them from the interface. In both cases, a head coach, team manager, or "tech-savvy assistant coach" handled all Hudl administration. The veteran coach consumed the output — watching film in team meetings, clicking shared links — but never operated the interface independently. This is significant for the redesign: the veteran's primary risk is not from new features (which he won't use), but from visual changes to the core player experience (the film player itself, the shared link landing page) that could disorient him in the team meeting context. Preserving the film-watching experience is a higher priority than exposing new tagging functionality to this persona.

Behavioral archetypes are distinct from personas. Personas describe who users are — their background, context, and goals. Archetypes describe how users behave inside a specific workflow, regardless of which persona they belong to. A single coach can exhibit multiple archetypes depending on the game, the week, and the time available. These archetypes emerged from interview synthesis and are used to stress-test design decisions: each proposed interface change should be evaluated against what it does to each archetype, not just each persona.

Definition: Does one thing during film review — either stat tagging or clip cutting — but never both in the same session. Chooses based on which deliverable is due first. The other deliverable is deferred indefinitely.

Who shows this behavior: Teacher-Coach (Marcus archetype) most consistently. Some Club Coaches during tournament weekends when time is extremely compressed.

Trigger condition: Available time is less than what both passes require. The coach calculates (usually unconsciously) that one complete pass is better than two incomplete ones.

Design implication: The Single-Passer is the primary target user for a unified tagging interface. They already want to do both — the interface structure is what forces them to choose. Eliminating the mode-switch between stat tagging and clip cutting collapses their two-pass obligation into one. This is the highest-ROI archetype for the redesign.

Definition: Shares game film with players or parents via a direct link plus manually typed timestamps in a separate message, rather than cutting and sharing discrete clips. This is the most common workaround identified in research (4 of 5 non-Assist participants).

Who shows this behavior: Club Coaches (Daniela archetype) most visibly. Also appears in Teacher-Coaches during high-volume weeks. Rarely in programs with video coordinators.

Trigger condition: Coach has watched the film and knows which moments matter, but does not have the time or inclination to go back through the clip-cutting interface a second time to formalize those moments as discrete deliverables.

Design implication: The Timestamp Sender is actively avoiding the clip-cutting interface because the cost of returning to it exceeds the benefit they perceive. A single-pass interface that creates a clip at the moment of tagging — no return visit required — would eliminate the workaround and likely increase engagement with the clip-sharing feature significantly. The design must make clip creation feel as lightweight as typing a timestamp.

Definition: Defers all film work to a single large session the morning after the game — doing stat tagging, clip cutting, and film review in one long block. This approach preserves quality by avoiding late-night fatigue degradation, but compresses the delivery window and crowds out other weekend obligations.

Who shows this behavior: Coaches with young children or family obligations that make late-night work impossible. More common among women coaches in the sample. Also appears in coaches with longer commutes after evening games.

Trigger condition: Deliberate scheduling choice. The coach has accepted late delivery to preserve work quality. Often describes this as a "system" they've developed.

Design implication: The Saturday-Morning Editor already consolidates work into one session by choice — they are a natural fit for a unified interface even if the time pressure is lower. They are more likely to complete all deliverables if the interface rewards doing them together. Their specific concern is total session length: they want to finish before family obligations resume, so efficiency within the session matters even when urgency is lower.

Definition: Assigns film work to an assistant coach, team manager, or technically skilled player (often a senior or team captain). The head coach provides direction — "clip these three moments, tag all our defensive transitions" — and reviews the output rather than producing it.

Who shows this behavior: Head coaches at larger, better-resourced programs. Also appears in coaches who are confident in their strategic decisions but describe themselves as "not good at the tech side."

Trigger condition: Access to a trusted collaborator with better Hudl proficiency. Often born from necessity (head coach doesn't have time) and formalized into a regular division of labor.

Design implication: The Delegator is a secondary user of the tagging interface (their delegate is the primary user) but is the primary consumer of the output. The redesign must not introduce so much complexity that Delegators can no longer hand off the workflow to less-experienced assistants. The unified interface should be learnable by a first-year assistant coach, not just an experienced head coach. Also: the Delegator's preferences drive what gets tagged, but not how. Interface decisions that make delegation easier (e.g., shareable tagging templates, annotation handoff, draft review mode) have high value for this archetype.

Film work does not happen in a dedicated, distraction-free environment. It happens in stolen time — between other obligations, at the margins of the day, often while fatigued. The following temporal patterns emerged from research:

Key design implication: The interface must perform well at 11pm on a Friday, on a home network, on a 4-year-old laptop, by a person who has been on their feet since 7am. That is the median use condition — not a stress test. Every additional modal, confirmation dialog, or mode-switch is a cognitive tax on someone who has no cognitive surplus to spend.

• Home couch or kitchen table: Primary environment for teacher-coaches and most club coaches. Laptop on a coffee table or dining surface. TV may be on in the background. Other family members present.
• Home office or bedroom desk: Less common. Coaches who use this setting report higher-quality output — dedicated space = dedicated attention. Mostly evening-preference coaches.
• School office during free period: Rare — only 1 of 11 participants regularly used school time. Most cited lack of uninterrupted time during school hours.
• Car (parked): Two participants described doing quick film review on their phones parked in the school lot after games, before driving home. Not tagging — just reviewing moments they remembered. No one used Hudl's mobile app for tagging.
• Hotel room at tournaments: Worst context. Poor WiFi, shared rooms, using phone or borrowed laptop. All tournament-attending coaches described this as a degraded experience. Two had given up on tournament-night film work entirely due to unreliable connectivity.

All 11 participants described their film sessions as interrupted. The type and frequency of interruption varied by persona and session time:

• Children and family: Most frequently cited. Coaches with children under 10 described film sessions as "opportunistic" — done whenever the house is quiet. Interruptions are unpredictable and can end a session without notice.
• Parent and player messages: Post-game periods trigger high message volume — reactions, concerns, requests. 7 of 11 coaches reported checking their phone during film sessions. This context-switch was described as "mostly fine" but contributed to losing track of film position.
• Physical fatigue forcing re-watches: 4 coaches described rewinding moments they had already tagged because they weren't sure they had tagged them correctly — an artifact of reduced attention from fatigue. This represents unplanned additional passes through the film, adding time to an already long session.
• Software interruptions: Hudl auto-save dialogs, video buffering pauses, and unexpected logouts were each cited by at least 2 participants as disrupting their tagging rhythm.

Design implication: The interface must be tolerant of interruption. A coach who steps away mid-tag and returns 15 minutes later should not lose context. The current position in the film, any open tagging panels, and any partially completed tags should persist. This is a requirement, not a nice-to-have, given the environment the interface actually operates in.

These notes document structured interviews with four Hudl Assist subscribers conducted in February–March 2026. The interviews were designed to answer a specific design question: if Assist already solves the two-pass problem for paying subscribers, what does that reveal about what a base-platform solution must do — and where will it fall short? The Assist subscriber is a contrast case, not a primary design target. Their experience shapes scope boundaries and reveals which problems a base-platform fix cannot credibly promise to solve.

All participants are identified by role and tenure only. Quotes are lightly edited for clarity.

Uploads game film within 2 hours of final whistle using the Hudl app on an iPhone. Assist breakdown is available by 9am Saturday — full stat event markers and per-player clip playlists for all 28 players. Reviews breakdown on laptop Saturday morning, approximately 45 minutes. Sends player playlists directly from the Assist dashboard with no additional editing.

Still returns to base platform 2–3 times per week for: (1) thematic clip packages for practice installation, (2) custom reels for 3 college-bound seniors, (3) opponent film review and tagging. Assist does not cover opponent film. For opponent work, she performs the full two-pass workflow manually — stat tagging pass, then clip cutting pass — the same workflow that non-Assist coaches use for all games.

• Assist solves routine post-game review but leaves opponent scouting entirely unaddressed. A base-platform unified tagging interface would have clear value for opponent film work even for Assist subscribers.
• Intent-based clip packages (thematic, not player-based) are the gap that neither Assist nor the current base platform fills well. This is a distinct design opportunity worth naming in the design brief.

His head coach manages Assist subscription and handles all film upload and breakdown distribution. He is a consumer of Assist output, not an operator. Receives a shared link to the Assist breakdown each Saturday. Reviews it on his own, then uses the base platform to pull specific formations and play sequences for his weekly install meeting. Estimates 3 hours/week in the base platform despite having Assist — all of it on offensive scheme preparation, which Assist's breakdown does not organize thematically.

• This participant describes the exact behavior a unified tagging interface enables — watching, tagging by type, and having thematically organized clips — as something he currently does manually across two passes. He is the clearest validation that the design concept solves a real remaining problem even for Assist programs.
• His workflow does not start from game film upload — it starts from consuming Assist output and then doing additional tagging. This suggests the interface must support working within an already-tagged film, not just from a raw upload.

Manages Assist subscriptions for 6 teams in a competitive club program. Assist cost is ~$8,400/year total across teams. Each head coach receives Assist output independently. He uses Assist for his own U19 team and manages the system administratively for others. Primary concern: two of his six coaches don't use Assist output consistently — they revert to watching raw film because they don't trust the Assist tagging accuracy for soccer-specific events.

• Sport-specificity is a real limitation of Assist's current offering, particularly for soccer. Custom tag types that coaches define themselves — not predetermined by Hudl's taxonomy — would address this and could represent a meaningful differentiator over the Assist service for technically sophisticated coaches.
• The cost argument against Assist is stronger than expected at the club/program administration level. A DOC managing multiple teams does a per-team cost calculation that individual coaches do not. A free base-platform solution competes directly with Assist at this level.

Adopted Assist after two years of manual two-pass tagging. Framed the switch as "I hit a wall — I couldn't keep doing it." Current workflow: uploads game film from his phone immediately after the game. Assist breakdown arrives by morning. Reviews on iPad over breakfast. Sends player playlists directly. Total time: ~30 minutes per game. Before Assist: 3–4 hours per game across two sessions.

• Participant D's "hit a wall" moment is the adoption threshold for Assist. Coaches do not pay for Assist at the first moment of friction — they pay after sustained friction over multiple seasons forces a breaking point. A base-platform fix could prevent coaches from ever reaching that threshold.
• The AD budget-justification dynamic is real. A cost that individual coaches justify easily ("my time is worth it") still requires organizational approval. A free base-platform feature removes this barrier entirely and could drive adoption at programs where Assist is not currently approved.

This matrix evaluates eight platforms across the criteria most relevant to the design problem: single-pass tagging capability, clip creation workflow, player delivery model, mobile viability, pricing accessibility, and how each positions itself relative to workflow complexity. Ratings are based on documented product features (public documentation, App Store listings, review data, and direct testing where access was available) verified as of March 2026. Assist is listed as a separate row from Hudl Base to surface the service-layer vs. interface distinction that is central to this project.

Ratings use a three-point scale: ●● Full = capability exists and works well, ● Partial = capability exists with significant friction or limitations, ○ None = capability absent or negligible.

• The single-pass gap is a market-wide problem, not a Hudl-specific one. Only Wyscout, Nacsport, and Catapult offer genuine single-pass tagging + clip creation — all three are priced for professional or semi-professional programs. No platform under $800/year solves this for the high school or club coach. Hudl sits at the intersection of maximum user volume and minimum capability on this dimension.
• Hudl Assist is Hudl's own acknowledgment of the gap. The Assist row is the only sub-$3,300 offering with full single-pass capability — because it outsources the tagging entirely. The existence of Assist proves Hudl knows the gap is real and monetizable. The design question is whether it can be solved at the interface level instead.
• SportsVisio and QwikCut are positioning explicitly against Hudl's complexity. Both platforms' marketing language (reviewed January–March 2026) emphasizes "simple," "no video coordinator needed," and "works for the coach who does everything." They are targeting the teacher-coach and club-coach personas directly. Neither fully solves single-pass tagging, but both are taking away Hudl users at the entry level.
• Mobile tagging is an unmet need across the board. No platform under $1,200/year offers viable mobile tagging. Coaches on the sideline, in a car, or in a hotel room cannot tag. This represents a workflow gap that a mobile-optimized redesign could address that competitors have not.
• Custom tag types are a Hudl strength — underexploited. Hudl's base platform supports fully custom tag taxonomies, which is a capability that Assist removes (Assist uses its own predetermined event categories). A redesigned interface that makes custom tags easier to use — without the complexity overhead they currently carry — would be a defensible differentiator against both Assist and lower-priced competitors.

To identify interface patterns for multi-attribute simultaneous annotation, the following non-sports tools were reviewed for tagging UX patterns that could inform the redesign:

This document maps the complete post-game film workflow for Hudl Base (manual, current state), Hudl Assist (service-mediated, current state), and the proposed Redesigned Interface (target state). All three are mapped at the same level of granularity — individual steps the coach takes or does not take — so that time savings, mode-switches, and decision points can be compared directly. Step counts and time estimates are based on interview data and direct platform testing; they represent the median experienced coach, not a first-time user.

TOTAL ESTIMATED TIME: 3–4 hours per game · PASSES THROUGH FILM: 2 minimum · MODE SWITCHES: 4–6

TOTAL COACH TIME: 30–60 min per game · PASSES THROUGH FILM BY COACH: 0–1 (review only) · ADDITIONAL COST: $900–3,300/yr

PROJECTED TOTAL TIME: 60–90 min per game · PASSES THROUGH FILM: 1 · MODE SWITCHES: 0 · ADDITIONAL COST: None (base platform feature)

This journey map traces the full post-game film workflow for the Teacher-Coach persona (Marcus, Persona 01) from final whistle to player delivery. It is mapped across five dimensions for each phase: the action the coach takes, the tool or interface used, the thoughts reported in interviews, the emotional state at that point, and any friction points encountered. The map is the current state — it describes what actually happens, not what Hudl intends to happen.

The map uses a five-point emotion scale: ▲▲ Energized — ▲ Positive — — Neutral — ▼ Frustrated — ▼▼ Depleted

This audit catalogs every discrete friction point identified in the Hudl base platform workflow, organized by severity and type. Friction points were identified through three methods: direct coach reporting in interviews (11 participants), structured observation of the current tagging and clip editing interfaces during recorded walkthroughs, and cross-referencing with public review data (G2, App Store, coaching forum threads). Each friction point includes a severity rating, an observed frequency, and the specific design implication for the redesign.

Severity uses a three-tier scale: Critical = blocks task completion or forces workflow abandonment, Significant = causes meaningful time loss or quality degradation, Minor = creates friction but does not derail the task.

The following friction points were identified but fall outside the scope of this interface redesign — either because they require infrastructure changes, are business model decisions, or are out of the designer's control:

• Video upload and transcoding time (15–45 min): Infrastructure and encoding pipeline issue. Not addressable through interface design, though progress feedback and background processing that allows other work to continue are interface-adjacent improvements.
• Hotel WiFi buffering: Network infrastructure. Design can address graceful degradation (offline-capable local playback) but cannot solve the underlying connectivity problem.
• Assist pricing and tier structure: Business model decision. The redesign positions itself as a base-platform alternative, not as a pricing recommendation.
• Soccer-specific tagging accuracy in Hudl Assist: Analyst training and AI model capability. Outside interface scope; noted in Assist Subscriber Interview Notes (Step 02).

This document catalogs interface patterns from within and outside the sports domain that are directly relevant to the design problem. Each pattern is evaluated for its applicability to the specific context of the Hudl redesign — late-night, fatigued, time-pressured coaches working on aging laptops with film playing in the background. Patterns that work perfectly in a calm professional setting may be inappropriate here. The evaluation accounts for cognitive load, interaction speed, error recovery, and interruption tolerance.

Patterns are organized into four categories: Tagging & Annotation, Clip & Media Management, Playlist & Delivery, and Navigation & Orientation. Each includes a source reference, description of the pattern, applicability rating, and specific adaptation notes for the Hudl context.

The following patterns were considered and rejected for the Hudl redesign context, with rationale:

• AI auto-tagging as primary workflow (rejected for base concept): As documented in the Problem Brief and Assist interview notes, AI auto-tagging has sport specificity limitations for soccer and continuous-play sports, and removes coach agency over what gets tagged. The primary concept relies on the coach as the active tagger — AI is reserved for a secondary speculative thread in the wireframes. The redesign must prove value for the majority of coaches who don't want or can't afford AI-mediated tagging.
• Wizard / step-by-step onboarding overlay (rejected): Research found that late-night coaches dismiss overlays immediately and never return to them. Contextual help surfaced at the moment of confusion (inline tooltips, hover states) is more appropriate than a linear onboarding sequence that requires attention up front.
• Separate mobile app for tagging (rejected for primary scope): While mobile tagging has clear value (post-game high-recall window), building a full mobile tagging experience is out of scope for a single-designer concept project. The redesign focuses on the desktop interface. Mobile capture of clip intentions (tap to flag a timestamp for later) is noted as a stretch feature but not a primary deliverable.
• Social / sharing feed model (rejected): Several competitor platforms (Hudl itself, Veo) have added social feed features — coach posts, player reactions, team activity streams. Research found no demand for this among participants; several actively described it as a distraction. The interface should remain task-focused: tag, clip, deliver.

Concept sketches are the earliest-stage design exploration — rough, fast, and deliberately uncommitted. The goal is to generate a wide range of structural approaches to the unified tagging problem before any layout decisions become load-bearing. All sketches were produced in Figma using a loose wireframe component set at 50% fidelity: blocks for UI regions, placeholder text for labels, no color beyond functional annotation. Each sketch took 20–40 minutes to produce. Refinement happens in the lo-fi wireframe stage (Deliverables 2–4), not here.

Sketching constraints: every concept must support the core single-pass requirement (stat tag + clip creation + playlist assignment in one pause of playback), must not require a mode switch, and must remain usable on a 13" laptop screen by a fatigued coach at 11pm. These constraints ruled out several promising patterns early — documented in the Annotated Decision Notes (Deliverable 5).

Concept: The video player occupies 65% of the screen width. A persistent right-side panel (35%) shows the active tag panel, event timeline, and playlist summary simultaneously at all times — no overlay, no modal, always visible. Tagging happens in the panel while video plays in the left pane. Clip in/out controls appear inline in the panel when a tag is placed.

Concept: Video fills 100% of the screen. No persistent panel. When a tag is triggered (spacebar or T key), playback pauses automatically and a compact overlay panel expands from the bottom edge of the video frame. Coach completes all tag properties in the overlay, confirms, and the overlay collapses. Video resumes. Nothing is visible during playback except a minimal event count badge.

Concept: Inverts the hierarchy — the event timeline is the primary interface element at the top of the screen (25% height), with the video player below it (75%). Tagging happens by clicking on the timeline at a timestamp rather than by triggering during playback. Clip bounds are dragged directly on the timeline. Playlist assignment happens via a tag-properties panel that appears when a timeline event is selected.

Concept: A small, always-visible floating heads-up display positioned in the lower-left corner of the video — similar to a game HUD. Shows only the most recently triggered tag type and a confirmation button. Designed for keyboard-heavy users who don't want to leave the video view at all. Full tag properties are set via keyboard navigation within the HUD without the panel growing or displacing the video.

• Why Sketch B wins: It places zero persistent visual load on the coach during playback — the full video frame is always available. The overlay appears exactly when needed (at a tag trigger) and collapses after confirmation. This maps directly to the mental model coaches already have: watch → notice a moment → pause → annotate → resume. The design follows the existing behavior rather than replacing it.
• What Sketch B needs: A discoverable trigger mechanism for non-keyboard users. A robust keyboard shortcut system for experienced coaches. A post-tagging review state that uses Sketch C's timeline-first layout. A collapsed/summary state that shows the coach their tagging progress without intrusion. All of these are addressed in the lo-fi wireframe deliverables.

This wireframe set covers the primary tagging interaction — the moment a coach triggers a tag during playback through to confirmation and resume. It documents four distinct states: the idle/playing state, the triggered/overlay-open state, the confirmation state, and the post-session review state. Each state is shown at the structure level only — no visual design, no color beyond functional annotation, no typography decisions. These are architecture documents, not design mockups.

All wireframes are produced in Figma at 1280×800px (13" laptop viewport). Component names are noted where they correspond to the component set being built in parallel. Annotations reference findings from the Friction Point Audit and Pattern Library directly.

The baseline state: video is playing, no active tag entry in progress. The interface is as close to a pure video player as possible during this state.

• [T] Tag moment trigger: Primary action. Pressing T (or clicking the button) pauses playback and opens the tag overlay. This is the only persistent UI element coaching the user toward the tagging feature during playback.
• [● 8 tagged] badge: Shows running count of tagged events this session. Gives coach a sense of progress and acts as a navigation entry point to the review state. Tapping the badge jumps to the review timeline (State 4).
• Bottom timeline strip: Read-only during playback. Event markers shown as dots — filled for tagged moments, hollow for clip-only marks. Hover shows event type preview. Clicking a marker jumps to that position. This is the pattern from Sketch C adapted for the bottom-strip context.
• [J] Jump to tag: Up/down arrow key shortcuts jump between tagged events. Critical for the review phase; also useful during tagging to quickly return to a moment for re-watch or correction.

Triggered when the coach presses T or clicks "Tag moment." Playback pauses. An overlay panel expands from the bottom of the video frame upward. The video frame remains visible above the overlay — the coach can see the paused frame they are tagging throughout.

• Pre-filled defaults: Event type and player default to the most recently used values. A coach tagging a sequence of Jordan's shots touches only Enter to confirm each one after the first. This addresses the fatigue-degradation finding directly — fewer decisions per tag.
• Clip bounds: Auto-set to ±8 seconds around the tagged timestamp. Configurable per event type in settings. Coach adjusts only when needed — the ◀/▶ nudge buttons move bounds in 2-second increments. The preview range is shown as a labeled scrubber so the coach can see exactly what the clip will contain.
• Playlists: Pre-populated based on player attribution (attribution-driven auto-assign pattern from Pattern Library). "Jordan #7" playlist is automatically checked when Jordan #7 is selected as player. Team playlist checked by default. Coach unchecks, not checks.
• [SKIP CLIP — S]: Confirms the stat tag only, creates no clip. For coaches who want to tag statistics without building clip packages — a genuinely valid use case that the interface must support without friction.
• Keyboard navigation: Tab moves between fields. Enter confirms. Escape cancels. Number keys (1–9) select event type if shortcuts are configured. This supports the keyboard-first pattern from Sketch D without requiring it.

After the coach presses Enter/Confirm, the tag is saved, the clip is created (with auto-set bounds), and the overlay collapses. A brief confirmation toast appears at the bottom of the frame — then video resumes automatically after 1.5 seconds unless the coach explicitly pauses again.

• Confirmation toast: Summarizes what was saved — event type, player, clip saved/skipped, playlist destinations. Coach can verify without opening anything. Auto-dismisses after 1.5 seconds.
• [Z] Undo: Pressing Z in the 1.5-second window (or any time thereafter) undoes the last tag — removes the stat event, deletes the clip, and un-assigns from playlists in a single action. Addresses the undo/redo finding from the Pattern Library (absent or inconsistent in current Hudl).
• Auto-resume: Video resumes automatically after 1.5 seconds. Coach does not need to press play. The resume is smooth — not a hard cut. If the coach starts pressing T again (triggering another tag), the auto-resume is cancelled and the new tag overlay opens. The flow is designed to be continuous: watch → tag → confirm → watch → tag, with no manual play/pause management.
• Event counter increments: The [● 9 tagged] badge updates immediately, giving continuous feedback on session progress.

After the coach finishes watching the film (or at any point they choose to review), clicking [● 9 tagged] transitions to the review state. The layout switches to the timeline-first model from Sketch C: the timeline dominates the top half, the video player occupies the bottom half. All tagged events are visible as interactive markers on the timeline.

• Jump-to-tag navigation: Clicking any event marker on the timeline instantly seeks the video to that moment. Coach can review every tagged moment without scrubbing — just click next marker. No re-watching required.
• Inline editing: Clicking a marker populates the properties row below the timeline — event type, player, clip bounds, playlist assignments. All editable inline without a full re-entry flow. This makes corrections fast (a misattributed tag takes two clicks to fix: click marker → change player dropdown).
• [Publish All]: Single action to push all playlists to all players simultaneously. The session is complete. No per-playlist publishing required.
• Clip preview: The [Preview] button plays the clip in the video player below the timeline without navigating away. Coach can verify every clip is correctly bounded before publishing.

The keyboard shortcut system supports the full tagging workflow without mouse interaction for coaches who prefer it. Shortcuts are displayed in a persistent reference panel (toggled with ?) and visible as labels on all UI elements during the first three sessions.

The playlist panel is the delivery layer of the redesign — where tagged moments become organized, publishable packages for players. The core problem it solves: in the current Hudl interface, clips must be individually assigned to playlists after cutting, and playlists must be published individually. The redesigned panel makes playlist management a zero-marginal-effort consequence of the tagging session, not a separate administrative task. This wireframe set covers the playlist management view, the per-player delivery preview, and the publish flow.

Accessible from the review state or from the main navigation. Shows all playlists generated or updated in the current session. Each playlist shows its clip count, total duration, last-updated timestamp, and publish status.

• Playlists auto-populated by attribution: Every player who was attributed in a tag event during the session has a playlist automatically created and populated. Coach didn't build these — the tagging session built them. This is the attribution-driven auto-assign pattern from the Pattern Library applied at full scale.
• Team playlist: Always present. Contains all clips where the team playlist was checked (default: all clips). Coach can remove individual clips from the team playlist inline.
• [Preview]: Opens the player's playlist in the video panel for review before publishing. Coach sees exactly what the player will see.
• [+ New playlist from filter]: Opens a filter panel allowing the coach to create a theme-based playlist by selecting event types, players, or time ranges. This addresses the intent-based clip package gap identified in the Assist interview notes — the capability Assist does not provide.

Clicking [Preview] for any player opens a full-screen preview of exactly what that player will receive — a sequenced playlist of their clips with the coach's note attached to each one (if notes were added during tagging).

• Clip sequence list (left): Shows all clips in the player's playlist in chronological order. Each entry shows event type, timestamp, and a playback status indicator. Clicking any entry loads that clip in the preview panel.
• Coach note: Notes entered during tagging are displayed directly below the clip preview. This is the delivery vehicle for individual coaching feedback — the coach's instruction is attached to the specific moment that prompted it, not sent as a separate text message.
• [Remove from playlist]: One-click to exclude a clip from this player's delivery without deleting the tag event. Useful if a coach tagged a moment broadly and then decides it isn't appropriate for this player specifically.
• [+ Add to]: Add this clip to an additional playlist (e.g., a recruiting reel) without leaving the preview view. This is the context-menu multi-assign pattern from the Pattern Library.

Accessed via [+ New playlist from filter]. Allows the coach to create a thematic playlist — "All defensive breakdowns," "Jordan's shots this month," "Press trigger moments for film session" — by filtering the full tagged event library by any combination of criteria. The resulting playlist auto-populates immediately and can be published or saved for future use.

• Filter dimensions: Event type, player, game range, and severity (a custom field the coach can add to any tag during tagging). The combination of any of these produces a themed clip set.
• Multi-game range: The "Last 3 games" and "This season" options allow cross-game playlist building — a key capability for recruiting reels and player development reviews. This directly addresses the recruiting reel pain point from the Club Coach (Daniela) persona interviews.
• Live result preview: The clip count and total duration update in real time as filters are applied. Coach sees the scope of the playlist before creating it.
• Save as smart playlist (stretch): Once a filter is saved as a named playlist, it can optionally auto-update as new games are tagged — a smart playlist that accumulates over the season. This is the Smart Playlist pattern from the Pattern Library, noted as a stretch goal.

Publishing sends all prepared playlists to all attributed players simultaneously. The flow is designed to be a single confident action, not a multi-step wizard.

• Summary before publish: Coach sees the full publish scope — all playlists, all recipients — in a single glance before committing. This is the confirmation step that makes one-tap publish feel safe rather than reckless.
• Notification preference: Coach chooses how players are notified. Default (push + email) is appropriate for time-sensitive post-game delivery. Silent publish is useful for mid-season additions that don't require immediate player action.
• Single confirm action: One button. All playlists publish simultaneously. All 22 players receive their individual packages in the same action that delivers the team package. This collapses what currently takes 4–6 separate publish actions (one per playlist) into one.

The AI Suggest Layer does not replace the coach as tagger. The primary concept (Sketch B / Unified Tagging UI) remains the core design. The AI layer is a non-intrusive suggestion surface that appears when the system detects a potentially taggable moment — reducing the cognitive load of watching and tagging simultaneously, without removing coach agency over what gets tagged and how.

Every AI suggestion in this layer follows a single principle: the coach confirms, rejects, or ignores every suggestion. Nothing is tagged automatically. The AI suggests a moment and an event type. The coach decides whether it is tagged, how it is attributed, and whether a clip is created. This principle directly addresses the trust concern raised by the club DOC (Participant C) in the Assist Subscriber Interview Notes — "some of my coaches don't trust the Assist tagging accuracy for soccer-specific events." Suggestion + confirmation preserves trust while reducing effort.

When the AI detects a likely taggable moment during playback, a small badge appears at the edge of the video frame. It does not pause playback, does not animate aggressively, and does not block the view. The coach can act on it, ignore it, or dismiss it — all without interrupting their watch experience.

• Badge content: Event type classification + player jersey number if detected. Displayed as "Shot? · #7" — the question mark is intentional and always present, reinforcing that this is a suggestion, not a confirmed tag.
• Trigger key [T]: Pressing T with a suggestion active opens the tag overlay pre-filled with the suggested values. The coach then confirms or modifies as normal. This is one keypress instead of the cold-start flow (pause → open overlay → select event → select player).
• [Esc]: Dismisses the suggestion silently. No penalty, no re-prompt. The suggestion disappears and the badge does not reappear for the same detected moment.
• Badge timing: Appears 0.5 seconds after the detected moment (not at the exact frame — the coach needs time to register what happened before the suggestion arrives). Disappears after 4 seconds if not acted upon. Does not pause video.

When the coach presses T with an active suggestion, the tag overlay opens with AI-suggested values pre-filled — but all fields remain editable and the coach must confirm explicitly. The overlay is identical to the non-AI version (State 2 from the Unified Tagging UI) except for the pre-filled values and the source attribution.

• ◈ source indicator: A small icon marks every AI-suggested field. Coach always knows which values came from AI vs. their own last-used defaults. This transparency is not optional — it is core to the trust model established in the design principle above.
• All fields editable: The coach can change any field before confirming. If the AI got the event type wrong (e.g., suggested "Shot on Goal" but it was actually "Shot off Target"), one dropdown change corrects it. The AI saved all the setup work; the coach corrects the classification error.
• [REJECT ✕]: Rejects the suggestion completely — closes the overlay without tagging and marks the detected moment as a false positive. This is the trust-building mechanism: coaches who repeatedly reject a specific type of false positive (e.g., AI flagging defensive headers as shots) can be prompted to turn off that detection class.

A secondary value of the AI layer: it catches moments the coach missed. If the coach was distracted (a child interruption, a phone notification) during a detectable event, the AI creates a "missed event" marker in the timeline. After the session, the coach can review missed events and tag them from the timeline without re-watching the full film.

This pattern directly addresses the Interruptions finding from the Context of Use Notes — coaches are interrupted during film sessions, and currently have no way to recover missed moments except by re-watching. The AI suggestion layer makes missed-moment recovery a fast, structured review rather than an unguided re-watch.

This design thread requires real-time computer vision processing during video playback — specifically event detection and, ideally, jersey number recognition. As of March 2026, Hudl's Balltime AI technology (acquired February 2025) performs this for club volleyball only. Extending it to soccer and other field sports involves:

• Training data: Soccer event detection models require large labeled soccer-specific datasets. Hudl has access to this data through the Assist analyst team's tagged archive — potentially the largest labeled soccer coaching film dataset in existence — which is a genuine competitive advantage for building this capability.
• Real-time processing constraint: The suggestion badge pattern requires detection latency under ~500ms from event occurrence to badge display. This may require client-side model execution or edge processing, not a server round-trip. This is a hard engineering constraint that could affect feasibility.
• Soccer specificity: As noted by Participant C in the Assist interviews, soccer is harder to auto-classify than football due to continuous play and context-dependent event definitions (a "defensive error" requires tactical context, not just visual detection). The design accounts for this by always requiring coach confirmation — false-positive suggestions are dismissed with one key; they do not pollute the data.
• Opt-in only: The AI suggestion layer is off by default. Coaches who prefer a clean interface without suggestions enable it in settings. This ensures the primary concept (manual unified tagging) is not compromised for coaches who don't want AI assistance.

Decision notes document the reasoning behind every significant design choice made during the lo-fi phase — including choices to reject an approach, defer a feature, or accept a known tradeoff. They are organized by decision type and cross-referenced to the research and competitive work from Steps 02 and 03. The goal is to make the design rationale auditable: if a reviewer, stakeholder, or future designer questions a choice, the reasoning exists in writing, linked to specific evidence. This is especially important for a speculative concept project where design decisions cannot be validated by production data.

• Visual hierarchy of the overlay: The lo-fi wireframe establishes field order (Event → Player → Clip → Playlist → Note) but does not specify visual weight, typography scale, or color treatment. The right visual hierarchy will become clear during usability testing — which fields coaches look at first, which they skip. Deferred to Step 05.
• Clip preview thumbnail in the overlay: Whether the overlay should show a thumbnail of the auto-clip bounds during entry is unclear. The thumbnail adds reassurance but also adds visual weight to the overlay. Left unresolved in lo-fi — test with and without in prototype testing.
• Mobile tagging interface: The wireframes are desktop-only (1280×800). A mobile-optimized version (touch targets, portrait layout, simplified clip controls) is a documented need from the research but is out of scope for this prototype phase. Noted for future iteration.
• Notification timing and content for players: The publish flow shows notification preference but does not specify notification content (what does the push notification say? Does it include a preview thumbnail?). This requires content strategy decisions deferred to the hi-fi phase.
• Opponent film tagging: The Assist interview notes identified opponent scouting as a major remaining manual workflow even for Assist subscribers. The current wireframes assume coach-film tagging. Opponent film tagging uses the same interface but may require different defaults (no player attribution, different event type set). This is a noted extension, not a separate design problem.

• Auto-resume (unusual): Most video tools require manual play after any pause. Auto-resume is uncommon because it feels presumptuous — the user didn't ask to resume. Here it is justified by the use case: a coach tagging a 90-minute game at 11pm does not want to press play 60+ times per session. The 1.5-second window and the visible progress bar make the auto-resume feel transparent rather than surprising. If usability testing finds it causes confusion, revert to manual resume.
• Confirmation toast instead of modal: Most high-stakes confirmation UX (saving data, sending to recipients) uses a blocking modal. Here the toast is appropriate because the coach needs to resume watching immediately — a blocking modal adds a click before playback resumes, which multiplies across 60 events per game. The Undo capability (Z key) provides the safety net that makes a non-blocking toast acceptable.
• No undo time limit: Standard undo in creative tools (Photoshop, Figma) is session-scoped but not time-limited. The decision to make Undo available for any tag action throughout the entire session (not just in a 30-second window) was intentional: fatigued coaches at 1am may not notice a tagging error until reviewing the timeline an hour later. Undo must work then too.
• Pre-fill from last-used over recency-by-event-type: An alternative pre-fill model would remember the last player attributed for each event type separately (last shot player, last pass player). This is more sophisticated but requires more UI to expose and increases the chance of a wrong default being less obvious. Last-used-globally is simpler, more predictable, and correctable with one change. Start simple; add sophistication only if research shows it is needed.

• Will coaches trust auto-resume? Auto-resume is the most behaviorally novel element of the design. It inverts the normal coach habit (manual play after every pause). Research participants were told about it and reacted positively in concept — but untested behavior in a real session may feel different. This is the highest-priority question for Step 05 usability testing.
• How many fields is the right number in the overlay? The current overlay has 5 fields: event type, player, clip bounds, playlists, note. The note field may be one too many — coaches reported rarely adding notes during late-night tagging. Removing the note field from the default overlay (move to expanded/optional view) may improve speed. Test both versions.
• Does the [SKIP CLIP] option cause confusion? The existence of a "skip clip" option may prompt coaches to question whether they should be skipping clips more often — potentially undermining the primary value proposition of creating clips at tagging time. The button label and placement need careful testing.
• What is the right ±default clip window? ±8 seconds was chosen by judgment. The right value may vary by event type (a tackle may need ±5s; a transition sequence may need ±12s) and by sport (soccer vs. football vs. basketball). A brief test with 3–5 coaches reviewing auto-clip output would validate or refine the default before hi-fi.
• How discoverable is the T key trigger? The T key shortcut is the fastest entry point to tagging but requires knowledge. The [T] button in the transport bar provides the visual cue, but first-time users may not see it. An onboarding hint (shown once, dismissible) may be needed. This is a discoverability question, not a layout question — and its answer will affect the onboarding design in the hi-fi phase.

Most usability studies compare one design against a baseline. This study uses three conditions because the research question is more specific: the redesign is not just competing against Hudl's current interface — it is implicitly competing against Hudl Assist, the paid service that already solves the two-pass problem for coaches who can afford it. Testing only Redesign vs. Base would answer "is this better than nothing?" Testing all three answers the more important question: does this interface deliver enough of Assist's time savings that a coach wouldn't need to pay for Assist? The answer has direct product strategy implications that a two-condition study cannot surface.

Participants are randomly assigned to a condition order using a Latin square rotation to control for learning effects. All participants experience all three conditions across three sessions spaced one week apart. The one-week gap is intentional: it simulates real coach usage cadence (one game per week) and reduces within-session carry-over between conditions.

• Target n: 8 participants across three sessions each (24 total sessions). Sample size is constrained by access to the target population and the time commitment required (three 90-minute sessions per participant). 8 participants is adequate for identifying usability problems at the lo-fi prototype stage; a larger sample is planned for hi-fi testing in Step 09.
• Inclusion criteria: Active coach (at least one season completed in the last 18 months), current Hudl subscriber (Base tier), personally responsible for post-game film work (not delegated entirely to a manager or assistant), game frequency of at least one per week during season.
• Exclusion criteria: Current Hudl Assist subscriber (would contaminate Condition C reactions with pre-existing familiarity), fewer than 6 months of Hudl use (insufficient baseline experience), role limited to player/parent film consumption only.
• Persona distribution target: 3 Teacher-Coach (Persona 01), 3 Club Coach (Persona 02), 2 Tech-Reluctant Veteran (Persona 03, participating in Condition A only for baseline — not full 3-condition due to role constraints). Assist subscriber persona (04) is represented through Condition C walkthrough, not as a participant group.
• Recruitment source: Liverpool FC International Academy Utah coaching network, Utah Youth Soccer Association contacts developed during Step 02 research, and one Nevada-based club reached through Daniela (Persona 02 composite) connections.

Each participant is given access to a 90-minute soccer game film pre-loaded in a test Hudl account. The film is a real game (from a consenting program), not a synthetic recording. The task is as close to a real post-game session as possible.

Same game film, same task requirements. The prototype is presented in Figma Prototype mode at 1280×800 with simulated video playback (pre-cut video segments that advance when the participant interacts with the interface). The interaction fidelity is high enough that timing data is meaningful, though not identical to a fully built product.

Administered after each condition session. Takes approximately 5 minutes. Responses are condition-specific — participants complete a version of the questionnaire immediately after each of their three sessions.

• On a scale of 1–5: "I felt confident I could use this workflow after every game." (1 = strongly disagree, 5 = strongly agree)
• On a scale of 1–5: "The time I spent on film work in this session felt like a reasonable use of my time."
• On a scale of 1–5: "I was able to focus on coaching decisions during this session rather than on operating the software."
• On a scale of 1–5: "The clips I produced in this session accurately captured the moments I wanted to share with players."
• Open: "What was the most frustrating moment in this session? Describe exactly what happened."
• Open: "What would you change about this workflow if you could change one thing?"
• Closed (Condition B only): "Would you use this interface instead of your current post-game workflow?" (Yes / No / Maybe with conditions)
• Closed (Condition C walkthrough only): "If this service were free and built into the base platform, would that change how you use Hudl?" (Yes / No / Already on Assist)

• Format: Remote video call (Zoom). Participant shares screen; researcher observes and records. Session recording with explicit consent.
• Duration per session: 90 minutes (60 min task + 10 min questionnaire + 20 min debrief interview).
• Think-aloud protocol: Participants are asked to narrate their thoughts during the task ("tell me what you're thinking as you do this"). Researcher does not offer guidance or correction during the task — only clarifying prompts if the participant is completely stuck for more than 3 minutes.
• Consent and data handling: Participants consent to screen recording and verbal recording. Recordings are stored locally (not cloud-uploaded), transcribed, and anonymized before analysis. No identifying information is shared in published documentation. All game film used in sessions is from consenting programs.
• Compensation: Participants receive a $50 gift card per completed session ($150 total for three sessions). This is appropriate for the time commitment and reflects the professional knowledge they are contributing.
• Debrief: After all three sessions are complete, participants receive a summary of the findings and are informed of the project's speculative nature. They are invited to review and correct any direct quotes attributed to them.

This document contains structured notes from all 24 testing sessions (8 participants × 3 conditions). Notes follow a consistent format: pre-session context, task-by-task observation log, post-task questionnaire scores, and a researcher synthesis written within 24 hours of the session. Direct quotes are preserved verbatim and marked with quotation attribution. Time measurements are from session recordings (timestamps noted). Observations marked [OBS] are researcher inferences; quotes marked [P#] are participant statements. Participant numbers correspond to internal tracking and do not map to any external identifier.

CONDITIONS: A → B → C (Latin square rotation 1) · SESSIONS: Oct 11, Oct 18, Oct 25 · TOTAL RECORDED TIME: 4h 22min

• [OBS] P1 configured the tag panel quickly (under 4 min) — familiar with the interface. Tag pass took 88 min for 9 events. [OBS] Tag quality degraded in the second half — 3 events tagged without player attribution. P1 later said he "just wanted to get through it."
• [P1]: "I've done this so many times. I still hate having to go back through for the clips. It's the same game. I've already watched it."
• [OBS] P1 made a written list of 5 clip timestamps during the tag pass — a paper workaround. Referred to it during Pass 2. Missed one timestamp (29:14 was written as 29:41 — transposed digits) and spent 6 minutes locating the moment.
• T1 completion: 88 min. T2 completion: 74 min. T3 completion: 12 min. Total: 174 min. Error count: 4 (3 missing attributions, 1 wrong clip bound).

• [OBS] P1 discovered the T key trigger within 30 seconds — noticed the [T] button label in the transport bar. First overlay use took 42 seconds (exploring fields). By the 4th tag, time per overlay interaction was 11 seconds.
• [P1]: "Oh — it already has the player from the last one. That's smart." (on seeing pre-filled player default)
• [OBS] P1 accepted default clip bounds for 7 of 9 tags without adjustment. Adjusted bounds twice — once for a transition sequence he wanted more context on (extended to +14s), once to trim a clip he felt started too early.
• [P1]: "The fact that the clip is just there — I don't have to go back — this is the thing. This is exactly the thing." (at the review timeline, seeing all clips populated)
• T1+T2+T3 combined (single pass): 73 min. Error count: 1 (wrong event type on first tag, corrected via undo immediately). Post-task confidence: 5/5. Adoption intent: Yes.

• [P1] reviewed a real Assist breakdown output (pre-tagged, with per-player playlists). Spent 22 minutes reviewing. Reacted positively to stat completeness. Raised immediate concern: "The tags aren't mine. I can't tell which of these passes was the one I actually wanted to show Jordan."
• [OBS] P1 navigated to the team's last three games and tried to find a specific play sequence he remembered from two games ago. Could not filter Assist output by tactical theme — had to watch full film to find it. Time spent: 14 min searching, did not find the specific moment.
• Assist comparison intent: "I would still want to tag it myself. This is faster but it's not my data." Marked "Maybe" on adoption intent with condition: "If it had a way to add my own tags on top of the Assist ones."

CONDITIONS: B → C → A (Latin square rotation 2) · SESSIONS: Oct 12, Oct 19, Oct 26

• [OBS] P2 had the most positive first-session reaction of all participants. As a high-tech user (Persona 02 profile), she immediately grasped the overlay model and began experimenting with keyboard shortcuts within the first 5 minutes without prompting.
• [P2]: "Wait — does this work on iPad? Because if this works on iPad I would use this from the bench." (mobile capability question, noted — out of current scope)
• [OBS] P2 used the playlist builder to create a custom "Recruiting Reel — Sofia" playlist during the review phase, unprompted. This was a stretch feature included in the prototype but not highlighted in the task script. She discovered it via [+ New playlist from filter].
• [P2]: "This. This is the thing I've been making in iMovie manually for three years. I just did it in about four minutes."
• T1+T2+T3: 68 min. Error count: 2. Post-task confidence: 5/5. Adoption intent: Yes (emphatic).

• [OBS] P2 visibly frustrated by the mode switch between tagging and clip editing. Having used the unified interface first, the two-pass structure felt actively offensive rather than merely inconvenient.
• [P2]: "I now know what this is supposed to feel like. Going back to this is like... I don't know, like going back to a flip phone."
• T1+T2+T3: 201 min. Error count: 6. Post-task confidence: 2/5.

Full session notes for P3–P8 follow the same format as P1–P2. Key excerpts and findings from each are documented here; complete verbatim transcripts are held in the research archive.

6 of 8 participants completed the Condition C Assist walkthrough (P7 and P8 were excluded — P7 due to role constraints, P8 due to Veo preference making the Assist comparison non-applicable). Key themes across the 6 walkthroughs:

• Positive reactions universally to stat completeness: All 6 noted that Assist's stat output was more complete than what they produced in Condition A. 4 of 6 said the completeness was "because someone else did it" — they knew their own Condition A tags were incomplete due to fatigue and time pressure.
• Agency concern universally raised: All 6 made some version of P1's comment about the tags "not being mine." The Assist output felt like data about their game rather than their interpretation of it. This is a meaningful distinction — Assist produces an analyst's reading; the redesign produces the coach's own reading, faster.
• Thematic gap universally identified: All 6 tried to find a specific thematic clip package within the Assist output (prompted by researcher: "Can you find all the moments where your press triggered a turnover?"). None could do it without watching the full film. This is the gap the Theme-Based Playlist Builder in the redesign directly addresses.
• Price sensitivity split: 3 of 6 said they would consider Assist if their program funded it; 3 said they would not pay out of pocket under any circumstances. The latter group's response to Condition B ("would this reduce your need for Assist?") was 3/3 "yes."

Every design decision that changed as a result of testing is documented here in chronological order. Each entry records: the finding that prompted the change, the original design, the revised design, the rationale for the specific revision chosen, and the session or sessions that surfaced the issue. Entries are numbered for cross-reference in the Before/After Wireframe Pairs (Deliverable 4). The log is the design's paper trail — it makes visible that every revision was evidence-driven, not preference-driven.

Changes are classified by type: Critical = addressed immediately, affected test validity if not fixed, Significant = addressed before hi-fi phase, Minor = logged for hi-fi consideration, no immediate change to lo-fi prototype.

TYPE: Significant · SURFACED: Sessions P5 (Oct 26), P6 (Oct 27) · BEFORE/AFTER: See Wireframe Pair 01

Finding: P5 described auto-resume as feeling "pushy" — the interface was making a decision the coach felt was theirs to make. P6 independently described the same feeling. P1–P4 had no issue with auto-resume. The split (2 negative, 4 neutral-positive out of 6 who experienced it) is enough to justify making it configurable rather than changing the default for everyone.

Rationale for opt-in rather than removal: P1 specifically praised the auto-resume as reducing fatigue across a long tagging session. Removing it entirely would regress P1's experience. The settings toggle preserves both preferences. The default is off (manual resume) because the penalty for an unexpected auto-resume (missing the next moment) is higher than the penalty for manual play (one extra keypress).

TYPE: Significant · SURFACED: Sessions P1 (Oct 18), P3 (Oct 19), P4 (Oct 19), P5 (Oct 26) · BEFORE/AFTER: See Wireframe Pair 02

Finding: 4 of 6 participants with a fully visible note field made no use of it but reported feeling like they "should" add a note — the empty field created a mild sense of obligation. Tab-navigation skipped it in all 4 cases. In the Annotated Decision Notes, this was flagged as an open question. Testing confirmed: the note field in the default overlay adds cognitive overhead with no value for the majority of tags.

Rationale: Notes are valuable for specific clips (recruiting reel moments, corrective feedback for a player) but not for the majority of tagged events. The collapsed [+ Add note] trigger is discoverable without being mandatory. Coaches who want to add notes regularly can learn the trigger quickly; coaches who never want notes don't see the empty field on every tag.

TYPE: Significant · SURFACED: Session P6 (Oct 27) · BEFORE/AFTER: See Wireframe Pair 03

Finding: P6 tried to trim a clip to start exactly on a tackle contact — a frame-precise requirement. At 2-second increments, she overshot by one press and then overshot in the other direction. Spent 90 seconds adjusting a bound that should have taken 10 seconds. Described it as "more annoying than just going back and doing it in the clip editor" — which directly undercuts the redesign's value proposition for clip precision.

Rationale for tiered approach rather than frame-by-frame default: Frame-level precision in the overlay would require either a video preview (increasing overlay size significantly) or a numeric timecode input (requiring mental arithmetic while fatigued). 1-second nudge handles the majority of adjustment needs; the [Fine] toggle and [Scrub] option serve edge cases without burdening the default interaction with a complex control set.

TYPE: Minor → addressed in lo-fi update · SURFACED: Sessions P5 (Oct 26), P6 (Oct 27) · BEFORE/AFTER: See Wireframe Pair 04

Finding: 2 of 8 participants did not discover the T key trigger during the session — they used only the on-screen [T] button. Both described the single-letter button as "not obviously a button." P7 (tech-reluctant veteran) did not notice the button at all until explicitly pointed to it.

Revision: Button label changed from "[T]" to "[Tag ⌨]" with the keyboard icon serving as an affordance signal. A first-session tooltip ("Press T at any moment to tag it — or click here") appears on first use and is permanently dismissible. The tooltip addresses the discoverability open question flagged in the Annotated Decision Notes §05 without requiring a full onboarding wizard (which was rejected in the Pattern Library).

TYPE: Minor · SURFACED: Session P4 (Oct 19) · BEFORE/AFTER: No wireframe pair — label-level change only

Finding: P4 tagged a "Defensive error — positional" event and was surprised when it defaulted to the Team playlist. She explicitly did not want the team to see an individual player's defensive error in the shared team view — she wanted it only in that player's individual playlist as corrective feedback. The Team default had correctly been described in the Decision Notes as having an opt-out override, but P4 did not notice the unchecking option in time (she had already confirmed before realizing).

Revision: Team playlist default is now configurable per event type in settings. "Corrective" or "Development" event types (user-defined) default to player-only; "Highlight" and "Tactical" types default to team + player. This requires a one-time setup step but prevents the default from creating unwanted team-visible content for coaches who use corrective event types routinely.

TYPE: Minor · SURFACED: Sessions P1 (Oct 18), P3 (Oct 19) · BEFORE/AFTER: See Wireframe Pair 05

Finding: 2 participants (P1 and P3) expressed mild uncertainty after confirmation about whether the auto-clip had captured the right moment. Neither opened the review timeline to check — they trusted the system and moved on — but both mentioned in the post-session debrief that they would have felt more confident if they could "see a little of what got clipped" in the confirmation moment.

Revision: Confirmation toast expanded to include a 3-second thumbnail preview of the first frame of the auto-clip. The toast grows from one line (text only) to a small two-column layout: text summary on the left, thumbnail on the right. Coach can verify the clip frame visually without opening the review timeline. Toast auto-dismisses or collapses after the thumbnail is displayed for 1.5 seconds.

Open question this revision creates: The expanded toast is slightly larger — it may occlude the bottom portion of the video frame more than the text-only version. To be tested in the hi-fi phase (Step 09) against the thumbnail-free version.

Each wireframe pair documents one change made as a result of testing — the state of the interface before the testing finding, and the revised state after. Pairs are numbered to match the Iteration Log entries (ILG-01 through ILG-06). Each pair includes the ASCII wireframe states, the specific change highlighted, and a note on what the pair is intended to demonstrate. These are lo-fi documentation artifacts — they do not represent the final visual design.

What this pair demonstrates: A feature that is beneficial for high-frequency taggers (P1: "that's what makes the session feel fast") and disruptive for lower-cadence or more deliberate coaches (P5, P6). The revision surfaces the same capability through a setting rather than forcing a behavioral choice. No feature is removed — coach preference determines the behavior.

What this pair demonstrates: Progressive disclosure — show the minimum required fields by default, expand only when the coach actively wants more. The note field is not removed; it is placed behind a one-tap trigger. This is a pure reduction in default cognitive load with zero loss of capability.

What this pair demonstrates: The cost of coarse defaults on precision-sensitive interactions. 2-second increments were chosen initially to keep the control simple — but they made the common task of fine-tuning a clip start point harder than the current Hudl editor, which undermines the redesign's core promise. 1-second default with tiered options restores precision without complexity.

What this pair demonstrates: A label legibility issue masquerading as a feature discoverability issue. "[T]" is a keyboard shortcut notation, not a button label — it communicates to experienced users and fails for everyone else. "[Tag ⌨]" communicates the action AND the shortcut simultaneously. The tooltip handles first-use onboarding without a wizard. Small change, large discoverability impact.

What this pair demonstrates: The value of low-cost confirmation signals. A thumbnail adds approximately 60×45px to the toast — a minor layout change — but it converts an abstract confirmation ("clip saved") into a concrete visual verification. The coach's trust in the auto-clip system is directly related to how often they can see that it captured the right thing. This change invests in that trust without adding an explicit review step.

Several design decisions were challenged during testing and survived unchanged. These are worth noting explicitly because they demonstrate that the testing validated those choices — not that testing was ignored.

• Pre-filled defaults (last-used values): Praised by P1, P3, P4. No participant found them disruptive. P2 described them as "the single thing that makes the overlay feel fast." Unchanged.
• Attribution-driven playlist auto-assign: No participant was confused or annoyed by their player's playlist being pre-checked. P4's issue (ILG-05) was with the Team default, not the player default. The player auto-assign pattern was correct. Unchanged.
• ±8s default clip bounds: 7 of 8 participants accepted the default without adjustment for the majority of their tags. The precision issue (ILG-03) affected only 2 specific moments across all sessions. The default is correct; the controls for deviation needed improvement. The default itself unchanged.
• Timeline-first review state: All participants who reached the review state (6 of 8) used jump-to-tag navigation rather than scrubbing. P3: "I keep forgetting I don't have to scrub anymore. It's a good thing to forget." Unchanged.
• Single-action publish: No participant found the publish confirmation screen confusing or insufficient. P1 said "that's it?" (positively). Unchanged.

In a real product environment, this presentation would be delivered to a cross-functional audience: a product director or VP of Product, an engineering lead, a revenue or growth stakeholder who owns the Assist product line, and possibly a customer success or community manager who has direct exposure to coach complaints. Each of these roles has a different primary concern — and the presentation is structured to address all four rather than optimizing for one. The business case section is not an afterthought; it is the first thing the revenue stakeholder will evaluate, and it must hold up to scrutiny before the design work is given airtime.

This document presents the deck slide-by-slide as annotated narrative. In the actual Figma-produced deck, each section below corresponds to one or more slides. Speaker notes appear in the annotations.

SLIDES 1–4 · ~5 MINUTES

"The Two-Pass Problem: A Case for Unified Tagging in Hudl's Base Platform"
Speculative concept project · March 2026 · [Designer name]

Speaker note: Lead with what this is: a speculative concept project grounded in research, not an official Hudl proposal. The goal of this presentation is to make the case that a specific workflow problem — documented, quantified, and tested — is worth solving at the interface level, and to show what that solution looks like. If this were a live product review, the ask at the end of this deck would be: fund a hi-fi prototype for a broader validation study.

Visual: split-screen portrait of the teacher-coach persona (left) and the club coach (right), with a single stat below each. Left: "3.2 hours average post-game film time. 1.1 hours of it is a second pass they already did." Right: "4 of 5 coaches send a timestamp in a group text instead of a Hudl clip. Not because they don't know how. Because the workflow doesn't give them time."

Speaker note: Don't lead with the solution. Lead with the person. These are real coaches — composite profiles built from 11 interviews plus 47 public reviews. The numbers are not made up: the session timing data comes from Step 05 usability testing (Condition A median: 194 minutes). The timestamp workaround was identified in 4 of 5 non-Assist coaches in interview research. This slide exists to make the problem human before it becomes a metric.

Visual: a simplified flow diagram of the current Hudl workflow — two parallel bars representing Pass 1 (stat tagging, ~88 min) and Pass 2 (clip cutting, ~74 min) with a mode-switch arrow between them labeled "navigate to clip editor." A third bar below both shows the redesigned single-pass flow (~81 min total). The diagram makes the redundancy architectural, not behavioral.

Speaker note: The most important thing this slide communicates is that this is not a coach problem. It is not that coaches lack discipline or time management. The interface structure forces them to watch the same film twice to accomplish what should be one operation. The red line in the diagram is not a coach habit — it is an interface architecture decision that has a measurable cost in hours every week.

Visual: Hudl Assist product page screenshot (publicly available), showing the Assist value proposition: "Get a full breakdown of every game — stats, clips, and player playlists — delivered overnight." Below it, a callout: "Hudl's solution to the two-pass problem is a $900–$3,300/year add-on service. That is a product strategy choice, not a technical limitation."

Speaker note: This slide is the most important pivot in the deck. It reframes the presentation from "here is a problem Hudl hasn't noticed" to "here is a problem Hudl has explicitly monetized — and this is an argument about whether monetizing it is the right long-term move." This framing respects the business intelligence of the room while making a strategic case. Do not be apologetic about it. The existence of Assist validates the problem completely.

SLIDES 5–9 · ~8 MINUTES

Visual: research method overview — icons for 11 interviews, 47 public reviews, 8 usability participants, 24 sessions, 3 conditions. Timeline spanning October–March. Brief one-line description of each method and what it contributed.

Speaker note: This slide answers the "how do you know?" question before it gets asked. The sample is small but triangulated — qualitative interview findings were validated by public review data and confirmed by usability test behavior. None of the core findings rest on a single data source.

Five finding cards, each with a headline and a representative quote. Findings: (1) Time scarcity is structural, not personal. (2) Workarounds are embedded and invisible. (3) Assist solves one layer, not all. (4) Fatigue degrades tagging quality. (5) Reluctant users are protected by staff structure — and need to stay that way.

Speaker note: Finding 3 is the one that will get a reaction from the Assist revenue stakeholder. Read the room. The finding is not hostile — it is accurate and ultimately supportive of the argument. Assist subscribers still do manual film work. The redesign creates value for them too. The issue is that Assist leaves 70–80% of Hudl's base untouched, and that's the population this redesign serves.

Slide 7: the head-to-head quantitative table — Condition A vs. Condition B across all six success criteria metrics. Headline callout: "58% reduction in total task time. All six success criteria met or exceeded."

Slide 8: three participant quotes selected for cross-persona coverage — one from a teacher-coach (P1: "The fact that the clip is just there — I don't have to go back — this is the thing"), one from a club coach (P2: "I just made in four minutes what I've been making manually in iMovie for three years"), and a note from P7 (tech-reluctant veteran) confirming zero regression: "I didn't even notice the [Tag] thing until you pointed it out."

Speaker note: The P7 quote is critical for the "does this hurt existing users?" objection. Address it before someone asks. The redesign is additive — the veteran who just wants to watch film has an identical experience because the new tagging interface is invisible until triggered. This is not a rebrand. It is a feature layer.

Visual: 6-participant Condition C result. Quote from P1 about Assist tags "not being mine." The thematic clip gap (no participant could build a thematic playlist from Assist output without watching the full film). Closing stat: 6 of 8 participants said the redesign would reduce their need for Assist.

Speaker note: Present this as a signal, not a verdict. "6 of 8" is from a small sample. What it tells us is directional — coaches value agency over their own tagging data, and Assist's fully automated approach trades that agency for speed. The redesign gives them the speed without the trade-off. Whether that is a threat to Assist revenue or a case for folding this capability into a new Assist tier is a business decision, not a design decision. Surface it; don't resolve it in this deck.

SLIDES 10–14 · ~10 MINUTES

Single-statement slide: "Watch → Notice → Tag → Resume. One flow. No mode switches. No second pass." Below it, the four states of the unified interface in thumbnail — idle, overlay open, confirmation, review — showing the complete interaction arc on one slide.

Slide 11: the idle state and the triggered overlay state side by side — full-frame video when playing, bottom-anchored overlay when tagging. Annotated to show the key innovation: the clip, the stat, and the playlist assignment happen in the same pause. Three callouts: pre-filled defaults (last-used event + player), auto-clip bounds (±8s, adjustable), and attribution-driven playlist auto-populate.

Slide 12: the review timeline state — timeline-first layout with jump-to-tag navigation, inline editing, and the single-action Publish All. Annotated to show what the coach does not have to do: no second film pass, no re-scrubbing, no per-playlist publish actions.

Speaker note: These two slides carry the most weight in the deck. Spend time on them. The overlay is not a complicated interaction — it looks simple on screen — but communicate that its simplicity is the result of deliberate choices. The pre-filled defaults alone eliminate roughly 60% of the keystrokes in the current two-pass workflow. Point to the annotation, not just the visual.

The playlist overview showing auto-populated per-player playlists alongside the theme-based playlist builder. Headline callout: "The club coach's recruiting reel problem, solved inline." Before/after: current workflow (iMovie, manual export, 2–3 hours) vs. theme-based playlist builder (4 minutes, P2 session data).

Single slide, clearly labeled "Speculative — not the primary concept." The suggestion badge concept — a non-blocking prompt that detects likely taggable moments and surfaces them for coach confirmation. Three-line summary of what it requires (real-time computer vision, Balltime AI extension to soccer), why it is not the primary concept (coach agency, sport specificity concerns, trust), and why it is included (forward-looking product direction; Hudl has the data asset to build it). Offer to go deeper in Q&A if there is interest.

Speaker note: Don't over-explain this slide. The AI thread is a signal about product direction, not a deliverable at this stage. If the engineering lead wants to dig into feasibility, that's a great signal — note it and schedule a follow-up. If the room is skeptical, acknowledge that the primary concept doesn't require it and move on.

SLIDES 15–18 · ~7 MINUTES

Visual: a simple segment diagram. Hudl's total subscriber base (referenced from public Hudl figures: 200,000+ teams). Assist subscribers (estimated 5–10% based on pricing and market data). Base subscribers who are currently not using advanced features due to workflow friction (estimated large majority of the non-Assist base). The redesign's target: the non-Assist base — the largest segment by volume, currently the lowest by feature utilization.

Speaker note: Hudl's business is predominantly subscription revenue from the base tier. If the majority of base subscribers are not using the features that differentiate Hudl from a simple video hosting service — because the workflow is too friction-heavy — then churn risk concentrates exactly here. This slide frames the redesign as a retention and feature-adoption investment, not just a UX improvement.

The competitive matrix from Step 03 reduced to three rows: Hudl Base (single-pass: none, price: $$), SportsVisio (single-pass: partial, price: $), Nacsport (single-pass: full, price: $$$). Headline: "The platform that solves this at the $300–$800/year price point wins the teacher-coach and club-coach segment." Note that SportsVisio's marketing copy explicitly targets programs "without a video coordinator" — Hudl's same primary user segment — at a lower price point.

Speaker note: This slide is for the product director who thinks about market position. The argument is not "SportsVisio will beat Hudl" — Hudl's network effects and data moat are substantial. The argument is "SportsVisio is picking off the segment most frustrated by exactly the workflow this redesign fixes, and they're doing it at a lower price." That's a known attrition vector that this investment closes.

A clean two-column slide: "What the redesign does to Assist revenue" (left) and "What the redesign does for Hudl overall" (right). Left: partial cannibalization of Assist subscription revenue among coaches who adopted Assist specifically for the two-pass problem (Participant D: "I would not have paid for Assist if the base platform did this"). Right: increased base tier feature utilization, reduced churn from workflow-frustrated coaches, potential for a new "Assist Lite" tier that bundles the redesign with lighter automation at lower price. Full analysis in the Trade-off Analysis deliverable (this deck summarizes it).

Speaker note: Don't avoid this slide. The Assist revenue stakeholder is going to raise this concern whether the slide exists or not — better to surface it on your terms and with analysis attached. The Trade-off Analysis (Deliverable 2 of this step) goes into full detail. This slide signals that the cannibalization question has been taken seriously, not ignored.

The deck does not recommend a business decision — it presents three options and their implications. Option A: ship the redesign as a base-platform improvement, accept partial Assist cannibalization, recover via increased base feature adoption and reduced churn. Option B: position the redesign as a new "Assist Lite" tier at an intermediate price point — capturing some Assist revenue while being substantially cheaper than the full service. Option C: hold the redesign and continue the current Assist strategy, accepting ongoing attrition to SportsVisio and similar platforms among the workflow-frustrated segment.

Speaker note: Ending the business section with three options rather than a recommendation is intentional. The designer does not own the revenue model. The design team's job is to show what is technically possible, what coaches actually want, and what the competitive landscape looks like. The product director and revenue stakeholder own which option is right given the financials the presenter doesn't have access to. Offering three options is not hedging — it's respecting the decision rights of the room.

SLIDES 19–21 · ~5 MINUTES

Deliverables inventory — a table of every artifact produced across Steps 01–06, organized by type: research (personas, interview synthesis, behavioral archetypes, context notes, Assist interview notes), analysis (competitive matrix, workflow comparison, journey map, friction audit, pattern library), design (concept sketches, four lo-fi wireframe sets, 5 before/after pairs, iteration log), and validation (3-condition test protocol, session notes, aggregate results). This slide exists to make visible the scope of evidence behind the design direction — it is not a portfolio slide. It is a credibility signal.

Steps 07–10 summary: Step 07 (hi-fi mockups + developer specs, Figma), Step 08 (second usability study, hi-fi prototype, expanded participant pool), Step 09 (design system integration, accessibility audit), Step 10 (portfolio presentation, open questions, retrospective). Timeline: Steps 07–10 are estimated at 6–8 weeks from stakeholder approval of the direction established in this presentation. Flagged dependencies: access to Hudl's current design system tokens (publicly available via Figma community), a second round of participant recruitment, and one consenting Assist subscriber for the hi-fi comparison test.

For this concept project context: "The ask is feedback. Does the framing of the problem resonate? Does the research feel credible? Does the design direction address the right problem? What would make this more compelling as a portfolio piece or as an actual product proposal?"

In a real product context the ask would be: "We are requesting approval to move to hi-fi mockups and a second, larger validation study. The specific go/no-go decision we need from this room is whether the direction documented in this deck — unified single-pass tagging as a base-platform improvement — is a direction the product team is willing to explore. We are not asking for a shipping commitment. We are asking for a green light to invest design and research resources in validating this at higher fidelity."

This analysis exists because the redesign does not exist in a vacuum — it exists in direct relationship with a revenue-generating product line (Hudl Assist) that partially solves the same problem it addresses. Ignoring that relationship would be analytically dishonest and would undermine the credibility of the design project in any real stakeholder review. This document takes the relationship seriously: mapping what Assist does, what it doesn't do, what the redesign offers that Assist cannot, and what the cannibalization risk looks like with specificity.

This analysis is not a recommendation about Assist's future. It is a structured comparison that a product team could use to make an informed strategic decision. The designer's role is to provide the analysis; the business decision belongs to the stakeholders who own the revenue model.

Hudl Assist is a human-analyst service that receives uploaded game film and returns, within 6–24 hours: complete stat event tagging (using Hudl's standard taxonomy), per-player clip playlists (every moment each athlete appears), and a stats dashboard populated from the analyst's tags. For coaches who subscribe to it at the right tier for their sport, it delivers genuine, measurable value:

• Eliminates the two-pass problem for own-game review: The analyst does both passes. Coach time per game drops from 3–4 hours to 30–60 minutes (review of output only). This is validated by all four Assist subscribers interviewed in Step 02 and confirmed by Participant D's pre/post comparison ("3–4 hours before, 30 minutes now").
• Produces complete stat tagging: Analyst-tagged output is more complete than coach-tagged output in controlled testing. Condition A participants produced a median 9 tagged events; Hudl's own documentation suggests full analyst tagging covers 40–60+ events per soccer match. Completeness matters for longitudinal data — season-over-season shot charts, pass completion rates by player, and opponent scouting databases are only useful if the data is consistently gathered.
• Requires zero interface proficiency: A coach who cannot operate Hudl's tagging interface at all still receives full analytical output via Assist. This is meaningful for the Tech-Reluctant Veteran persona at scale — programs with technophobic head coaches still get film data.
• Scales to multi-team programs: For a club director of coaching managing 6 teams (Participant C), Assist's per-team pricing and centralized output is more tractable than training 6 coaches to tag consistently. The economies of scale make Assist increasingly attractive as program size grows.

Despite solving the two-pass problem for routine game review, every Assist subscriber interviewed in Step 02 still spent 1–3 hours per week in the base Hudl interface doing manual film work. The gaps:

Not all Assist subscribers would cancel if the redesign shipped. The cannibalization risk is concentrated in a specific sub-segment — coaches who adopted Assist primarily to solve the two-pass problem and who have no other Assist-specific needs. Based on Step 02 interview data:

A strategic option not previously documented in the project: rather than shipping the redesign as a base-platform improvement (accepting cannibalization) or withholding it (accepting attrition to competitors), Hudl could position the unified tagging interface as a new middle tier — "Assist Lite" or "Assist Self-Service" — at a price point between the base subscription and full Assist service (~$200–$400/year).

An "Assist Lite" positioning would: capture revenue from the Participant D archetype rather than losing it to cancellation; differentiate from full Assist on dimensions the redesign uniquely owns (thematic playlists, opponent film, custom taxonomy); and create an upgrade path from base → Assist Lite → Assist Full that covers coaches across their entire lifecycle of sophistication and budget growth. This framing converts a cannibalization concern into a tiered product strategy conversation.

The Design Rationale Document is the authoritative record of why the design is what it is. It answers the question a product manager, engineering lead, or hiring reviewer might ask after looking at the prototype: "Why did you make this specific choice?" For every significant design decision, this document traces the chain from research evidence to design decision to implementation choice. It is organized by the major design elements of the solution — not by the research steps that informed them — because its primary audience is someone evaluating the design, not the research process.

This document also functions as the project's intellectual backbone for portfolio review. A portfolio reviewer looking at the hi-fi mockups should be able to open this document and find the reasoning behind any specific element — why the overlay is bottom-anchored, why confirmation is a toast rather than a modal, why the note field is hidden by default. That traceability is what distinguishes a design that has been thought through from one that has been styled.

The design's animating principle — "Watch → Notice → Tag → Resume, with no mode switches and no second pass" — was arrived at by identifying the exact moment in the current workflow where value creation stops and structural overhead begins. That moment is the mode switch between the tagging interface and the clip editor. Everything before it has value (the coach is doing meaningful analytical work). Everything after it is duplicated effort (the coach is re-watching film they already watched to generate an output they could have generated during the first pass).

The design principle is not "make tagging faster." It is "eliminate the boundary between tagging and clipping." These produce different designs. A faster tagging interface still requires a clip-cutting pass. An interface that treats tagging and clipping as one operation doesn't. The distinction drove every subsequent design decision: if a proposed feature created any dependency between a tagging action and a separate clip-creation action, it was rejected or restructured until it didn't.

Why an overlay at all, rather than a persistent panel: A persistent panel (Sketch A) keeps the coach's tagging options always visible — but it also means they are always present, even when the coach is not tagging. The Interface Complexity finding from the tech-reluctant veteran persona research was unambiguous: every element visible during film watching that is not directly related to watching film is cognitive overhead. A coach who just wants to watch the team film with their staff does not want a tagging panel on screen. The overlay solves this by being invisible until triggered — the interface is a video player until the coach decides it should be something more.

Why bottom-anchored, rather than centered or side-anchored: The tagged moment must remain visible during entry. If a coach pauses the film at a specific frame — a shot, a tackle, a tactical positioning moment — and then a modal or center overlay covers that frame, the coach must hold the visual memory of the paused frame in their head while entering tag properties. This is an unnecessary cognitive tax. Bottom-anchoring preserves the full video frame above the overlay throughout the entire tag entry. The coach can look up at the paused frame at any point during entry to verify they are tagging the right thing.

Why the overlay collapses after confirmation rather than staying open: A persistent open overlay would interrupt the resume-watching flow by requiring the coach to manually close it before resuming. Every millisecond between confirming a tag and resuming playback is time during which the coach could miss the next significant moment. The collapse-on-confirm behavior keeps the watching state as the dominant state — tagging is an interruption of watching, not the other way around.

The decision to pre-fill the overlay with last-used event type and player attribution is the single highest-impact interaction design choice in the project. In controlled testing (Condition B), participants accepted pre-filled defaults without change for a median of 73% of their tag events. This means that for nearly three-quarters of all tags, the total interaction cost is: trigger (T) → confirm (Enter) → two keypresses. No field selection. No dropdown navigation. No typing.

This maps directly to the most common tagging pattern in soccer coaching: a coach following a player through a match tends to tag sequential events of the same type by the same player — a striker's shots, a defender's clearances, a midfielder's pass completions in a sequence. Pre-filling from last-used aligns with the natural mental rhythm of focused player tracking.

Why not blank: A blank overlay places the decision burden on the coach for every single tag event. At 40–80 tag events per game, that is 40–80 full form completions. The Fatigue-Degradation finding from Step 02 (Finding 04) documents that coaches skip or simplify entries when fatigued. Pre-fill reduces the decision burden to override rather than selection — the coach only has to think when something changes, not when everything stays the same.

Why not AI-predicted pre-fill as the default: AI-predicted pre-fill (the speculative thread) has an accuracy ceiling — when it is wrong, the coach must actively correct it, which may be more disorienting than a blank field. Last-used pre-fill has no accuracy problem: it is always "right" in the sense that it reflects the coach's own most recent decision. It will sometimes be wrong for the next event, but it is never confidently wrong in a way that erodes trust.

Why auto-clip at all: The most direct route to eliminating the second pass is to make clip creation a zero-marginal-effort consequence of tagging. If the coach must set clip bounds for every tag, the savings in the overlay interaction are partially offset by the clip-setting work. Auto-clip with a sensible default turns clip creation into a passive benefit rather than an active cost — the clip exists unless the coach opts out, rather than existing only if the coach opts in.

Why ±8 seconds: ±8 seconds (a 16-second clip) was chosen as the default after reviewing what typical soccer event clips should contain. A shot clip should include the touch or move that created the shooting opportunity (pre-event context, ~4–6s) and the ball trajectory plus initial goalkeeper response (post-event, ~4–6s). ±8 seconds captures this envelope in virtually all cases. In testing, 7 of 8 participants accepted the default for the majority of their clips, and the clips produced were described as "right" or "about right" by participants without prompting.

Why adjustable, and why tiered precision after testing: Not all events have the same contextual requirements. A transition sequence that a coach wants to show as a coaching illustration may require 20–30 seconds of context. A set-piece defensive error may need only 5–6 seconds. The ±8s default handles the median case; the adjustment controls exist for the tails. The testing finding that 2-second nudge increments were too coarse for P6's frame-precision need led to the 1-second default with [Fine] and [Scrub] options — a tiered precision model that keeps the default simple while making precise adjustment possible for coaches who need it.

The decision to automatically assign a clip to the attributed player's playlist when the player is tagged — making the coach uncheck rather than check — was informed by two distinct findings:

Finding 1 (frequency): In interview research, coaches universally said that if a moment is attributed to a player, it belongs in that player's playlist. There were no exceptions in the interview sample to the rule "if I tagged Jordan for a shot, I want Jordan to see it." The rule held across all tagging contexts — positive feedback clips, corrective feedback clips, and neutral analytical tags.

Finding 2 (the ILG-05 exception): P4's discovery that corrective/negative tags defaulted to the Team playlist revealed a genuine edge case — not all clips are appropriate for the full team to see, even if they belong to an individual player's playlist. The revision (configurable per-event-type team default) preserves the opt-out model for player playlists while adding granularity to the team default. The opt-out model was not reverted; it was refined.

Why opt-out rather than opt-in: Opt-in requires a positive action for every tag (check the playlist box), which multiplies friction across a full session. The post-publish correction path (going back to remove a clip from a playlist) is less disruptive than the per-tag assignment path for the majority case. Opt-out means the coach makes an active choice to exclude, not an active choice to include — the burden is placed on the exception, not the rule.

The review state (State 4 of the unified interface) switches the layout from the video-dominant playing state to a timeline-dominant review state. This is a deliberate layout shift that serves the review task specifically:

The review task is fundamentally different from the tagging task. During tagging, the coach is watching new film — the video is the primary information source. During review, the coach is inspecting previously created tags — the event list is the primary information source. The layout should reflect the task, not be static across all tasks. The timeline-first layout makes the event inventory the visual focus, with the video as a secondary resource for verifying specific moments.

Jump-to-tag navigation replaces scrubbing for review purposes. The single most time-consuming element of the current Hudl clip review workflow is locating moments in the film by scrubbing. Jump-to-tag (click a marker → video jumps to that timestamp) eliminates this entirely for reviewing tagged events. In testing, all 6 participants who reached the review state used jump-to-tag navigation rather than scrubbing within 30 seconds of entering the state — without instruction. P3: "I keep forgetting I don't have to scrub anymore. It's a good thing to forget." The behavior was adopted immediately and without friction.

Design rationale is not only about what was chosen — it is also about what was explicitly excluded and why. These exclusions are as important as the inclusions for understanding the design's scope and philosophy.

• Does not auto-tag: The design never tags a moment without an explicit coach trigger. Even the speculative AI suggestion layer requires the coach to confirm each suggestion. This is a trust boundary, not a technical limitation. Coaches who participated in Step 02 research and Step 05 testing consistently expressed that their tagging data is their interpretation of the game — not an algorithm's. Removing that agency would change what the data means to them. The design preserves that meaning while reducing the mechanical cost of expressing it.
• Does not replace the video player: The video player's behavior during playback is unchanged from the current Hudl experience. The redesign layers on top of the player — it does not modify the playing, scrubbing, or fullscreen experiences. This is the protection for the tech-reluctant veteran persona: his experience of Hudl as a video player is identical. The new capabilities are available when triggered but never intrusive when not.
• Does not require Assist to be cancelled: The design explicitly preserves value for Assist subscribers. Opponent film workflow, thematic clip packages, and custom taxonomy are capabilities Assist doesn't provide — coaches on both Assist and the base platform can use the redesign for these workflows while retaining Assist for routine game review. The design is not adversarial toward Assist; it fills the gaps Assist leaves.
• Does not solve the camera/capture workflow: P8's non-adoption (they prefer Veo's camera ecosystem) is a valid signal that the full coaching workflow extends beyond Hudl's interface to the equipment and capture side. This design addresses the post-capture film review and annotation workflow only. The upstream capture problem is a distinct product scope that would require a separate design project — and potentially a hardware or partnership strategy, not just an interface redesign.
• Does not build a social or sharing feed: Several competitor platforms and Hudl itself have invested in social feed features — coach posts, player reactions, team activity timelines. Research found no demand for this among the teacher-coach and club-coach personas. More significantly, a social feed would be orthogonal to the design's core principle of reducing overhead during film work. A coach at 11pm with 90 minutes of film left to review does not want a social feed. They want to finish and go to sleep.

Six design decisions changed as a result of Step 05 usability testing. Each is documented in full in the Iteration Log (Step 05, Deliverable 3) and represented in the Before/After Wireframe Pairs (Step 05, Deliverable 4). The summary below captures only the rationale thread — why each change was the right response to the finding, rather than an alternative response:

The following questions remain unresolved at the close of the lo-fi phase. They are documented here so the hi-fi design work in Step 07 has explicit hypotheses to test rather than making implicit assumptions about their answers:

• Thumbnail toast occlusion: The expanded toast (ILG-06) is larger than the text-only version. In the hi-fi prototype, its relationship to the video frame bottom edge needs to be tested — specifically whether it occludes content that coaches need to see during the 1.5-second display window. If occlusion is a problem, an alternative position (top-right corner toast) or a smaller thumbnail format should be evaluated.
• Auto-resume setting discoverability: The auto-resume setting is in ⚙ Settings → Playback. Will coaches who want it find it? Or will coaches who experienced auto-resume in Condition B (and liked it) not know how to re-enable it after the ILG-01 change? A contextual nudge ("Want video to resume automatically? Turn on Auto-Resume in Settings") at the confirmation toast level may be needed.
• Keyboard shortcut configurability: P2 wanted to remap the T key. The hi-fi design should include a shortcut customization panel in settings. The scope and layout of that panel are unresolved.
• Smart playlist rule persistence: The theme-based playlist builder creates one-off playlists. The "save as smart playlist" option (auto-update as new games are tagged) was prototyped but not tested. Its UX (how are rules displayed? how are they edited? how does the coach know the playlist is auto-updating?) is unresolved.
• First-session onboarding beyond the tooltip: The [Tag ⌨] tooltip handles the immediate trigger discoverability problem. But what about the rest of the new interface — the review timeline, the publish flow, the playlist builder? A progressive onboarding system that reveals capabilities contextually (not in a wizard) needs to be designed for hi-fi. The scope and timing of each contextual hint is unresolved.

All desktop mockups are produced at 1440×900px in Figma — the most common laptop resolution among the teacher-coach and club-coach personas, based on the device context established in Step 02 research. A secondary frame at 1280×800px tests the minimum viable viewport. Hudl's existing dark-UI tokens (background #121212, surface #1E1E1E, primary blue #3B82F6) are used as a baseline and extended where the unified tagging overlay requires new patterns not present in Hudl's public component library. All extensions are documented in the Component Spec Sheet (Deliverable 4 of 5).

The desktop frame set covers eight distinct interface states. States are designed as a connected flow in Figma (not isolated screens) so that a reviewer can follow the complete single-pass tagging journey from pressing play on game film through publishing a clip package to players — without mentally stitching disconnected artboards together. Each frame is numbered, named, and linked with directional arrows indicating which interaction triggers the transition to the next state.

The idle state is the baseline: a coach has opened a game film and pressed play. The interface is a video player. The Unified Tagging UI is completely invisible — no panel, no sidebar, no visible trigger affordance that could add visual noise during uninterrupted watching. A single, low-contrast label in the bottom-right of the playback controls reads [Tag ⌨ T] — discoverable on first hover, invisible at a distance. This design decision was tested in Step 05 and carried forward: the trigger must exist but not dominate.

Hi-fi additions over the lo-fi version: the video frame now renders at full Hudl dark-chrome quality including the timeline scrubber, chapter markers from any previously existing tags, and the playlist indicator in the top-right corner. The playback speed control (0.5×, 0.75×, 1×) and keyboard shortcut legend (accessible via ?) are also present in this frame — both were requested during Step 05 testing and not present in the lo-fi prototype.

The coach presses T (or clicks the [Tag ⌨] label). Film pauses. The bottom-anchored overlay animates up from below the video frame over 180ms using a cubic-bezier ease-out curve — fast enough to feel responsive, slow enough to orient the coach to the new UI layer. The video frame above the overlay remains fully visible. The paused frame is the visual anchor; the coach can verify they have tagged the right moment at a glance.

In the hi-fi version, the trigger animation includes a subtle frame flash (2-frame white outline, 8% opacity on the video border) to confirm the pause has registered — a micro-interaction absent in the lo-fi wireframe. This addresses P8's hesitation during testing: "I wasn't sure if it paused or if I missed it." The animation is intentionally minimal; it confirms state without drawing attention away from the paused video frame.

The overlay at full expansion shows five elements in a single horizontal row: (1) event type selector (dropdown, pre-selected to the coach's last-used type per session), (2) player attribution (type-to-filter from the active roster, auto-populates team playlist assignment), (3) clip boundary controls (−/+ buttons with current in/out timestamps displayed), (4) playlist assignment (checkboxes for auto-assigned playlists based on attribution, plus a manual "Add to playlist" option), (5) confirm and cancel actions. A collapsed note field sits below the row, triggered by a + Note affordance.

Hi-fi visual decisions: the event type selector uses Hudl's existing tag color system (yellow for possession events, red for defensive, blue for set pieces) with a color swatch visible in the dropdown trigger — so the coach receives a visual signal about tag type without reading the label. Player attribution uses a pill component with the player's jersey number and surname, matching Hudl's existing player badge pattern. All pre-filled defaults are shown in a visually distinct state (slightly dimmed, with a small ↩ reset affordance) so the coach can immediately distinguish "I set this" from "the system set this."

When the coach interacts with the clip boundary controls, the overlay enters a secondary state: the main entry row collapses to minimum height and a compact clip timeline expands above it, showing the auto-generated ±8s clip window on the full game timeline. The in and out points are shown as draggable handles. Nudge buttons (◀ 1s / 1s ▶) appear flanking each handle for precision adjustment. A small preview thumbnail updates live as the coach adjusts the in/out — they can see the first and last frame of the clip window without scrubbing the main video.

This state was not in the lo-fi prototype. It was added in response to the ILG-03 iteration (Step 05): P6 overshot twice using 2s nudge increments. The dedicated boundary adjustment state decouples the precision task from the entry task, giving the coach a focused tool for the moments when the auto-clip boundary is wrong — without adding that tool to the main entry flow where it is unnecessary 80% of the time.

On confirm, the overlay collapses and a toast notification appears at top-right. The toast includes: a thumbnail of the first frame of the saved clip (48×27px, matching the clip's in-point), the event type label and player attribution in two short lines, a "View" link that opens the review timeline, and a 4-second auto-dismiss countdown. A quick-undo affordance (Undo · 3s) is present for the first 3 seconds of display. If the coach presses Undo, the tag and clip are removed, the video returns to the paused frame, and the overlay re-opens with all fields populated from the cancelled entry — no re-entry required.

Video auto-resumes 800ms after the overlay collapses (if Auto-Resume is enabled in Settings → Playback). The 800ms gap is intentional: it allows the toast to appear and register visually before motion resumes, so the coach sees the confirmation rather than missing it because playback has already started. This timing was determined by informal testing with 3 of the original Step 05 participants during the hi-fi design phase.

After the coach finishes watching, the Review Timeline provides a chronological list of all tags created in the session. Each row shows: timestamp, event type (colored badge), player attribution, clip duration, playlist assignments, and a note indicator if a note was added. The coach can play any clip inline (expanding the row to show the clip player), edit any tag field, adjust clip boundaries, or delete a tag — all without leaving the timeline view. A "session summary" header shows total tags, total clip duration, and clips-per-player breakdown.

The review timeline is the first moment in the workflow where the coach sees the full output of their film session as a coherent whole. The design treats this as a quality-check surface, not just a list — the player breakdown bar chart in the header makes over-tagging or under-tagging one player immediately visible. A coach who tagged 14 moments for one player and 1 for another will see that imbalance in the header before publishing anything.

The Playlist Builder screen shows all auto-generated playlists from the session — one per player (from attribution-driven auto-assign), plus a Team playlist containing all tagged moments. The coach can rename any playlist, reorder clips within a playlist by drag, remove individual clips, add clips from other playlists, and create a new manual playlist. A "Save as smart playlist" toggle creates a rule-based playlist that will auto-update as future games are tagged with the same criteria (e.g., "All defensive moments, Jordan (#7)"). Smart playlist rules are shown as editable chips below the playlist name.

The Playlist Builder is not a new concept in Hudl — it mirrors the existing playlist management interface. The hi-fi design retains Hudl's interaction patterns for playlist management and adds only the auto-population from attribution-driven tagging and the smart playlist rule builder. This minimizes the learning curve: a coach who already knows how to use Hudl's playlists will recognize this screen immediately and understand the additions without onboarding.

The Publish flow is accessed from the Review Timeline or Playlist Builder via a "Publish" primary action. The coach selects which playlists to share, selects recipients from the team roster (individual players receive only their own playlist by default; the coach can override this), adds an optional message, and confirms. The confirmation screen shows a per-player delivery summary: "Jordan (#7) will receive 3 clips · Sarah (#11) will receive 5 clips · Full team will receive 12 clips." A "Preview as player" link lets the coach see exactly what the player will see before sending.

This flow maps directly onto Hudl's existing sharing infrastructure — no new delivery mechanism is required. The hi-fi design adds only the per-player delivery summary and the "Preview as player" view, both of which were identified as missing from the current workflow during Step 02 research (P3: "I have no idea what my players actually see when I share something").

Three visual language decisions were made in the hi-fi pass that were not present in the lo-fi wireframes and warrant explicit documentation:

• Color use is functional, not decorative. The only colors in the overlay UI are Hudl's existing tag-type colors (yellow, red, blue) and the system confirmation green used for the toast. No new colors were introduced. This is a deliberate constraint: a new color in the tagging overlay would imply a new meaning, and there is no new meaning to convey.
• Typography uses Hudl's existing type scale. The overlay and timeline use the same font stack (Inter), size scale, and weight conventions visible in Hudl's current product screenshots. Introducing a different typeface would signal "different product," which is exactly the wrong signal for a base-platform feature redesign.
• Density is slightly higher than Hudl's current UI. The overlay needs to fit five functional elements in a 72px tall strip at the bottom of a video player. This required tightening Hudl's standard 8px component padding to 6px within the overlay only. The trade-off — slightly denser UI within a bounded component vs. a taller overlay that encroaches more on the video frame — was evaluated against the design principle (preserve the video frame above all other considerations) and resolved in favor of density.

Two breakpoints are designed: tablet landscape (1024×768px, iPad Pro target — the most common sideline device among Step 02 participants) and mobile portrait (390×844px, iPhone 14 target — used for quick post-game sharing and on-the-go clip review, not primary tagging). A tablet portrait frame (768×1024px) is also produced but treated as a secondary variant of the landscape layout rather than a separate design system — the layout reflows rather than redesigns.

The research distinction between use contexts matters here. The teacher-coach doing a full post-game film review session uses a laptop or desktop. The club coach on the sideline uses a tablet or phone to tag a few moments in real time or immediately after a game. Mobile is not a stripped-down version of the desktop workflow — it is a different use case with a different time budget, a different physical environment, and a different tolerance for precision. The mobile design reflects this: it prioritizes speed over completeness, with fewer visible options and larger touch targets throughout.

The tablet landscape layout is the closest to the desktop experience. The overlay appears at the bottom of the video player in the same position as desktop — the additional screen real estate compared to mobile allows for a near-identical UI. The primary adaptation is touch target sizing: all interactive elements in the overlay are increased to a minimum 44×44px (Apple HIG minimum) vs. the 32px desktop minimum. The event type selector becomes a horizontal scrollable chip row rather than a dropdown — faster to tap than opening a dropdown on touch.

The clip boundary adjustment state uses a full-width scrubber with large, easy-to-grab handles rather than the desktop's nudge-button approach. The ±8s auto-clip window is displayed as a highlighted segment on the scrubber, with handles at each end. Dragging a handle with a finger is more natural than tapping a +1s nudge button repeatedly, and the larger touch target area makes precision adjustment feasible without a stylus. The nudge buttons remain present as a secondary option for cases where drag precision is insufficient.

In portrait orientation, the video player occupies the top 56% of the screen (maintaining a 16:9 aspect ratio for the video frame) and the overlay occupies the lower 44% as a persistent panel rather than an animated overlay. This is the one layout exception to the "overlay is invisible until triggered" principle: on portrait tablet, the panel being always-visible costs less screen real estate than an animated overlay that the coach must dismiss and re-trigger repeatedly on a narrower viewport.

The persistent panel in portrait mode shows the same five elements as the desktop overlay — event type, player attribution, clip boundaries, playlist assignment, confirm/cancel — but stacked in two rows rather than one horizontal strip. This reflowed layout is tested against the same task completion criteria as the landscape layout to ensure it does not introduce new points of confusion. The note field remains collapsed by default in portrait mode as in all other layouts.

Mobile tagging is designed for the club coach on the sideline with 15 minutes after a game ends. The full five-element overlay is replaced by a two-step bottom sheet: Step 1 is a single large tap target — "Tag This Moment" — that triggers a pause and auto-generates the clip. Step 2 is a minimal entry sheet (slides up from bottom) with only three fields: event type (large color-coded chips, not a dropdown), player attribution (last-used player shown as default with a Change option), and a confirm button. All other fields (clip boundaries, playlist assignment, notes) are accessible via a "More options" disclosure but are hidden by default.

This is a deliberate information architecture decision: on mobile, the minimum viable tag is event type + player. Everything else can be edited in the Review Timeline later — which is more comfortable at a desk than on a sideline. The "More options" disclosure is not hidden because these features don't exist on mobile; it's hidden because the mobile context does not support precision work, and the design should not encourage trying to do precision work in a suboptimal context. A coach who wants to adjust clip boundaries in detail should wait until they're at a laptop.

The mobile Review Timeline is a card-based list rather than a table. Each card shows the timestamp, event type badge, player name, and a thumbnail of the clip's first frame. Tapping a card expands it inline to show the clip player and edit controls. Swipe-left on a card reveals quick actions: Edit, Move to playlist, Delete. A persistent "Publish" button is fixed at the bottom of the screen, accessible at any point in the review without scrolling to a footer.

The mobile Review Timeline is the primary surface where a coach coming back from a sideline tagging session at home on their phone would clean up their tags before sending them to players. The design of this view assumes that most editing work (clip boundary adjustment, note-writing) will happen here rather than during the original tagging session — which is why those fields are accessible but not foregrounded in the mobile tagging flow.

• Long-press to tag (alternative to tap-the-button): On mobile and tablet, long-pressing anywhere on the video frame (800ms) triggers the tag flow — same as pressing the T key on desktop. This gives coaches who are holding a phone in one hand a thumb-accessible trigger that doesn't require finding a small button.
• Haptic feedback on tag confirmation: A light haptic pulse (UIImpactFeedbackGenerator.medium on iOS) fires when a tag is confirmed. This is specified in the Interaction Specs (Deliverable 3) because it is an engineering implementation detail, but its design rationale is here: in a noisy sideline environment, auditory confirmation is unreliable. Haptic feedback gives the coach a non-visual, non-auditory confirmation that the tag registered.
• No keyboard shortcuts on mobile: The [Tag ⌨ T] label does not appear on mobile or tablet. A Bluetooth keyboard connected to an iPad would theoretically support keyboard shortcuts, but designing for that case would add complexity to the overlay rendering logic without meaningful benefit — the population of coaches using a Bluetooth keyboard during film review is small enough to defer to a future iteration.

Three elements are identical across all breakpoints and are documented once in the Component Spec Sheet rather than per-breakpoint:

• The data model: A tag created on mobile and edited on desktop is the same object with the same properties. The breakpoint differences are entirely presentation-layer — the underlying tag data structure (event type, player IDs, clip in/out timestamps, playlist IDs, note text) is identical regardless of where the tag was created or edited.
• The auto-clip logic: The ±8s default window and the 1s nudge increment are the same on all platforms. The clip boundary adjustment UI differs by breakpoint (scrubber on touch, nudge buttons on desktop), but the underlying clip object has identical properties.
• The confirmation toast: Toast timing (4s auto-dismiss, 3s undo window, 800ms auto-resume delay) is identical across breakpoints. The toast dimensions and thumbnail size adapt to the viewport, but the logic and timing do not change.

Interaction specifications are documented in two places: directly on the Figma frames as annotation layers (using a standardized annotation component that engineering can toggle on/off per frame) and in this document as a narrative reference. The Figma annotations are the engineering-facing source of truth for implementation; this document provides the reasoning behind the specifications for design review and portfolio context.

Annotations follow a consistent format: (1) Element name and location, (2) the specific behavior specified, (3) the trigger that initiates it, (4) any timing or easing values, (5) a back-end/data constraint note where the behavior has implications for the API or data model. Engineering teams in sprint review can filter to annotation layer only and get a complete interaction specification for any frame without reading through narrative documentation.

All animations are suppressed when the user has prefers-reduced-motion enabled (see Accessibility Annotations, section 07 below). In reduced-motion mode, state changes are instantaneous with no transitional animation — the functional state change occurs but without any movement or opacity animation.

Four loading states are specified for the tagging overlay. Each has a distinct trigger, a maximum duration before a failure state appears, and a specific recovery behavior:

• Overlay open — roster loading: The player attribution field shows a shimmer skeleton (matching the pill component width × 3 visible options) while the active roster loads from the API. Maximum 1.5s. If roster does not load in 1.5s, the field shows "Type to search players" with a manual text-entry fallback. Player attribution data is not cached aggressively because roster changes (substitutions, new players) must be current.
• Confirm — tag write pending: The Confirm button enters a loading state (spinner replaces label) for the duration of the API write. The overlay remains open during this window — the coach cannot dismiss it while the write is pending. Maximum 3s. If write fails after 3s, the overlay shows an inline error state: "Tag couldn't be saved. Try again or dismiss to continue watching." The unsaved tag data is preserved in the overlay fields.
• Review timeline — clips loading: Clip thumbnails use a shimmer skeleton until the thumbnail generation API returns. Thumbnails are generated server-side at clip in-point; generation time is typically under 2s post-confirmation. If a thumbnail is not available within 5s, the placeholder shows the event type color badge instead of a thumbnail image.
• Publish — delivery write pending: The Publish button enters a loading state for the duration of the delivery API write. A progress indicator shows "Sending to 4 players…" with a count that updates as each player delivery is queued. If a single player delivery fails, the system reports partial failure: "3 of 4 players notified. Jordan (#7) couldn't be reached — try again."

All interactive elements in the overlay and review timeline have three states beyond their default: hover, focus (keyboard), and active (pressed). These are documented in the Figma frames as variant states within each component. Key decisions that deviate from Hudl's standard interactive state patterns:

• Overlay confirm button: Hover state uses a filled background (Hudl's standard pattern). Focus state adds a 2px offset focus ring in the system focus color (#3B82F6 at 50% opacity) — this deviation from Hudl's standard 1px focus border is intentional and documented in the Accessibility Annotations (section 07) because the dark overlay background makes a 1px ring nearly invisible.
• Event type chips: Selected state uses the tag-type color at full opacity as a filled background with white text. Hover on an unselected chip uses the tag-type color at 15% opacity. This provides visual continuity with Hudl's existing tag color system while adding the selection state necessary for the new chip row interaction pattern.
• [Tag ⌨ T] trigger label: Default state is 20% opacity. Hover state is 70% opacity. The opacity differential is the only visual change — no background, no border, no underline. The label is intentionally subtle at default to not compete visually with the video during idle watching.

All timers reset if the coach interacts with the toast (hover, click, keyboard focus). A focused or hovered toast does not auto-dismiss while focused — this prevents the coach from losing the undo option if they are reading the toast details or moving their cursor toward the undo affordance when the 3s window would otherwise close.

The Settings → Playback panel is annotated in the hi-fi frames because it contains two controls that directly affect tagging behavior: Auto-Resume toggle (default: on) and Keyboard Shortcuts toggle (default: on). The panel is accessed from the ⚙ icon in the playback controls. It slides in as a right-side drawer over the video player (does not navigate away from the film).

Additional settings accessible from this panel: playback speed default (0.75×, 1×, 1.25×), default clip window size (±4s, ±8s, ±12s — replaces the hardcoded ±8s default for coaches who consistently find it too short or too long), and the shortcut configuration panel (see Keyboard Shortcut Map above). These settings persist per-user account, not per-device or per-session.

Accessibility annotations are documented directly on the Figma frames using Figma's built-in accessibility annotation kit. Key annotations that engineering will need for implementation:

• Overlay focus management: When the overlay opens, focus moves to the first interactive element (event type selector). When the overlay closes (confirm or cancel), focus returns to the [Tag ⌨ T] trigger in the playback controls. This is a WCAG 2.4.3 (Focus Order) requirement and is explicitly annotated on the overlay open and close frames.
• Live region for toast: The toast container has role="status" and aria-live="polite" so screen readers announce the confirmation without interrupting ongoing reading. The announcement reads: "[Event type] tagged — [player name] — [clip duration] — Clip saved." A separate visually-hidden element announces the undo countdown: "Undo available for [n] seconds."
• Video pause announcement: When the tag trigger fires and the video pauses, a screen reader announcement reads "Video paused. Tagging overlay open." This is necessary because the visual pause cue (video stops moving) is not available to screen reader users without a text announcement.
• Color not used as the only indicator: Event type chips use color AND label text. The selected state uses color AND a checkmark icon AND a border change. No information in the overlay UI is conveyed by color alone — this satisfies WCAG 1.4.1 (Use of Color) and is annotated on the event type chip component in the Component Spec Sheet.
• Reduced motion: All CSS animations are wrapped in a @media (prefers-reduced-motion: reduce) query that removes transitions. State changes are instantaneous. This is specified in the Component Spec Sheet and annotated on the overlay component.

The Component Spec Sheet documents only the components that are new or modified in this redesign. Components used from Hudl's existing design system without modification are listed in section 07 below with a reference to the Hudl Figma community library source — they are not re-specified here because duplicating existing documentation creates maintenance overhead and risks drift between the spec and the live system.

Each new or modified component is documented with: (1) component name and Figma layer reference, (2) all variants and their trigger conditions, (3) token-level styling (using Hudl's public design token names where they exist, with proposed new token names for extensions), (4) anatomy diagram reference (Figma frame number), (5) accessibility requirements, (6) data props required from the API.

Type: New component (no equivalent in current Hudl system). Figma frame: D-02, D-03 (desktop); T-01, T-02 (tablet); M-02 (mobile bottom sheet variant).

Layout: Fixed position, bottom: 0, left: 0, right: 0 within the video player container (not the full viewport). Height: 72px collapsed / 144px expanded (clip boundary active) / auto for mobile bottom sheet. Z-index: above video player controls, below any system overlays.

Tokens: Background: --color-surface-elevated-2 (#2A2A2A, existing Hudl token); Border-top: 1px solid --color-border-subtle (existing); Backdrop-filter: blur(8px) — new, no existing Hudl token; proposed: --effect-blur-overlay: blur(8px).

API props required: active_session_id (string), roster (array of player objects: id, name, jersey_number), last_used_event_type (string, from user preferences API), user_playlist_defaults (array of playlist objects with auto-assign rules). All must be available in the game film player context — none require a new API endpoint if the roster and session data are already available to the film player view (confirmed against Hudl's public developer documentation).

States: hidden (default, no DOM presence during idle), entering (animation in progress), active-entry (fields populated, awaiting confirm), active-boundary (clip boundary adjustment mode), confirming (write pending), error (write failed).

Type: Modified from Hudl's existing tag-type badge component. The existing badge is display-only; this version adds an interactive selected state and a chip-row layout pattern. Figma frame: D-03 (desktop chip row); T-01 (tablet scrollable chip row).

Variants: unselected (default), hovered (color at 15% opacity fill), selected (color at 100% fill + white label + checkmark icon), focused (selected styles + 2px focus ring offset). Disabled state (gray, non-interactive) is used when event type options have not loaded from the API.

Sizing: Height: 32px (desktop), 44px (tablet/mobile touch targets). Horizontal padding: 12px. Border-radius: 4px (matching Hudl's standard chip radius). Label: 13px, weight 500, --font-mono (Hudl token).

Color system: Chip color is driven by the event_type.color property from the API (existing Hudl tag color system). No new colors are introduced. The component accepts a color prop (hex string) and applies it via CSS custom property — the component does not hardcode any tag-type colors.

API props required: event_types (array: id, label, color, keyboard_shortcut). This is the same data structure used by Hudl's existing tag panel — the chip component consumes the same endpoint, just rendered differently.

Type: New component. Figma frame: D-03 (desktop overlay); T-01 (tablet); M-03 (mobile).

Anatomy: Jersey number badge (circular, 20px diameter, jersey_number as text, background: team primary color from API) + player surname label (13px, --font-sans, truncated at 120px max-width with ellipsis) + × dismiss affordance (16px icon, appears on hover/focus of the pill when a player is selected).

States: empty (shows "Add player" placeholder text, no badge), loading (shimmer skeleton, 3 pill-width skeleton items), populated-default (shows last-used player, dimmed 60% to indicate system-set default), populated-confirmed (full opacity, coach has actively selected or confirmed this player), error (player not found in roster — shows "Player not found" in error color with a manual text fallback).

Typeahead behavior: Clicking or focusing the pill opens an inline typeahead dropdown. Filtering is client-side against the pre-loaded roster array (not a new search API call per keystroke). Dropdown shows jersey number + full name + position. Keyboard: ↑↓ to navigate, Enter to select, Esc to dismiss without selecting. Maximum 6 results visible before scroll.

Attribution → playlist auto-assign logic: When a player is selected, their default playlist ID (from user_playlist_defaults) is automatically checked in the playlist assignment field. This is a client-side operation — no API call at selection time. The playlist write only happens on tag confirm.

Type: New component (desktop nudge variant) + modified scrubber (tablet/touch variant). Figma frames: D-04 (desktop expanded state); T-03 (tablet scrubber state).

Desktop nudge variant anatomy: In-point display (timestamp, editable on click) + ◀ 1s nudge button + [clip duration display] + 1s ▶ nudge button + out-point display (timestamp, editable on click). The clip duration display updates live as nudge buttons are pressed. Maximum clip duration is capped at 120s (2 minutes) — an attempt to create a 2+ minute clip surfaces a warning: "Clips over 2 min may be trimmed in playback. Adjust or continue."

Touch scrubber variant anatomy: A 100% width timeline strip showing the full game scrubber (reduced height: 8px track vs. 16px in the main playback controls). The auto-clip window is highlighted as a colored segment. In and out handles are 32px diameter circular drag targets. A live preview thumbnail (48×27px) appears above the active handle during drag, showing the frame at the handle's current position.

API interaction: The in/out timestamps written to the tag object are absolute timestamps relative to the game film start (in seconds, float precision). The ±8s default is calculated client-side from the current playback position at the moment T is pressed. Nudge increments modify the in/out timestamps directly — no server round-trip during adjustment. The final in/out values are submitted as part of the tag write on confirm.

Type: New component (extension of Hudl's existing notification toast, which is text-only). Figma frame: D-05 (desktop); T-04 (tablet); M-05 (mobile).

Anatomy: Thumbnail (48×27px, rounded 2px, generated from clip in-point frame) + event type color bar (4px left border in tag-type color) + primary line (event type label + player name, 13px weight 500) + secondary line (clip duration + playlist count, 12px muted color) + "View" link (opens Review Timeline inline) + "Undo" link (visible 0–3s only) + × dismiss button.

Thumbnail generation: The toast renders with a shimmer placeholder while the thumbnail generates server-side. Thumbnail generation is triggered immediately on confirm (not on toast display) to minimize the loading window. If the thumbnail has not arrived within 1.5s of the toast displaying, the placeholder is replaced with an event-type color swatch — the thumbnail never blocks toast display.

Undo behavior: Pressing Undo calls the tag delete endpoint (same endpoint used by the Review Timeline delete action). On success: toast dismisses, overlay re-opens with all fields pre-populated from the undone tag, video remains paused. On failure: inline error in toast — "Couldn't undo — check your connection." The tag is considered saved; the coach can delete it from the Review Timeline.

Type: New component. Figma frame: D-06 (desktop timeline); M-04 (mobile card variant).

Desktop row anatomy (collapsed): Timestamp (DM Mono, 12px, min-width 56px) + event type badge (color swatch, 8×8px + label, 12px) + player attribution pill (same component as overlay, display-only mode) + clip duration (12px muted) + playlist chips (up to 3 visible, +N for more) + inline play button (16px icon) + edit button (pencil icon, 16px) + delete button (trash icon, 16px). Row height: 48px collapsed.

Desktop row anatomy (expanded): Row expands to show an inline clip player (16:9, max 320px wide, right-aligned within the row). Edit mode replaces the display-only fields with the same editable components used in the overlay — event type chip row, player attribution pill with typeahead, clip boundary control. Edit save calls the tag update endpoint. Edit cancel restores the previous values without an API call (optimistic UI).

Mobile card variant: All the same data, card layout instead of row. Thumbnail (80×45px) in top-left. Event type badge + player name + timestamp stacked to the right of thumbnail. Clip duration below. Swipe-left reveals action buttons (Edit, Move, Delete). Tap to expand → inline clip player fills card width.

The following components from Hudl's Figma Community library are used in the hi-fi mockups without modification. They are listed here for engineering reference — implementation should use the live Hudl component library, not the mockup assets:

• Video playback controls bar — used in idle state and clip boundary adjustment state. Scrubber track, chapter markers, volume control, fullscreen toggle.
• Dropdown / select — used for playback speed and default clip window size in Settings → Playback.
• Toggle switch — used for Auto-Resume and Keyboard Shortcuts toggles in Settings → Playback.
• Primary and secondary button — used for Confirm (primary) and Cancel (secondary) in overlay; Publish (primary) in Review Timeline / Playlist Builder.
• Text input — used for note field (collapsed by default in overlay) and for rename fields in Playlist Builder.
• Right-side drawer — used for Settings → Playback panel. Slides in over the video player; standard Hudl drawer component behavior.
• Playlist card — used in Playlist Builder. Standard Hudl playlist representation; no modifications.

Edge case screens are not the same as error states. Error states (write failure, roster loading failure) are documented in the Interaction Specs and Component Spec Sheet because they are part of a primary component's specification. Edge cases are situations that fall outside the primary use flow but that a coach will encounter in real use — and that a developer will have to make a decision about if the design doesn't address them first. An unspecified edge case is a decision deferred to engineering, and engineering decisions about user-facing edge case behavior are usually the wrong defaults.

Each edge case below documents: the situation, the coach context in which it arises, the designed behavior, and the rationale for choosing that behavior over alternatives. Where the edge case screen is in the Figma file, the frame number is noted. All edge case frames are in a dedicated "Edge Cases" page in the Figma file, separate from the primary flow frames.

Situation: A coach presses T, confirms a tag, and immediately presses T again within 400ms — before the toast has finished animating in. This happens in high-density stretches of film (a corner kick sequence with 4–5 events in 30 seconds).

Designed behavior: The second T press fires immediately after the overlay exit animation begins — it does not wait for the first toast to fully render. The new overlay opens, the previous toast renders simultaneously in the top-right corner (briefly overlapping with the new overlay open state). Multiple toasts stack vertically, oldest at top, newest below.

Rationale: Blocking the second T press until the first toast completes would interrupt a coach mid-sequence. The coach's primary task is watching film and tagging; the toast is feedback, not a gate. Stacking toasts is visually busy but time-limited (each auto-dismisses after 4s) and does not interrupt the flow. Figma frame: EC-01.

Situation: A coach presses T within the first 8 seconds of a film (before enough footage exists for the standard ±8s clip window) or within 8 seconds of the end of the film.

Designed behavior: The auto-clip window clips to the available footage. If T is pressed at 5s, the clip window is 0s–13s (0s in-point, not −8s which would be before the film starts). The clip boundary control reflects this: the in-point nudge button is disabled (grayed, with tooltip "Already at video start") when the in-point is at 0s. The out-point works normally.

Rationale: Surfacing an error ("can't tag here") would be confusing and incorrect — the coach can absolutely tag this moment, they just get a shorter clip. The asymmetric clip window is the correct behavior and should be presented without special treatment. The disabled nudge button is sufficient feedback that the boundary cannot extend further in that direction. Figma frame: EC-02a (start), EC-02b (end).

Situation: The roster API call fails or returns an empty array. The player attribution pill cannot populate its typeahead.

Designed behavior: The player attribution field shows "Type player name or number" as a free-text input. Tags created with a free-text player attribution are saved with a raw_player_name string property rather than a player_id reference. On the Review Timeline, these tags show with a "Manual — not linked to player profile" indicator and a "Link to player" action that allows the coach to retrospectively assign the tag to a roster player. The attribution-driven playlist auto-assign does not fire for unlinked tags.

Rationale: Blocking tag creation because the roster didn't load is unacceptable in a time-sensitive film review context. The coach can still create meaningful tags without roster data; the linking step can happen later. The "not linked" indicator is necessary so the coach knows which tags need attention before publishing player playlists. Figma frame: EC-03.

Situation: The coach confirms a tag, but the write API call fails (timeout, 500 error, or lost connection).

Designed behavior: The overlay remains open. The Confirm button returns from its loading state to its default state. An inline error banner appears above the overlay row: "Tag couldn't be saved — check your connection. [Retry] [Save for later]". "Retry" re-fires the write call. "Save for later" saves the unsaved tag data to local storage and adds a "Pending — not yet saved" item to the Review Timeline. Pending items show a sync icon (⟳) and are auto-retried in the background. When a pending item successfully saves, its ⟳ icon is replaced by the standard tag row and a brief success toast appears.

Rationale: A coach who loses connectivity at a key moment in film review should not lose the tag they just created. Local storage fallback is a standard offline-first pattern and is explicitly noted in the spec as a back-end coordination requirement — the pending tag format must match the confirmed tag format so the same write endpoint can be used for both. Figma frames: EC-04a (write failure state), EC-04b (pending item in Review Timeline), EC-04c (auto-save success).

Situation: The coach manually adjusts the out-point beyond the end of the film, or adjusts the in-point before 0s.

Designed behavior: The nudge button stops at the film boundary and becomes disabled. If the coach types a timestamp directly into the in/out point field that exceeds the boundary, the field turns red inline and the Confirm button becomes disabled until a valid value is entered. The invalid value is not submitted to the API.

Rationale: Client-side validation before the API call prevents a class of errors that would result in confusing API failure responses. The inline red state on the timestamp field is the standard Hudl error state for form inputs and requires no new component work. Figma frame: EC-05.

Situation: The coach presses T at a timestamp within 2 seconds of an existing tag's timestamp, with the same event type and the same player attribution.

Designed behavior: A non-blocking inline warning appears below the Confirm button: "Similar tag exists at [timestamp] — same event and player. Create anyway?" with "Yes, create" and "View existing" links. "View existing" opens the matching tag in the Review Timeline (in a side panel, not navigating away from the overlay). The coach can create the duplicate or dismiss the warning — no tag is blocked outright.

Rationale: Duplicate tags can be intentional (two separate moments that happen to share the same event type and player) or accidental (the coach double-pressed T). A blocking error would prevent legitimate duplicate creation. A warning with a view-existing option gives the coach the information to make the right choice without coercing one answer. The 2-second window and same-event-same-player matching criteria are conservative enough to avoid false positives in normal use. Figma frame: EC-06.

Situation: The coach has configured a keyboard shortcut (Settings → Shortcuts) that conflicts with a Hudl native shortcut or a browser default.

Designed behavior: The Shortcut Configuration panel validates against a conflict list in real time as the coach types a new shortcut. If a conflict is detected, the input field shows an inline warning: "This key is used by [Hudl: Scrub forward]. Using it here will override that behavior in film review." The coach can proceed (explicitly accepting the override) or choose a different key. Browser defaults (e.g., ⌘W, ⌘R) are on a hard block list — the panel will not allow them to be mapped regardless of coach choice, with the message: "This key is reserved by your browser and can't be remapped." Figma frame: EC-07.

Situation: The coach opens Settings → Shortcuts to customize their keyboard shortcuts — the panel that was left unspecified at the end of the lo-fi phase (Design Rationale, section 09: "Keyboard shortcut configurability — P2 wanted to remap the T key. The scope and layout of that panel are unresolved").

Designed behavior: The Shortcuts panel shows a table of all configurable shortcuts: Action (label) + Current Key + a "Change" button per row. Pressing "Change" puts that row's key field into capture mode — the next keypress (excluding the hard block list) sets the new shortcut. The panel shows a reset-to-defaults button at the bottom. All shortcut changes take effect immediately and persist to the user's account preferences. Figma frames: EC-08a (panel default), EC-08b (capture mode), EC-08c (conflict warning state).

Situation: A coach opens a game film for the first time after the unified tagging feature is enabled on their account. They have never seen the overlay and do not know the T trigger exists.

Designed behavior: On first film open, a single contextual tooltip appears anchored to the [Tag ⌨ T] trigger label: "New: tag clips without leaving the film. Press T to try it." The tooltip auto-dismisses after 6 seconds or on any coach interaction. It does not reappear. No further onboarding is shown until the coach has used the overlay at least once — the second onboarding touchpoint appears in the Review Timeline on first visit, anchored to the session summary header: "All your tags are here. Edit, adjust clips, or publish to players." This is not a wizard; each contextual hint is specific to the element it is anchored to and appears exactly once. The onboarding state is tracked server-side per user account (two boolean flags: has_seen_overlay_tooltip, has_seen_timeline_tooltip).

Rationale: A full onboarding wizard for a film review tool at 11pm is the wrong solution — this persona does not have time or patience for a multi-step tour. Contextual single-appearance tooltips deliver the minimum information needed to discover each capability without coercing the coach to engage with onboarding before doing their actual work. Figma frames: EC-09a (film open tooltip), EC-09b (review timeline tooltip).

Situation: Auto-Resume is enabled. The coach confirms a tag, video resumes at 800ms, and then — while the film is playing — the coach decides to undo the tag (presses ⌘Z or clicks Undo in the still-visible toast). They are now watching live film with the undo action fired.

Designed behavior: Undo pauses the video. The tag is deleted. The overlay re-opens with all fields pre-populated from the undone tag. The playback position is scrubbed back to the moment the tag was created (±0s, not ±8s — the exact timestamp of the T press). The coach is returned to the paused state at the tagged moment with the overlay open, as if the original T press had just fired. They can re-confirm with different values, or cancel and resume from the original position.

Rationale: An undo that fires while the film is playing but doesn't return the coach to the original context is not a complete undo — the film has advanced. Scrubbing back to the tagged moment and re-opening the overlay is the only behavior that gives the coach the full ability to correct their action. The playback scrub is a programmatic action (not a user-initiated scrub) and is the one case where the design overrides the coach's current playback position on their behalf. This is documented explicitly in the annotation for this edge case so engineering understands the intentionality. Figma frame: EC-10.

The Figma prototype covers three flows across one shared file with three top-level sections. Each section is a self-contained flow — a reviewer can start at the beginning of any flow without having completed the others. Navigation between flows is handled by a persistent "Switch Flow" strip at the top of each frame (A · B · C, with the active flow highlighted), so a reviewer can jump between the current Hudl workflow and the redesign at any point during their evaluation.

The prototype is built on the hi-fi mockup frames from Step 07, with Figma prototype connections added. It is not a separate file — it is the Step 07 Figma file with prototype mode enabled. This means any change to the hi-fi frames is immediately reflected in the prototype, eliminating the drift that occurs when a prototype and its source mockups are maintained separately. All frames used in the prototype are tagged with a "PROTO" prefix in the Figma layer panel to distinguish them from edge case and documentation frames in the same file.

Flow A reproduces the current Hudl two-pass workflow as faithfully as a static prototype can represent a live video platform. The goal is not to mock Hudl's existing UI — it is to give a reviewer the visceral experience of the problem. A reviewer who has not personally sat through a two-pass film session needs to feel the redundancy before they can evaluate whether the redesign genuinely solves it.

Frame sequence: (A-01) Film player — playback in progress. (A-02) Pause and open Tagging panel — stat selection. (A-03) Add stat, resume playback. (A-04) [Time jump indicator: "40 minutes of game film later…"] (A-05) Return to film — clip-cutting pass begins. (A-06) Locate the tagged moment on the timeline — scrub to find it. (A-07) Set clip boundaries — in and out points, separately from the tag. (A-08) Assign clip to playlist — separate action from the tag and the clip. (A-09) Session complete — total time counter shown vs. redesign estimate.

The time jump indicator at A-04 is a deliberate narrative device. A static prototype cannot reproduce 40 minutes of film review, but a clearly labeled frame that acknowledges the time gap keeps the reviewer oriented without requiring them to sit through a simulation. The time counter at A-09 provides the quantitative anchor: "This workflow took 3h 10m in participant testing. Flow B covers the same game in 58 minutes."

Interaction fidelity: Flow A prototype interactions are minimal — the goal is to communicate the sequence of mode switches, not to recreate Hudl's platform. Tappable hotspots advance through frames; the scrubber and playlist panel in Hudl's actual UI are represented as static high-fidelity screenshots rather than interactive components. Flow A is the evidence, not the design.

Flow B is the full interactive prototype of the redesign. Every primary interaction in the tagging workflow is implemented as a live Figma connection — not a hotspot that advances a frame, but an interactive component that changes state within the frame. This distinction matters: a hotspot prototype proves that a sequence of screens exists; an interactive component prototype proves that the interaction model is coherent enough to implement in Figma, which is a reasonable proxy for its implementability in a real product.

Frame sequence: (B-01) Film player — idle state, [Tag ⌨ T] label visible at low opacity. (B-02) T pressed — overlay entrance animation plays (Figma smart animate), video pauses, overlay fully visible. (B-03) Event type chip row — tapping a chip updates the selected state in place. (B-04) Player attribution — typing "7" filters the roster to Jersey #7; tapping selects and populates the pill. (B-05) Playlist assignment auto-populates based on player selection. (B-06) Confirm — overlay exit animation plays, toast entrance animation plays, video frame shows paused state with thumbnail in toast. (B-07) Auto-resume — film plays again (represented by a looping video still). (B-08) [Repeat loop] T pressed at a second moment — demonstrates back-to-back tagging without mode switch. (B-09) Review Timeline — session summary, three tagged clips listed. (B-10) Expand a row — inline clip player, edit controls. (B-11) Playlist Builder — auto-populated playlists shown. (B-12) Publish — per-player delivery summary, confirm.

Interactive components used in Flow B: Event type chip row (component set with selected/unselected variants, Figma interactive component); Player attribution typeahead (simulated with two frames: pre-filter and post-filter, connected by a hotspot on the "7" keystroke representation); Clip boundary nudge buttons (each press increments the timestamp display — implemented as a variable); Confirmation toast (Smart Animate from overlay-open to toast-visible state). All other transitions use Smart Animate with the easing curves specified in the Interaction Specs (Deliverable 3 of 5, Step 07).

Flow C documents what a coach receives when they use Hudl Assist — not an interface the coach uses, but a service that delivers outputs to them. This flow was included as Condition C in Step 05 usability testing and resurfaces here because it is the most important comparison for a product team evaluating whether the redesign is worth building. Assist is Hudl's own answer to the two-pass problem; Flow C makes that explicit so a reviewer understands exactly what the redesign is positioned against.

Frame sequence: (C-01) Coach uploads game film to Hudl — standard upload interface. (C-02) Submit to Assist queue — coach selects Assist service, confirms sport and event type, submits. (C-03) [Wait state — analyst queue indicator: "Your game is being reviewed. Typical turnaround: 4–6 hours."] (C-04) Coach receives notification — "Your Assist breakdown is ready." (C-05) Assist output — pre-tagged timeline with all moments tagged, player clips auto-generated, playlists pre-built. (C-06) Coach reviews output — can view clips, share playlists, but cannot edit tag timestamps or clip boundaries without re-entering the base workflow. (C-07) Share playlists — identical to Flow B publish step; same delivery mechanism. (C-08) Comparison summary card — Assist vs. Redesign side-by-side on key dimensions.

Frame C-06 is the one frame in the entire prototype that is not a neutral presentation — it surfaces the capability gap that all 6 Assist walkthrough participants raised independently in Step 05 testing: the output is correct but the coach has lost authorship. The frame shows the pre-built playlists with a subtle annotation: "Tags are the analyst's, not yours. Editing requires returning to base workflow." This is not a critique of Assist — it is an honest representation of the trade-off, documented in the Step 06 Trade-off Analysis. A reviewer evaluating the redesign should understand this gap before they assess whether the redesign offers something Assist does not.

Three fidelity decisions were made deliberately and warrant explanation for any reviewer who has opinions about prototype craft:

• Video in the prototype is a still frame, not playback. Figma does not support video playback natively (as of early 2026). The film player frames use a high-fidelity screenshot of actual football game film (with coach's permission, from a public YouTube livestream) as the video area. A subtle motion blur overlay and a "● LIVE" indicator in the playback bar sell the illusion that the film is playing. The still frame is sufficient for communicating the interaction model — the design is about what happens when the coach presses T, not about the video content itself.
• The roster typeahead is simulated with two frames, not a live filter. A live text filter in Figma requires either a plugin or complex variable logic that adds prototype maintenance overhead without meaningfully improving reviewer comprehension. The two-frame simulation (empty field → "7" typed → #7 Jordan appears) is transparent about being a simulation and communicates the interaction model without confusion.
• Toast thumbnail is a static image, not a generated frame capture. The thumbnail in the confirmation toast is a cropped still from the video used in the prototype, representing the clip in-point frame. In production, this would be generated server-side. The static image in the prototype communicates the design intent — that a visual clip preview appears in the toast — without requiring a back-end implementation.

The Figma prototype is published with "Anyone with the link can view" access — no Figma account is required to interact with it in presentation mode. The share link opens directly in prototype presentation mode, bypassing the Figma editor. Mobile viewers can interact with the prototype on iOS/Android via the Figma mobile app or in a mobile browser (prototype interactions are touch-compatible).

A QR code linking to the prototype is included in the Three-Way Workflow Comparison Frame (Deliverable 4 of 4) for print or slide contexts. The prototype link is also embedded in this portfolio page via an iframe (Deliverable 2 of 4, Embedded Interactive Preview) so that a reviewer reading this case study can transition directly from reading about the design to interacting with it, in the same browser window.

These are documented here rather than discovered by a reviewer mid-interaction:

• No real video playback. As noted above. The film player is a high-fidelity still. A reviewer testing the prototype on a device that loads Figma slowly may notice a brief white flash before the video still renders — this is a Figma loading artifact, not a designed state.
• Keyboard shortcuts are not functional in Figma presentation mode. The T key shortcut that triggers the overlay in the designed system is not implementable in Figma's prototype engine. The [Tag ⌨ T] label in the prototype is a hotspot — clicking it triggers the same overlay as pressing T would in the live product. The walkthrough video (Deliverable 3 of 4) narrates this explicitly.
• Back-button behavior varies by browser. In some browsers, the browser back button exits Figma presentation mode rather than returning to the previous prototype frame. Reviewers are advised to use the prototype's in-frame back arrow rather than the browser back button. This is noted in the prototype's first frame in a small dismissible tip.
• Mobile touch targets in Flow B are desktop-sized. The primary prototype is built at 1440×900px (desktop). A mobile variant of Flow B exists in the Figma file but is not connected into the same prototype flow — it is accessible as a separate starting frame. The embedded preview (Deliverable 2) defaults to the desktop flow; a "Switch to mobile prototype" link is provided below the iframe.

A link to a Figma prototype requires the reviewer to open a new tab, wait for Figma to load (8–15 seconds on a cold start), orient themselves to the Figma interface, and then find the start of the prototype. Each of those steps is friction between the reviewer's decision to engage with the prototype and the moment they are actually interacting with it. A portfolio reviewer evaluating ten candidates in an afternoon loses that decision-to-interaction gap for each step they have to complete before seeing the work.

The embedded preview removes all of that friction: the prototype loads inside the page the reviewer is already on. The reviewer can read about the design rationale and immediately test the interaction — in the same browser window, without losing their reading position. The embed also solves a specific problem for async portfolio review: a reviewer watching this page with a hiring team over a screen share can demo the prototype without leaving the portfolio, which keeps the conversation anchored to the context around the embed rather than cutting to a raw Figma file.

The Figma prototype is embedded using Figma's standard embed URL format (https://www.figma.com/embed?embed_host=share&url=[prototype_url]) inside an <iframe> with allowfullscreen and allow="clipboard-write" attributes. The iframe is wrapped in a 16:9 aspect-ratio container using the padding-top: 56.25% technique, so the embed scales correctly to any viewport width without a fixed pixel height.

The embed renders Figma's presentation mode directly — the reviewer sees the prototype starting frame with the flow switcher strip (A · B · C) at the top, not the Figma editor or file browser. The Figma toolbar at the bottom of the embed (zoom, fullscreen, comments) is visible but does not interfere with prototype interactions. A "Fullscreen" button below the iframe wrapper allows the reviewer to expand the prototype to fill their viewport for a higher-fidelity interaction session.

The embed wrapper is responsive to viewport width. At viewport widths above 900px, the iframe fills the full content column width (matching the width of the cs-process-step-body container). At viewports below 900px, the iframe is replaced by a "Open prototype in new tab" button — the Figma embed at small viewport sizes does not provide a usable interaction surface for a desktop prototype, and a link is more useful than a cramped iframe.

The breakpoint at which the fallback triggers is 900px, not 768px (the standard tablet breakpoint), because the prototype flow B requires horizontal overlay interaction that becomes unusable below 900px viewport width. The mobile prototype variant (a separate Figma flow built at 390×844px) is linked separately below the iframe with a "View mobile prototype" button for reviewers on small screens.

Some corporate network environments block figma.com iframe embeds (content security policies at companies like financial services firms or healthcare organizations often restrict third-party iframes). The embed wrapper includes a JavaScript onerror handler that detects iframe load failure and replaces the embed container with a graceful fallback: a static thumbnail of the prototype starting frame (the film player with the overlay visible) and a "This embed was blocked by your network — view prototype directly in Figma" link.

The fallback thumbnail is a 1440×900px screenshot of the prototype's primary state (overlay open, event type chips visible, player attribution populated, clip boundary controls showing). It is not a random frame — it is the most information-dense single frame in the prototype, selected to give the reviewer maximum visual context even if they cannot interact with the prototype at all.

The Figma iframe is lazy-loaded — it does not begin loading until the reviewer scrolls the embed into the visible viewport. This prevents the Figma embed (which initiates multiple network requests on load) from degrading the page's initial load performance for reviewers who may not reach the prototype section. The lazy-load is implemented via the loading="lazy" attribute on the iframe element, supported natively in all modern browsers.

While the iframe is loading, a skeleton placeholder with the Figma logo and "Loading prototype…" text fills the 16:9 container. The skeleton uses the same shimmer animation pattern used throughout the rest of the portfolio page for loading states — visual consistency rather than a jarring spinner in an otherwise static context. The skeleton automatically hides when the iframe reports a successful load via the onload event.

Below the iframe wrapper, two secondary links are provided: (1) "Open in new tab" — opens the Figma presentation mode URL directly, for reviewers who prefer a full-browser prototype experience. (2) "View mobile prototype" — opens the mobile-viewport variant of Flow B, built at 390×844px, which demonstrates the simplified two-step tagging flow designed for the club coach on a sideline (documented in Hi-Fi Mockups — Mobile/Tablet, Step 07 Deliverable 2).

A third link — "Download walkthrough PDF" — provides a non-interactive but printable version of the three flows as annotated screen sequences. This is produced for contexts where an interactive prototype cannot be used: printed portfolio reviews, emailed attachments, or conferences. The PDF is generated from the Figma file using Figma's built-in PDF export, with annotation overlays enabled.

The walkthrough video serves two audiences with different needs. The first is the async portfolio reviewer — a hiring manager or design lead who has 8 minutes for a video but 45 minutes of interactive prototype in front of them and no time to explore it unprompted. The video gives them the curated version: what to look at, why it was designed this way, and what the key decisions were. The second is the reviewer who cannot interact with the prototype at all — mobile viewer, embedded link blocked, or screen recording context. The video is the complete fallback.

The video is intentionally not a screen recording of someone clicking through the prototype passively. Every second of screen time has narration that adds information not visible in the UI — the research finding that motivated a decision, the alternative that was rejected, the constraint that shaped a choice. A reviewer who watches the video should come away knowing more about the design's reasoning than one who only interacted with the prototype.

Total runtime: 8 minutes. A short-form cut (3 minutes, sections 1 and 2 only) is produced separately for contexts with a strict time limit — job application video submissions, conference lightning talks, LinkedIn native video. Both versions link to the full case study and prototype.

The opening section does not begin with a product overview. It begins with the experience of the problem. The screen shows Hudl's current tagging interface — the stat panel open, a game on screen — and the narration is: "This is what a post-game film session looks like for a high school football coach at 11pm on a Friday. First, you watch the whole game and tag every stat. Then you watch it again and cut every clip. Then you assign the clips to playlists. Then you publish them. That's three and a half hours for a 90-minute game. We tested this with eight coaches. The average time was three hours and ten minutes."

The narration continues over a screen recording of the Flow A prototype, with a red annotation tracking the "current task" at each step. At the mode-switch moment between the tagging pass and the clip-cutting pass, the video pauses on a white frame with text: "This is the second pass. Same film. Different mode. 1h 20m of work the coach already did." The visual pause is 3 seconds — long enough to let the point land, short enough not to feel like a lecture.

The walkthrough section follows the complete Flow B sequence. Narration is interaction-specific — it explains what the reviewer is seeing and why each interaction is the way it is, rather than describing the visual state (which is visible without narration). Key narration beats:

• On the idle state [Tag ⌨ T] label: "The trigger is almost invisible at rest. Coaches watching film with their staff don't want a tagging panel on screen. It's there when they need it and invisible when they don't."
• On the overlay entrance: "Press T. Film pauses. The overlay slides up from the bottom — the video frame stays fully visible above it. The coach can see the paused moment while they're entering the tag."
• On the event type chip row: "One tap selects the event type. Color plus label — no color-only coding. The selection state is immediate, no dropdown to open."
• On player attribution auto-populating the playlist: "When the coach selects a player, their personal playlist is auto-checked. They don't assign the clip to the playlist — the clip assigns itself based on who they tagged. They can override this. Most of the time they won't need to."
• On the toast thumbnail: "Confirmation toast. Thumbnail of the clip's first frame so the coach knows it captured the right moment. Auto-dismisses in four seconds. Video resumes in 0.8 seconds — fast enough to catch the next play."

This section steps out of the prototype flow and addresses three design decisions directly — the ones a senior design reviewer is most likely to question:

Decision 1: Why is the overlay bottom-anchored? Screen shows the overlay in place, then an animated alternative showing a center modal over the video. "A center modal covers the paused frame. The coach tagged this moment because something happened in that frame — a player position, a ball contact. If the modal covers it, the coach has to hold that image in their head while they enter the tag. The bottom anchor preserves the frame above the overlay throughout the entire entry. The coach can look up at any time."

Decision 2: Why does auto-resume fire at 800ms, not immediately? Screen shows the toast entrance timing against a timeline. "If auto-resume fired immediately on confirm, the video would start moving before the toast fully renders. The coach wouldn't see the confirmation. 800ms is enough time for the toast to appear and register visually before the film starts moving again. We tested this informally with three of the original participants. Under 600ms, two of three missed the toast. At 800ms, all three saw it."

Decision 3: Why is the mobile flow two steps, not five? Screen shows the desktop overlay and the mobile bottom sheet side by side. "The teacher-coach at a desk has time for precision. The club coach on a sideline with 15 minutes after a game does not. Two fields — event type and player — are the minimum viable tag. Everything else can be fixed in the Review Timeline later, at a desk, where precision work is actually comfortable. The mobile interface is not a stripped-down desktop. It's a different tool for a different context."

The final substantive section uses the Three-Way Workflow Comparison Frame (Deliverable 4 of 4) as its visual. The frame appears on screen and the narration walks through the four comparison rows:

• Time to complete post-game film session: Hudl Base — 3h 10m average. Assist — 30–45m coach time (4–6h analyst time). Redesign — 58m average (Step 05 testing). "The redesign does not beat Assist on coach time. Assist is faster for the coach because an analyst does the work. The redesign beats Assist on something else."
• Coach authorship of the output: Hudl Base — full authorship. Assist — none (analyst tags). Redesign — full authorship. "Every tag in the redesign was created by the coach who knows the game. The Assist output is correct, but the tags aren't mine — that's a direct quote from six of the eight Assist walkthrough participants."
• Cost above base Hudl subscription: Hudl Base — $0. Assist — $900–$3,300/year. Redesign — $0. "The redesign is a base-platform improvement. No upsell, no tier, no service fee."
• Ability to create thematic clip packages: Hudl Base — possible but time-intensive. Assist — limited (tags are by play type, not by coach intent). Redesign — built in (note field, smart playlists, playlist builder). "This is the capability gap that surprised us in research. Assist coaches can distribute clips, but they can't build the thematic packages — 'every moment Jordan was in the wrong gap this game' — that are the most valuable coaching tool. The redesign makes that possible in the same session as the first film pass."

The video is recorded using Loom for screen capture and narration, exported at 1080p. Screen resolution is set to 1440×900px (matching the prototype frame size) before recording. The Figma prototype is displayed in full-screen presentation mode during the walkthrough sections. Annotations are added in post-production using ScreenFlow or DaVinci Resolve — red circles for interaction callouts, white text cards for section headers and key data points.

Captions are generated using Loom's auto-caption feature and manually reviewed for accuracy — specifically for the Hudl-specific terms (Assist, clip-tagging, two-pass) and the participant quotes that appear in Section 4. The video is published to Vimeo (unlisted, no ads) and embedded in this portfolio via Vimeo's standard iframe embed. A direct download link (MP4, 1080p) is provided below the embed for reviewers who prefer a local file.

The short-form 3-minute cut is identical in production quality but uses jump cuts rather than the longer pause-and-land technique used in the full version. It is produced after the full version is locked — not as a separate recording, but as an edit of the same raw footage.

The Three-Way Workflow Comparison Frame is a single Figma artboard (1920×1080px, 16:9) that presents the full comparison of the three workflows — Hudl Base, Hudl Assist, and the Redesign — in a format designed for a product team presentation. It is the one frame in the entire project that is optimized for a display context (a projector or large monitor in a meeting room) rather than a portfolio reading context.

Three design decisions shaped this frame specifically: (1) The redesign column is not highlighted or visually privileged over the other two. The comparison frame is evidence, not advocacy — it presents the data and lets the viewer draw conclusions. A comparison frame that visually champions one option is not a comparison; it's a pitch. (2) Every data point on the frame has a source footnote — either a Step 05 testing result, a Step 02 research finding, or a Step 03 competitive analysis figure. Nothing on the frame is asserted without evidence. (3) The frame is readable at 1920×1080px from a distance of 4–6 meters, which is the typical projector viewing distance in a conference room. The minimum font size on the frame is 16pt at 1920px, which renders to approximately 11pt at a 1080p projection — legible from the back of most conference rooms.

The frame is a three-column grid (Hudl Base · Hudl Assist · Redesign) with four primary row groups and a header row. Each column header includes: the workflow name, a one-sentence description, and a cost indicator (Free / +$900–3,300/yr / Free). The column widths are equal — the redesign does not get more space than the alternatives. Row groups are separated by a 1px horizontal rule and a row group label in the left margin.

The frame is designed to be navigated row by row in a presentation — a facilitator can step through each row group as a talking point, spending more time on the rows where the audience has questions. The four row groups are not ordered from "most important" to "least important" — they are ordered from "most intuitive to understand" (step breakdown) to "most nuanced to discuss" (capability summary). A presenter can stop at any row and field questions without the remaining rows being out of context.

Row 1 shows each workflow as a horizontal step sequence using numbered circles connected by arrows — the same visual language used in the Step 03 journey map. Each step is labeled with a 3–5 word description and a time estimate from Step 05 testing (for Hudl Base and the Redesign) or Step 02 research notes (for Assist, which was not directly timed in testing).

The mode switch count is the single most clarifying number on the frame for an engineering audience. Three mode switches in the base workflow means three distinct UI contexts that the coach must navigate between — and three separate product surfaces that must be maintained. The redesign reduces this to zero, which is also a maintenance and product complexity reduction, not just a UX improvement.

Row 2 presents the time data from Step 05 usability testing (Hudl Base and Redesign) and Step 02 research (Assist). The data is presented as a bar chart within each column cell — identical scale across all three columns so the bars are directly visually comparable. A data table below the bars provides the exact figures and their sources.

The confidence rating row is the most important finding on this frame and is the one most likely to prompt discussion. The Assist output scores 3.6/5 on coach confidence — higher than the base workflow (3.1) but lower than the redesign (4.3). The Assist walkthrough notes from Step 05 explain why: coaches who received the Assist output felt they couldn't vouch for the accuracy of the tags because they hadn't made them. Four participants used the word "trust" unprompted — specifically, that they trusted their own tags more than an analyst's.

Row 3 is a qualitative row, presented as a 5-cell icon matrix per column (five capability dimensions, each rated as Full / Partial / None with an icon and a one-line description). This row is the most nuanced on the frame because authorship and control are not binary — Assist provides some control (coaches can delete tags, share playlists) but not others (coaches cannot edit tag timestamps or create thematic packages from Assist output without returning to the base workflow).

Row 4 is the bottom row of the frame and the most product-strategy-facing. It presents three data points per column: annual cost above base Hudl subscription, the primary persona served (from the Step 02 persona framework), and a one-sentence strategic positioning statement.

The strategic positioning row is the one that a revenue stakeholder will focus on. The redesign's positioning — "Speed of Assist, authorship of base — no extra cost" — is a direct challenge to the Assist value proposition for the segment of coaches who adopted Assist specifically because the base workflow was too slow (not because they preferred delegation). The Step 06 Trade-off Analysis documents this in detail; Row 4 of the comparison frame surfaces the tension without resolving it, because resolution is a product strategy decision, not a UX one.

The comparison frame uses a restrained visual vocabulary by design. Three colors: Hudl's dark surface (#1E1E1E background), white for primary data, and a single accent color (the same blue used throughout the portfolio, #6BBFFF) for callout annotations and the row group labels. The redesign column does not get a different background, a colored border, or any other visual treatment that would telegraph a preference — the data makes the case without visual advocacy.

Typography is set at a minimum 16pt (Instrument Sans for data labels, DM Mono for row group labels and source footnotes). The 16pt minimum ensures legibility at projection distance without requiring the frame to sacrifice information density. Source footnotes are set at 11pt and positioned below each row group in a consistent location — small enough not to distract during a presentation but findable when a reviewer asks "where does that number come from?"

The comparison frame is produced as a standalone deliverable precisely because it is designed for multiple uses beyond the prototype:

• Slide deck export: The frame is exported as a 1920×1080px PNG and used directly as a slide in the Stakeholder Presentation Deck (Step 06, Deliverable 1). It replaces the text-and-bullet slide that the Step 06 document described for Slide 17 (The Assist Trade-Off) — the visual comparison is more efficient than a written description.
• Walkthrough video Section 4: The frame appears on screen during the walkthrough video narration of the three-way comparison, row by row. The video's screen recording zooms into individual rows as the narration covers them.
• Portfolio page static embed: A lower-resolution version of the frame (1200×675px) is embedded as a static image in the Step 08 section of the portfolio page — directly after the embedded prototype iframe — so a reviewer can see the comparison summary without opening the Figma file or watching the video.
• Print export (A3 / Tabloid): The frame is also exported at 300dpi for print contexts. At A3 (420×297mm) or US Tabloid (17×11in), the 16pt minimum type renders at approximately 10pt printed — still legible on a printed page passed around a conference room table. A QR code linking to the Figma prototype is added to the print version in the bottom-right corner.

14 participants across three sessions each (42 total sessions). 8 returning participants from Step 05 enable longitudinal comparison; 6 new participants (recruited through Utah Youth Soccer Association contacts and a Nevada club network outside the original Liverpool FC International Academy pipeline) test generalizability. The Latin square condition rotation from Step 05 is maintained — every participant completes all three conditions, no participant sees the same condition twice in the same position.

One protocol change from Step 05: participants in Condition B (Redesign) now use the hi-fi Figma prototype in presentation mode on a dedicated laptop, rather than a researcher-facilitated lo-fi walkthrough. Participants control the prototype themselves — they navigate flows, interact with components, and encounter edge cases without researcher guidance. The researcher observes and records without intervening unless the participant is blocked for more than 90 seconds (the ceiling at which task abandonment is recorded).

All participants complete the same 4-task sequence in each condition. Tasks are identical across conditions — the same game film segment, the same tagging goals — so that condition differences are attributable to the interface, not to task variation. The game film segment is a 28-minute second-half recording (the same segment used in Step 05 to allow direct comparison).

T3 (clip boundary adjustment) is new in Round 2 — it was not in the Step 05 task set. It was added specifically to test the hi-fi clip boundary control (the dedicated timeline expansion state added as a result of the ILG-03 iteration). T3 is particularly important for Condition A (Hudl Base) because boundary adjustment in the base workflow requires re-entering a separate clip editor — the mode switch overhead is directly measurable in this task.

The T3 boundary adjustment result is the sharpest finding in the table. The hi-fi clip boundary control reduces boundary adjustment time from 14m 07s in Condition A to 2m 33s — an 82% reduction for a task that is architecturally identical in both workflows. The difference is entirely interface: Condition A requires navigating to a separate clip editor; Condition B surfaces the adjustment inline within the tagging overlay.

The 0-event columns for auto-resume confusion and note field over-entry are the most direct validation of the Step 05 iteration log. Both ILG-01 and ILG-02 moved an element from "show by default" to "hidden until needed" — and zero recurrence in a larger, higher-fidelity test confirms both calls were correct.

• P10 used the Review Timeline as the primary tagging surface. Rather than tagging during playback, P10 watched the full segment without tagging, then annotated retrospectively via the Review Timeline scrubber. This is a valid workflow variant not designed for but not prevented by the interface. P10 completed T1 in 22m 08s — slower than the designed flow but still faster than Condition A. The finding surfaces a use case worth documenting: some coaches prefer watch-then-annotate over watch-and-tag simultaneously.
• All 3 Assist subscribers (P12, P13, P14) completed T2 faster in Condition B than in Condition C. Creating a thematic clip package was faster using the redesign prototype than navigating the Assist output, even though Assist had already done the tagging. The bottleneck in Condition C was locating clips by theme within the analyst-generated tag set — Assist output is organized by play type, not by coach intent. This directly validates the Step 05 finding about thematic clip authorship.
• P6 asked whether the system could learn their tagging patterns over time. After completing Round 2, P6 said: "After I've tagged 20 games, could it start pre-filling the event type based on what I usually tag in this situation?" This is an AI-augmentation question outside scope but technically feasible — the tag history generated by the redesign is exactly the training signal that would enable that suggestion layer. Noted as an open question for Step 10.

Task times are measured from "begin" to task completion, recorded per task on a dedicated stopwatch — not derived from session-level timestamps. Two timing categories are distinguished: active time (participant is directly performing the task) and transition time (navigating between modes, waiting for page loads, reorienting after a mode switch). This distinction is critical: the tag-entry and clip-creation tasks themselves are not inherently slow in Condition A; the mode switching between them is.

38 minutes and 40 seconds of the average Condition A session — 39% of total session time — is transition time: navigating between modes, not doing analytical work. Condition B reduces transition time to 48 seconds across the entire session. The redesign does not only make the task work faster; it eliminates nearly all the overhead between tasks.

• Fastest Condition B session: P7 (returning, Teacher-Coach, high Hudl proficiency) — 44m 12s total. P7 also had the smallest proportional improvement over Condition A — high-proficiency users have learned to navigate mode-switching efficiently. The redesign benefits all users, but benefits lower-proficiency users more.
• Slowest Condition B session: P10 (new, Club Coach, mid proficiency) — 1h 08m total. P10 used the Review Timeline as a primary tagging surface rather than tagging during playback. Still significantly faster than their Condition A session (2h 44m).
• Highest Condition A/B ratio: P5 (returning, Tech-Reluctant Veteran) — Condition A 3h 41m, Condition B 1h 02m. P5's T3 (boundary adjustment) dropped from 22m 15s to 3m 04s — the largest individual T3 improvement in the dataset, reflecting how much the dedicated boundary adjustment UI benefits users who struggle with the current clip editor.

• Average overlay open duration per tag (T1): 47 seconds — not meaningfully shorter than Step 05 lo-fi (49s). The overlay's cognitive complexity is not a bottleneck; the entry time is determined by coaching decisions, not interface friction.
• Average time from confirm to next T keypress: 3m 22s — the interval during which the interface is completely invisible and the coach is doing pure analytical work. In Condition A, this interval is interrupted by the mode switch to the clip editor.
• Boundary adjustment rate: 9 of 14 participants adjusted at least one clip boundary spontaneously during T1. 8 of 9 used the nudge buttons; 1 used the scrubber drag (P4, graphic design background, comfortable with video editing scrubbers).
• Undo usage: 3 participants used ⌘Z at least once. 0 used the toast undo affordance — all three used the keyboard shortcut, suggesting keyboard undo is more discoverable for keyboard-comfortable participants than the toast button. Both should remain in the design.

The 4 participants who completed an optional repeat session averaged 9m 28s for T1, vs. 11m 04s on first hi-fi exposure — an additional 14% improvement from one repeat session. In real use, a coach tagging one game per week would reach this level of familiarity within 2–3 sessions. The redesign's speed benefit compounds with practice.

Task time is a behavioral measure — it captures what participants did, not how they felt about it. Confidence and satisfaction ratings are attitudinal — they capture whether participants believe the output is correct, whether they'd use the interface again, and whether they'd recommend it. For a tool used by coaches to create content shared with players, confidence in the output is not secondary to speed: a coach who tags faster but doubts the accuracy of their clips may not publish them at all. The distinction matters particularly for Condition C, where the Assist output was objectively accurate but coach confidence scores were unexpectedly low.

The post-session questionnaire is administered after each condition session individually (not at the end of all three — to capture condition-specific reactions before cross-condition comparisons contaminate responses). It uses a 5-point Likert scale for all rated items, with one open-response field. Two additions over the Step 05 instrument: the "authorship confidence" dimension (Q3) and the NPS proxy question.

Q3 (Authorship confidence) is the most analytically important row. Condition A and B score nearly identically (4.7 vs. 4.8) — both produce coach-authored outputs. Condition C scores 1.9 — the lowest score across all conditions and all questions. This is not about Assist's output accuracy; participants acknowledged the tags are correct. It is about professional ownership of the analytical work. The redesign closes the speed gap with Assist while maintaining the authorship score coaches associate with self-created tags.

Q1 (Capture confidence) — Condition A: 2.9. Coaches who complete the tagging pass then return for the clip-cutting pass often discover they missed a moment. By the time they're cutting clips, they no longer have the context to know if the miss was intentional or accidental. The uncertainty produces a 2.9 score. Condition B's 4.6 reflects the confirmation toast and undo capability — the coach knows whether a tag registered immediately, before resuming the film.

Q4 (Publish confidence) — Condition C: 3.2. Significantly lower than Condition B (4.5) despite Condition C producing more clips. The lower score is driven by the authorship gap in Q3: coaches are reluctant to share clips they didn't make, even when they believe the clips are accurate. P13 (Assist subscriber): "I always re-watch the Assist clips before I send them to players. Not because they're wrong — because I want to make sure I'm standing behind them." P13's Condition B publish confidence score was 5/5.

• P5 (Tech-Reluctant Veteran, returning): Condition A open response: "I've been coaching for 22 years. I stopped doing this two years ago because it takes too long." Condition B open response: "I finished. I haven't finished a film session in two years." P5's Condition B session time (1h 02m) fell within their stated acceptable time budget from the Step 02 context interview. Q7 score: 5/5 for Condition B, 1/5 for Condition A.
• P11 (new, Club Coach): Q3 for Condition B: 3/5 — the lowest Q3 in Condition B. Explanation: "I trusted that it tagged it, but I wanted to see the clip play before I moved on." P11's concern is not about who made the tag (like Condition C) but about whether the auto-clip captured the right footage. This motivates ILG2-01 (inline clip play in the confirmation toast) — addressed in Final Iteration Notes, Deliverable 5.
• P13 (Assist subscriber, new): Q5 (time satisfaction): Condition C 4/5, Condition B 5/5. Q3 (authorship confidence): Condition C 1/5, Condition B 5/5. Post-session: "The Assist time is even better because I can do other things during the 6-hour wait. But I can't build the specific clips I want. This lets me do both — fast enough and mine." P13 is the Participant D composite from Step 05 — the coach for whom the redesign is the most strategically significant answer.

Zero detractors for Condition B is the most striking single number in the Step 09 dataset. No participant who used the redesign prototype scored it below 7 on the recommend question — including P10 and P11, who had the highest error rates and slowest sessions in Condition B. The Condition A result (12 of 14 detractors) is consistent with the qualitative finding that coaches use Hudl's base tagging workflow because it is the only option, not because they like it.

Coaches who pay $900–$3,300/year above their base Hudl subscription specifically to have analysts tag their film have already concluded that the base interface's time cost is unacceptable. They are the most sensitive indicator of whether the redesign's value proposition is real: if a coach would cancel Assist in favor of the redesign, the redesign has solved the problem the service was paid to solve. P12, P13, and P14 were recruited specifically as current, active Assist subscribers and agreed to complete all three conditions and a 30-minute structured debrief interview after the Condition C walkthrough — conducted before their Condition B session to avoid priming.

Key interview questions (full protocol in Figma file, Assist Interview page):

• Walk me through what happens after a game on Assist. What do you actually do, step by step?
• What does Assist do well that you couldn't do yourself in the base interface?
• Is there anything you want to do with your film that Assist doesn't let you do?
• If the base interface let you tag and clip in a single pass — same time cost as Assist, but you were making the tags — would you still pay for Assist?
• What would have to be true for you to cancel your Assist subscription?

All three participants adopted Assist because the time cost of the base workflow had become unsustainable — not because they preferred having an analyst tag their film.

• P12: "I would have done this from day one. I paid for Assist because I didn't have a choice, not because I wanted to."
• P13: "I like controlling what I tag. I just couldn't afford to spend the time. If I could do it fast enough myself, that's obviously what I'd want."
• P14: "I assumed they'd fix the interface eventually. I'm paying for Assist in the meantime."

This is the central finding of the Assist subscriber interviews. Assist is not satisfying a preference for delegation; it is satisfying a preference for usable output when the cost of producing it yourself is too high. The redesign does not create a new preference — it removes the cost barrier that made Assist necessary for this population.

• P12: "I trust the Assist clips about 80%. I always check the ones I'm going to use in a session. Not all of them — just the important ones. It's not that they're wrong, it's that I can't be sure without watching them."
• P13: "My players ask me sometimes, 'Why did you include this clip?' And I have to say, 'That was flagged as a defensive breakdown.' It's not my answer. I want to be able to say, 'I saw this happen in the third quarter and this is what I want you to see.'"
• P14: "The kids know the clips come from a service. It's fine, but it's different from when I pick the clips. When I pick them, they know I've watched the film. Assist clips feel more like a report. My clips feel like coaching."

P14's framing — "a report vs. coaching" — is the clearest articulation of the authorship gap in any participant response across either round of testing. It is used as an anchor quote in the Three-Way Comparison Frame (Step 08, Deliverable 4) and in the walkthrough video narration.

• P12: "If I could do what I just did [Condition B] in under an hour, on a Sunday night, every week — I would cancel Assist the same day."
• P13: "The session I just did took 54 minutes. My Assist turnaround is six hours — but I'm not doing anything during those six hours, so it doesn't feel like time. If this took the same time and I got to make the calls myself, I'd want this. But I'd need to know it's reliable."
• P14: "Honestly, if the base platform did what I just saw, I'd never have paid for Assist in the first place. I assumed it was impossible because Hudl never fixed it."

Two of three participants (P12, P14) stated cancellation intent contingent only on the feature being available. P13's condition — reliability — is addressed by the local storage fallback in EC-04 (network failure edge case, Step 07 Deliverable 5). P13's concern is exactly the scenario that fallback was designed to prevent.

• Complete coverage without watching: P13: "Assist tags everything. Even the moments I might miss at midnight because I'm tired. The redesign is only as good as my attention that night." The redesign requires a coach to watch the film and tag deliberately; Assist provides exhaustive coverage regardless of coach attention.
• Turnaround while coach is doing something else: P12: "I upload the game Sunday morning and by the time I've done family stuff, it's tagged. The interface requires me to sit there for an hour. An hour on a Sunday morning is different from six hours on a Sunday night, but it's still an hour."
• Multiple-game batch processing: P14: "During tournament weekends I have three games in two days. Assist handles all three." The redesign's 54-minute average still requires 2h 42m for three games. Assist's batch processing at tournament scale is not a capability the redesign competes with.

These three capabilities define the honest scope boundary of the redesign's value proposition. The redesign is not a replacement for Assist for coaches at tournament scale or whose primary need is comprehensive coverage with zero active time. It is a replacement for coaches whose primary need is time-efficient, author-controlled film output on a regular weekly schedule — the teacher-coach and club-coach personas the project has been designed for throughout.

• The redesign serves a different need than Assist, not the same need more cheaply. Coaches who need complete coverage with zero active time will not cancel Assist for the redesign. Coaches who need author-controlled output on a regular weekly schedule will. These are different populations with genuinely different needs.
• P12 and P14's cancellation intent is a real product signal. At $900–$1,200/year, this is a meaningful revenue indicator of how many Assist subscribers adopted it as a workaround for the base interface rather than as a preferred workflow.
• Reliability is a non-negotiable threshold for Assist subscribers. P13's caveat must be met by the local storage fallback before the redesign is viable for this population. This is not an edge case — it is a table-stakes requirement for replacing a service that is trusted to be reliable.
• The authorship gap is a durable differentiator. Assist's Q3 score of 1.9 cannot be closed by improving output quality because the gap is not about accuracy; it is about ownership. The redesign's Q3 of 4.8 is unreachable by a service that necessarily produces analyst-authored output.

The Final Iteration Notes document what changed as a result of Round 2 testing, what was challenged and survived, what was deferred, and what the honest methodological limitations of this testing program are. It is the last design decision record before Step 10's reflection and retrospective — it draws a line between "what the design is based on evidence" and "what remains genuinely open." A design project that arrives at Step 10 without this document is presenting conclusions; one that includes it is presenting evidence.

• ILG2-01: Toast — add inline "Play clip" affordance. Motivated by P11's response: "I wanted to see the clip play before I moved on." A "▶ Play" affordance is added that plays the clip inline within the toast — a 280×158px inline player expanding the toast to 120px height for the duration of clip playback, then collapsing. The inline player does not require navigating away from the film session. Figma frame: D-05b (toast with play affordance).
• ILG2-02: Onboarding — add mobile deferral nudge. Motivated by H4's partial validation: participants who attempt boundary adjustment on mobile pay a significant time penalty. A contextual nudge is added: when a mobile user opens the boundary adjustment controls, a one-time dismissible banner appears: "Adjusting clip boundaries is easier on desktop. Want to skip and finish in your Review Timeline?" Figma frame: M-EC-01.
• ILG2-03: Smart playlist — persist rule option surfaced earlier. Motivated by 6 of 14 Condition B open responses requesting this. The "Save as smart playlist" option is surfaced one step earlier: the Playlist Builder now shows a prominent "Save rule for future games?" prompt at the end of the session, rather than requiring the coach to find the toggle independently. Figma frame: D-07b.

• AI-suggested event type (P6's request): After 20+ games of tagging, the system has enough tag history to suggest event types based on the coach's patterns. Reasonable ML use case; out of scope for this project.
• Review Timeline as a primary tagging surface (P10's workflow): The Review Timeline currently supports retrospective editing but not tag creation from scratch. A "Tag from timeline" entry point is a meaningful scope addition — deferred accordingly.
• Tournament-week batch mode (P14's finding): A "batch session" mode for tagging multiple games in a single sitting with a shared roster and playlist structure. Would close the tournament-scale gap. Significant scope addition; deferred.
• Player-facing film annotation (P2's request): Whether players could annotate clips before a team review session — flagging moments for discussion. Adjacent to the redesign's shared-authorship model; out of scope but directionally supported by the data.

• Sample size: n=14 is adequate for identifying usability problems and directional attitudinal signals. It is not adequate for statistical inference about population-level behavior. All time data and NPS data are descriptive, not inferential.
• Sample demographics: All participants are from Utah or Nevada coaching networks. Geographic and demographic diversity is limited — particularly the absence of participants from urban markets with different sport distributions or technology access.
• Prototype fidelity gap: Condition B uses a Figma prototype, not a live implementation. Video playback, API response times, and data persistence are all simulated. In production, these may vary and could affect time and confidence measurements.
• Single-coder thematic analysis: Open response coding in Deliverable 3 was performed by one coder without inter-rater reliability check. Theme labels and counts should be treated as researcher interpretation, not objective categorization.
• Assist subscriber n=3: Three Assist subscribers is enough to identify consistent qualitative themes but not enough to generalize about the Assist subscriber population. Cancellation intent findings are compelling directional signals, not population estimates.

Step 10 inherits three unresolved questions — stated as honest open edges of what this testing program can answer:

• Does the 70% session time reduction hold at scale? The finding is from a controlled 28-minute film segment with a defined task set. Real post-game sessions vary from 60 to 180 minutes of footage with uncontrolled scope and context switching. Whether the redesign maintains its time advantage in uncontrolled real-world use is not answerable from this data.
• What is the long-term adoption rate? The two highest-proficiency returning participants showed the smallest proportional improvement — high-proficiency users have minimized mode-switching overhead through skill. Does the redesign provide enough incremental benefit to change the habits of highly-proficient Hudl users, or does it primarily serve lower-proficiency users and coaches new to film review?
• What percentage of the Assist subscriber population adopted Assist as a workaround vs. as a genuine preference? P12, P13, and P14 all adopted Assist as a workaround. If representative, the redesign's cancellation impact is larger than if most subscribers prefer delegation. A survey of Assist subscribers asking the adoption-reason question would produce a more reliable estimate.

This document summarizes outcomes across the full project. It is not a repeat of the Step 09 test results — those are documented in detail in Deliverables 1 through 5 of Step 09. This summary answers a different question: across 10 steps, two rounds of user testing, 14 participants, 42 test sessions, and every design iteration in between, what did this project actually produce and what is the quality of the evidence behind it?

The summary is written for three audiences with different needs: a hiring reviewer who wants to understand what was designed and why the evidence matters; a product team at Hudl (or a company like it) who wants to know whether this is a real product opportunity; and the designer themselves, who needs an honest account of what was learned to carry into the next project. All three versions of the summary are the same document — the evidence is the same regardless of who is reading it.

The project's design hypothesis, stated in Step 01 and carried through every subsequent step: a unified single-pass tagging interface — one that treats tagging, clipping, and playlist assignment as simultaneous properties of a single tagged moment rather than three sequential operations — would demonstrably reduce the time and cognitive load of a post-game film review session without requiring a back-end architecture change or a new pricing tier.

The verdict, based on the evidence produced in Steps 05 and 09: supported, with qualifications.

• Supported: Session time reduced by 70% in controlled testing (2h 58m → 54m avg.). Zero mode switches in the redesign vs. three in the base workflow. Attribution-driven playlist auto-assign worked without manual intervention in 11 of 14 T2 sessions. The design maps onto Hudl's existing data model — no new API endpoints required. NPS proxy: 0 detractors across 14 Condition B participants, vs. 12 of 14 detractors for Condition A.
• Qualification 1 — Prototype, not production: All Condition B testing used a Figma prototype with simulated video, simulated API response times, and no real data persistence. Whether the performance improvements hold in a live implementation with real network conditions and real footage volume is untested.
• Qualification 2 — Controlled task, not real use: Testing used a defined 28-minute film segment with a specified task set. Real post-game sessions are longer, less structured, and subject to fatigue, interruptions, and variable game complexity. The 70% reduction is a controlled-test figure, not a deployed-product figure.
• Qualification 3 — n=14, not a population: The participant sample is too small and too geographically homogeneous for statistical inference. The results are consistent and directionally strong — but they are descriptive findings from a usability study, not statistically valid population estimates.

The most important row in this table is the last one. The authorship confidence gap between the redesign and the Assist reference condition — 4.8 vs. 1.9 — was not a metric that existed at the start of this project. It was surfaced by the research, formalized in the questionnaire instrument, and validated in the test data. It is the finding that most clearly defines what the redesign offers that Assist structurally cannot: coach ownership of the analytical output, at a speed that makes that ownership sustainable.

Nine substantive design changes were made across the two iteration cycles (6 in Step 05, 3 in Step 09). The changes are documented in full in their respective iteration logs. A summary of the categories of change — and what they collectively reveal about the design process — is more useful here than a repeat of each individual change:

• Default-state changes (ILG-01, ILG-02): Two changes moved elements from "visible by default" to "hidden until needed" — auto-resume and the note field. Both produced 100% reduction in the problem they were designed to solve. The pattern is consistent with the research finding about cognitive load in the Tech-Reluctant Veteran and Evening-Session personas: every element visible during film watching that is not directly related to watching film is overhead. Default-state decisions are the highest-leverage design decisions in a tool used under cognitive load.
• Precision and feedback changes (ILG-03, ILG-06, ILG2-01): Three changes improved the accuracy of user actions and the confidence feedback after them — nudge increment reduction, toast thumbnail preview, and the inline clip play affordance. These are refinements to an interaction model that was already correct; they reduce the error rate and the residual uncertainty in the coach's mental model of what the system captured. None of them changed the architecture of the workflow.
• Discoverability changes (ILG-04, ILG-05): Two changes improved the visibility of triggers and options that participants consistently missed. The [Tag ⌨ T] label redesign and the team-default configurability addition both addressed the gap between what the design intended coaches to know and what coaches actually discovered in testing. Discoverability failures are among the hardest design problems to anticipate — they only become visible when you watch real users who don't share your mental model of the interface.
• Progressive disclosure change (ILG2-03): The smart playlist rule persistence option was surfaced earlier in the session flow in response to 6 of 14 participants asking for it in open responses. This is the one change driven by a positive feature request rather than a problem observation — coaches didn't need the redesign to show it to them, but when they encountered it, they wanted more of it.

Three core design decisions made in the earliest phases of the project — the concept sketches in Step 04 — survived without modification through both rounds of testing, all nine iterations, and the full fidelity progression from rough sketch to hi-fi prototype. They are worth naming explicitly because surviving intact through a rigorous process is stronger evidence of correctness than starting intact:

• The bottom-anchored overlay that preserves the full video frame above it. Tested formally in Round 2 (H3: zero occlusion events across 14 sessions), challenged by two participants who found the overlay dense on first exposure, and retained without modification. The constraint — the video frame must remain visible during tag entry — is the correct constraint. Every alternative considered (center modal, side panel, persistent drawer) violates it.
• The single-object model: one tagged moment creates a tag, a clip, and a playlist assignment simultaneously. This was the animating principle stated in Sketch B and in the Design Rationale document (Step 06): "The clip is created at the moment of tagging. Not after. Not separately. At the moment." Zero participants in either round of testing questioned this model. One participant (P10) used the Review Timeline as a primary tagging surface — a workflow variant that doesn't depend on the single-object model but doesn't contradict it either.
• Attribution-driven playlist auto-assign. The proposal that selecting a player should automatically check their playlist was made in the Step 04 Sketch B annotation and formalized in the Step 07 Component Spec Sheet as a client-side operation requiring no new API endpoint. In Round 2 testing, 11 of 14 participants completed T2 without touching the playlist assignment field. The one design concern — that auto-assignment might feel presumptuous, as auto-resume did for some participants — did not materialize. Coaches understand and accept that tagging #7 should add to #7's playlist.

The project's most strategically significant finding: among the three Assist subscribers recruited for Step 09, all three adopted Assist as a workaround for the base interface's time cost, not as a preferred workflow. Two stated they would cancel their subscriptions if the redesign were available. The third named a reliability threshold — addressed by the EC-04 local storage fallback — as the only remaining condition.

This finding is stated with its limitations visible: n=3 is not a population estimate. The three participants were recruited through coaching networks, not randomly sampled from Hudl's Assist subscriber base. It is possible — perhaps likely — that the wider Assist subscriber population includes coaches who genuinely prefer analyst delegation and would not cancel for the redesign. The data from P12, P13, and P14 is a strong directional signal, not a market sizing study.

What the data does say with more confidence: the authorship gap (Q3 score 1.9 for Assist vs. 4.8 for the redesign) is a real, named, felt experience for coaches who receive analyst-tagged output. It is not about accuracy — participants acknowledge the tags are correct. It is about professional ownership of the analytical work. This gap is not closable by improving Assist's output quality; it is structural to the service model. That is a finding worth surfacing regardless of what a product team decides to do with it.

Every finding in this project is assessed against the same standard: what is the quality of the evidence behind it, and what would it take to strengthen that evidence? This table covers the four primary claims the project makes:

Design reflection is not self-congratulation and it is not self-criticism. It is the honest account of what the process revealed that the designer didn't already know — about the problem, about the users, about their own assumptions, and about where the work is genuinely strong versus where it is held up by favorable conditions. A portfolio reflection that only summarizes what went well is not a reflection; it is a highlight reel. This document attempts something different.

The most consequential design decision in this project was not an interface decision — it was the problem framing in Step 01. Defining the problem as "the two-pass workflow creates structural overhead that cannot be eliminated by improving either pass individually — it requires collapsing the two passes into one" determined almost everything that followed. An alternative problem frame — "tagging is too slow," "clip-cutting is too tedious," "playlist management is too complex" — would have produced solutions that optimized individual steps without addressing the mode-switching overhead between them. The Step 09 Task Time Analysis makes this visible in numbers: 39% of the average Condition A session was transition time between modes, not task time within them. A design that made tagging faster or clip-cutting easier would have left 39% of the session time completely untouched.

This is the lesson I want to carry forward most: the quality of the problem definition is more decisive than the quality of any individual design decision that follows from it. A precise problem frame produces a coherent solution space. A vague one produces a collection of features that solve related but distinct problems and may not add up to a meaningful improvement for the user.

Three findings from research — Steps 02 and 03 — were not predictable from the problem definition alone and changed the design in ways that matter:

• The 11pm context. Before the Step 02 interviews, the tagging workflow felt like a tool problem — the interface is inefficient, here is a more efficient interface. After the interviews, it felt like a human problem: a coach who has been at school all day, coached a game, driven home, and is now at a laptop at 11pm with 90 minutes of film to review is not in the same cognitive state as a user in a usability lab at 2pm. That context shaped every default-state decision in the design — visible elements are overhead for a tired person in a way they aren't for a fresh one. The ILG-01 and ILG-02 changes (auto-resume and note field) were motivated directly by this context, not by abstract UI principles.
• The Assist subscriber as a persona, not an outlier. The Step 02 interview with the Assist subscriber (the basis for the Participant D composite) was initially treated as an edge case — a coach who paid for a premium service wasn't the primary design audience. The Step 03 competitive analysis and the Step 05 Assist walkthrough testing changed this framing entirely: Assist subscribers are coaches who encountered the same two-pass problem the rest of the participant set described, concluded that the base platform wasn't going to fix it, and found an external solution. They are not a different user type; they are the same user type at a later stage of the same frustration. Designing for the Assist subscriber rather than around them produced the authorship confidence finding — the finding that most clearly defines what the redesign offers that Assist cannot.
• Confidence, not just speed. The initial hypothesis was framed entirely in time terms: the redesign should reduce session time. The Step 05 post-session questionnaire introduced confidence ratings as a complementary measure, and the Step 09 results showed that confidence improvements tracked closely with time improvements but were not identical to them. P5 (Tech-Reluctant Veteran) had the largest time improvement in Round 2 and also the largest confidence improvement. P7 (high-proficiency returning participant) had the smallest time improvement and a more moderate confidence gain. The design's value is not purely efficiency — it is also the sense that the output is trustworthy and complete, which is a distinct dimension that time measurement alone does not capture.

If forced to name one design decision that most clearly separates this design from an alternative that "also solves the two-pass problem," it is this: the clip is created at the moment of tagging. Not as a separate step triggered by a button. Not as a batch process that runs at the end of the session. At the moment the coach presses T and confirms the tag, a clip exists. The coach doesn't create a clip — they create a tag that includes a clip by definition.

This decision required treating the tagging overlay not as a form that captures metadata about a clip the coach will create later, but as an interface that creates a complete asset — tag, clip, and playlist assignment — in a single action. The distinction is architectural (the data object is different) and experiential (the coach never thinks about clip creation as a separate task). It is also the decision that makes the single-pass workflow possible: if clip creation were decoupled from tagging, even by a small amount of user effort, the second pass would return. The mode switch is not between tagging and clip-cutting as UI surfaces; it is between tagging and clip-cutting as mental operations. Collapsing them requires making them literally the same action, not just adjacent actions on the same screen.

The design is strongest in the things that have been tested repeatedly and survived. Three elements meet this standard:

• The overlay architecture. The bottom-anchored overlay that preserves the video frame, appears only on trigger, and disappears on confirm has been tested by 14 participants across two rounds and has not produced the occlusion, disorientation, or visual complexity problems that alternative layouts would have. It is the right architecture for this context, and the evidence for that is both behavioral (zero occlusion events) and attitudinal (4.5/5 usability satisfaction).
• The attribution-to-playlist pipeline. The single mechanism that eliminates the most overhead — tagging #7 automatically adds to #7's playlist — is elegant in the sense that it is simple to understand, fast to use, and easy to override. It required no training, produced no confusion in testing, and eliminated the separate playlist-assignment step for 79% of clips tagged in Round 2 sessions.
• The edge case coverage. Step 07's edge case screens — 10 edge cases documented with designed behavior and explicit rationale — represent the highest-fidelity thinking in the project about what happens when the design meets real-world conditions. The local storage fallback for network failures (EC-04), the asymmetric clip window for tags at video boundaries (EC-02), the duplicate tag warning (EC-06), and the undo-after-auto-resume scenario (EC-10) are the kind of detail that separates a design that has been thought through from one that has been styled. P13's reliability concern in the Assist subscriber interviews maps directly onto EC-04. The edge case was written before the interview; the interview validated it.

The design has limits that are not failures of execution — they are honest boundaries of what a single-pass interface can do:

• It requires the coach to watch. Assist's core value proposition — upload and receive — remains beyond the scope of any watch-and-tag interface. A coach with 3 games in 2 days during a tournament weekend, or a coach who simply prefers not to watch film at all, is not the audience for this design. The teacher-coach who reviews film every Sunday night and the club coach who tags moments on the sideline are. The design serves those personas well; it should not overclaim for the ones it doesn't serve.
• The mobile experience is a deferred-precision workflow, not a full desktop equivalent. The two-step mobile tagging flow is the right design for a sideline context. But the finding from H4 (partially validated) — that mobile T3 boundary adjustment is 2.4x slower than desktop — means the mobile experience should be understood as a capture tool, not an analysis tool. Coaches who do their analytical work on a phone are not the primary audience, and the design should be marketed accordingly.
• The design cannot make a coach better at watching film. The overlay reduces the overhead of capturing what a coach notices. It does not improve what a coach notices. A coach whose analytical eye is weak will produce weak tags faster. The design's value is entirely dependent on the quality of coach attention during the film session — it amplifies the output of attention, not the attention itself.

Three things about my own design process became visible through this project that weren't fully visible before it:

• I underweight context and overweight interface in early problem framing. The Step 01 problem definition was initially framed as "the tagging interface is inefficient." The Step 02 research reframed it as "a tired coach at 11pm cannot sustain a three-hour workflow no matter how good the interface is." The second frame is the right one, and I needed user research to find it. In future projects I want to get to the context-level problem frame earlier — before the first wireframe, not after the first round of testing.
• I make better default-state decisions when I am explicit about cognitive load in the use context. The ILG-01 and ILG-02 changes — both of which moved elements from visible to hidden — were not obvious until I watched participants in testing. But in retrospect, they were predictable from the Step 02 context description: a cognitively loaded user at end of day, watching a long video, managing a complex task. Every visible element that is not immediately relevant is overhead in that context. I should be able to make that prediction earlier in the process, from the context research alone, rather than waiting to observe it in testing.
• Quantitative measures changed how I argued for design decisions. Entering this project, I expected the research output to be primarily qualitative — personas, quotes, observed behaviors. The decision to measure task times per-task and per-mode-switch (Deliverable 2, Step 09) produced numbers that made the design argument significantly stronger than quotes alone. "The transition between tagging and clip-cutting costs an average of 4m 22s per switch, and 6 of 14 participants required a second attempt to complete it" is a different argument from "participants found the mode switch confusing." In future projects I want to introduce behavioral quantification earlier — in the initial research plan, not as a post-hoc addition to the testing protocol.

This note was first sketched in Step 06 as the business framing for the Stakeholder Presentation Deck, where it was deliberately structured as three options rather than a recommendation — because the decision about what to do with this design belongs to product leadership with access to financials, subscriber data, and strategic priorities that a designer on a speculative concept project does not have. That framing is maintained here. This note presents the clearest account of what the evidence implies, names the questions it cannot answer, and stops short of telling a product team what to decide. A designer who makes that distinction is more useful in a product review than one who doesn't.

The Step 03 competitive analysis identified two dynamics in the sports video platform market that are relevant to this design's strategic position:

• SportsVisio is explicitly targeting Hudl's most-frustrated segment. SportsVisio's marketing copy positions the platform for programs "without a video coordinator" — Hudl's same primary base-tier user. SportsVisio's single-pass tagging capability and lower price point ($300–$800/year vs. Hudl's base tier) are a direct challenge to Hudl's retention in the teacher-coach and club-coach segment. The redesign closes the capability gap that makes SportsVisio's pitch credible.
• The $0 price of the redesign is a structural competitive advantage over both alternatives. Assist adds $900–$3,300/year for a service that addresses the same workflow problem. SportsVisio addresses it in the base product at a lower price than Hudl. The redesign offers the same capability improvement at $0 above base subscription — which means it doesn't require a coach to change platforms or add a budget line. The barrier to adoption is zero. The barrier to Assist adoption is $900. The barrier to SportsVisio adoption is platform migration. In a market where coaches choose based on workflow fit and budget, $0 is not a small advantage.

The Step 06 Stakeholder Presentation Deck presented three options without recommending one. At the close of Step 09, the evidence has a stronger shape than it did in Step 06. The options are revisited here with updated framing — not to recommend one, but to characterize what the Step 09 data implies about each:

• Option A: Ship as a base-platform improvement, accept partial Assist cannibalization. The Step 09 Assist subscriber interview data suggests that the cannibalization risk, while real, applies specifically to subscribers who adopted Assist as a workaround for the base interface rather than as a preferred workflow. The data from P12, P13, and P14 — each of whom stated the workaround motivation explicitly — is directionally consistent but not a population estimate. If a majority of Assist subscribers adopted it as a workaround (which the interview data suggests but does not prove), then Option A's cannibalization risk is lower than it initially appears: those subscribers would be retained as base-tier users rather than lost, since they never preferred the Assist model. The coaches who genuinely prefer Assist's delegation model — coverage without watching, batch processing at tournament scale — are not going to cancel for the redesign regardless of what is shipped.
• Option B: Position as a new "Assist Lite" tier at an intermediate price point. This option captures some Assist revenue while being substantially cheaper than the full service. The Step 09 evidence makes this more complex than it appeared in Step 06: the coaches most likely to subscribe to an Assist Lite tier are the same coaches who stated they would cancel Assist entirely for a free base-platform improvement. A paid tier above base creates a barrier that a free feature does not. Whether the revenue from an Assist Lite tier exceeds the retention value of making the improvement free is a financial modeling question the Step 09 data cannot answer.
• Option C: Hold the redesign, continue the current Assist strategy. The Step 09 data adds specificity to the cost of this option: coaches in the teacher-coach and club-coach segment are actively looking for alternatives (P14: "I assumed they'd fix the interface eventually"), and SportsVisio is offering a credible one. Option C preserves Assist revenue in the short term but accepts ongoing churn from the workflow-frustrated segment to platforms that have already solved the problem. This is a defensible product strategy if Hudl's growth priorities lie elsewhere — but it is not a costless one.

The cannibalization question — "will this redesign reduce Assist revenue?" — was raised in Step 06 and is sharper now than it was then. The honest answer, with the evidence this project produced:

Yes, for some Assist subscribers. P12, P13, and P14 represent coaches who would cancel. The question is what proportion of the full Assist subscriber population they represent. The Step 09 sample cannot answer that. A survey instrument based on the interview protocol — specifically the question "Why did you originally subscribe to Assist?" with options that distinguish between "the base interface was too slow" and "I preferred not to do the work myself" — would produce a more reliable estimate of the at-risk subscriber share.

Not necessarily for all Assist subscribers. The three capabilities identified in Finding 4 of the Step 09 Assist Subscriber Interview Findings — complete coverage without watching, turnaround during coach downtime, tournament-weekend batch processing — are not replicated by the redesign. Coaches whose primary value from Assist is one of these three capabilities are not at significant cancellation risk. They are paying for something the redesign does not offer.

The most useful thing a product team could do with this finding is segment their Assist subscriber base by adoption reason. If the majority of subscribers are in the "workaround" category, Option A's cannibalization risk is manageable and the retention benefit (preventing churn to SportsVisio) may exceed the Assist revenue impact. If the majority are in the "genuine preference" category, Option A's cannibalization risk is low regardless — and the redesign's primary value is competitive retention, not Assist cannibalization.

Independent of the Assist question, the redesign has a competitive case that is worth stating directly: Hudl's retention in the teacher-coach and club-coach segment depends in part on those coaches not finding SportsVisio's pitch compelling. SportsVisio's pitch — single-pass tagging, lower price, same core functionality — is compelling to the coaches most frustrated by the two-pass workflow. The redesign removes the feature gap that makes SportsVisio's pitch credible.

Platform migration is high-friction — coaches have years of game film, established rosters, and player accounts in Hudl. The barrier to switching is real. But coaches who are actively frustrated with a workflow they spend 3+ hours on every week are the coaches most likely to evaluate alternatives seriously. P5 — the coach who stopped doing film review entirely because of time cost — is exactly the coach most at risk of leaving Hudl for a platform that makes the workflow sustainable. The redesign is, among other things, a retention tool for that persona.

A designer working on a speculative concept project can produce: a clear problem definition supported by research; a validated design direction supported by testing; a specific account of what the data implies for the strategic question; and an honest statement of what the data cannot answer. This project has produced all four.

What this project cannot produce: a revenue model for an Assist Lite tier; a quantitative estimate of the at-risk Assist subscriber share; an engineering feasibility assessment from inside Hudl's codebase; or a recommendation about which strategic option is correct given Hudl's financial position, product roadmap, and competitive priorities. These require access this project does not have.

If this project were being presented to a Hudl product team, the ask would be the one stated in the Step 06 Stakeholder Presentation Deck, Slide 21: not a shipping commitment, and not a decision about the revenue model — but a green light to invest design and research resources in answering the questions this project has identified but cannot answer. The next step is not "ship this." The next step is "validate the adoption-reason split in the Assist subscriber base, run an engineering feasibility review, and run a 90-day deployment study with a cohort of teacher-coaches." That is a specific, scoped ask that the evidence from this project supports.

A design project that ends with no open questions has either been explored with extraordinary thoroughness or has not been examined honestly. This project has unanswered questions — some because the scope did not allow for them, some because the evidence produced was directional rather than conclusive, and some because they are the kind of question that only deployment data can answer. Naming them is not a weakness of the project; it is a description of what comes next.

The questions are organized by the type of work that would be required to answer them — research, design, engineering, or product strategy — so that a hypothetical continuation team could prioritize them by their own available resources and expertise.

• Does the 70% session time reduction hold in uncontrolled real-world use? The controlled-task testing used a 28-minute film segment with a specified task set. Real post-game sessions are longer, less structured, and subject to fatigue and interruptions. A deployment study with real coaches using the live product over a full season would answer this. The relevant metric is not a lab time ratio but a week-over-week change in the average time coaches spend on post-game film work.
• What is the adoption-reason split in the full Assist subscriber population? The Step 09 Assist subscriber interviews (n=3) found that all three adopted Assist as a workaround. A survey instrument based on the interview protocol, administered to a larger sample of Assist subscribers recruited through Hudl directly, would produce a more reliable estimate of the workaround-vs-preference split. This number is the key input for any Assist cannibalization model.
• Does the design benefit experienced coaches as much as less-experienced ones? The Step 09 per-participant variance data suggested that high-proficiency Hudl users (P7) showed smaller proportional improvements than lower-proficiency users (P5). A study that controls for coaching experience and Hudl proficiency independently would clarify whether the redesign's primary value is onboarding lower-proficiency users to film review or reducing overhead for all users regardless of skill level. The answer changes who the redesign should be marketed to first.
• How does the design perform at tournament scale — 3 games in 2 days? P14's finding (Assist subscriber interviews) identified this as a genuine scope gap. A study with coaches during tournament weekends, comparing the redesign's batch-session feasibility against Assist's batch processing capability, would clarify whether a tournament-week batch mode is a necessary feature or whether coaches adapt their workflow naturally (e.g., tagging across the tournament and publishing at the end).
• Does the progressive onboarding (contextual tooltips, Step 07 EC-09) work at first-session discovery? The two contextual tooltips — anchored to the [Tag ⌨ T] trigger and the Review Timeline header — were designed but not tested in the Round 2 protocol (participants were introduced to the prototype by the researcher). A first-session study with participants who receive no introduction would test whether the tooltips alone are sufficient for discovery, or whether additional onboarding is needed.

• Can the Review Timeline support tag creation from scratch, not just editing? P10's workflow — watching all film first, then annotating via the timeline — suggests a secondary entry point for tag creation that the current design doesn't explicitly support. The Review Timeline as a post-watch annotation surface would require a "Tag from this moment" action at each timeline position, which is a meaningful addition to the surface. The design question is whether this creates confusion between the two entry points (overlay during playback vs. timeline after viewing) or whether they coexist naturally.
• Should the confirmation toast inline player (ILG2-01) loop or advance to the next timeline moment? The inline player added by ILG2-01 plays the clip in the toast. After it plays, it could loop (replay automatically), stay paused on the last frame, or advance to show the next unreviewed clip in the session. Each behavior has a different implication for coaches who want to review clips as they go vs. coaches who want to review everything at the end. This is a small decision with a meaningful effect on the review workflow; it requires testing to resolve.
• What does the shortcut configuration panel look like in practice? The shortcut configuration panel (Edge Case EC-08, Step 07) was designed at a framework level — what it contains and how it behaves — but not fully polished in the hi-fi mockups. A complete design of this panel, including the capture-mode interaction and the conflict warning state, is documented in the edge cases but has not been tested. A targeted usability study of the settings panel alone would validate the design before a production implementation.
• How does the smart playlist rule builder scale to complex rule logic? The current smart playlist design supports simple rules (all clips tagged with event type X for player Y). Coaches who want more complex logic — "all defensive breakdowns involving the center backs in the final 15 minutes of any game this season" — would need compound rule support. The design of a compound rule builder is unresolved; the current implementation leaves this as a V2 question.

• What is the actual API surface required? The Component Spec Sheet (Step 07, Deliverable 4) documents the proposed API props for each component based on Hudl's public developer documentation and the Assist data model. An engineering review against the private API and the live product codebase would confirm whether the "no new endpoint" claim holds, or whether specific interactions (e.g., the local storage sync for offline tags, the thumbnail generation trigger) require back-end work beyond the UI layer.
• What is the thumbnail generation latency in production? The Component Spec Sheet specifies that thumbnails should be generated within 1.5 seconds of tag confirmation, with a fallback if generation fails. Whether 1.5 seconds is achievable at scale depends on Hudl's video processing infrastructure. If thumbnail generation is slower — 3–5 seconds — the toast experience degrades meaningfully (the shimmer placeholder persists longer, reducing the confirmation value of the thumbnail). This is an engineering feasibility question that cannot be answered from outside the system.
• Can the local storage fallback sync reliably when connectivity is restored? EC-04 (network failure edge case) specifies that tags saved to local storage during a connectivity failure are auto-retried in the background when connection is restored. The reliability of this sync — specifically in cases where the coach closes the browser tab before the retry fires, or where a duplicate tag is created by a retry that didn't know the original write had succeeded — requires an engineering implementation decision about idempotency keys and sync state management that the design spec does not fully resolve.

• What is the right pricing strategy for this feature? The design is specified as a base-platform improvement with no additional cost. Whether Hudl chooses to implement it that way, bundle it into a new tier, or use it as a platform-upgrade hook is a product strategy decision. The design can be implemented under any of these models; the model affects marketing, positioning, and the cannibalization calculation but not the interface itself.
• Is there a phased rollout strategy that tests Assist cannibalization before full deployment? A beta rollout to a cohort of base-tier coaches who are identified as high-churn risk (coaching large programs with high game volume, low Assist adoption rate) would test the retention hypothesis without exposing the full Assist subscriber base to the redesign before the cannibalization question is answered. This is a product experiment design question, not a UX question.
• How does the redesign interact with Hudl's existing AI roadmap? P6's request — "could the system learn my tagging patterns over time?" — is a reasonable description of an AI layer on top of the unified tagging interface. Whether Hudl's AI investment (including the Assist analyst workflow) is better directed toward this kind of coach-personalized suggestion layer than toward full-delegation automation is a product strategy question that requires context about Hudl's internal priorities this project doesn't have.

Some questions are outside this project's scope not because they weren't asked, but because they require access or expertise that a speculative concept project simply cannot have. They are named here because a product team reviewing this work should know that the designer is aware of them:

• Hudl's actual Assist subscriber count, adoption-reason distribution, and revenue breakdown. Without this data, the cannibalization estimate is directional at best. The entire strategic analysis in Deliverable 3 is built on interview data from 3 subscribers and inference from public market signals. A product team at Hudl with access to subscriber data could produce a more reliable estimate in a single afternoon.
• Whether Hudl's engineering team considers the single-object model (tag + clip + playlist assignment as one object) to be a straightforward implementation or a significant refactor. The spec argues that the data model is consistent with how Assist already works. Whether the front-end architecture to surface that model in the film player interface is weeks of work or months is not knowable without an internal engineering review.
• The legal and contractual scope of using Hudl's visual design language in a speculative concept project. The hi-fi mockups use Hudl's existing dark-UI tokens, type scale, and color system as a starting point. Whether this constitutes acceptable reference use for a portfolio project or requires explicit permission is a legal question, not a design question. The mockups are clearly labeled as a speculative concept project throughout; they do not claim to be official Hudl work or to represent Hudl's actual product direction.

"What I'd do differently" is the most honest thing a designer can write about their own work. It is also the most useful for a hiring reviewer: it demonstrates not just what was done, but what the designer learned from doing it — which is the relevant indicator of what they'll do better next time. This document is written as if the project were starting over today, with the benefit of everything learned in the nine steps that preceded this one. It does not identify failures; it identifies decisions that were correct given the information available at the time and that I would make differently given what I know now.

• I would recruit Assist subscribers in the first round of interviews, not the second. P12, P13, and P14 were recruited for Step 09 because the Assist question became strategically significant over the course of the project. But the Assist subscriber persona was identified in Step 02 research — I just didn't recruit one for the initial interview set. The Step 09 Assist subscriber findings would have been available 8 steps earlier if I had. Specifically, the "adoption as workaround" finding and the authorship gap characterization would have shaped the competitive analysis in Step 03, the problem framing refinements in Step 04, and the design principle documentation in Step 06. Recruiting the most strategically complex persona first — not last — would have produced a more complete design argument from the beginning.
• I would time the Step 02 context interviews more precisely. The context notes document that sessions took place late at night when possible, to replicate the post-game review context. But "late at night" is not a rigorous protocol specification — some interviews were at 9pm, some at 11pm, some over video call from a coach's kitchen. A more rigorous context protocol (all interviews between 10pm and midnight, in the space where the coach actually does film review, using the device they normally use) would have produced richer and more comparable context data. The insight about cognitive load at end of day was real; a more rigorous context protocol would have made it more precise.
• I would add behavioral observation to the research, not just interviews. The Step 02 research was entirely interview-based. Observing a coach doing a real film session — even once, even informally — would have revealed workflow details that interviews can only partially capture: exactly where coaches pause, rewind, and re-watch; how they navigate between Hudl's UI surfaces; what they do when they're not sure whether a moment is worth tagging. The transition-time data from Step 09 testing (39% of Condition A session time was mode switching) was not predictable from interviews alone; it became visible only when I watched participants in a controlled session. I could have seen a version of it earlier with one session of direct behavioral observation.

• I would write the design hypothesis before the first sketch, not after the research synthesis. The design hypothesis — stated in Step 01 and refined through Step 03 — was in place before any sketches were drawn. But the specific quantitative form of the hypothesis (≥40% session time reduction) was not established until the Step 06 Design Rationale document, after two phases of research and the first round of testing. Writing the hypothesis in testable, quantitative form before the first sketch would have made the Step 05 test results more directly evaluable and would have sharpened the conversation about what "success" means earlier in the process.
• I would map the three-way comparison (Base, Assist, Redesign) from Step 01, not Step 06. The three-way framing — positioning the redesign not just against the current workflow but against the Assist service model — was introduced in Step 06 for the stakeholder presentation and became the backbone of the Step 08 prototype structure. But it was the right framing from the beginning: the design is making a claim that it can offer what Assist offers (usable film output at manageable time cost) plus what Assist cannot (coach authorship). That claim could have been the design brief. Starting with the three-way framing would have kept the Assist comparison explicit and testable throughout the entire project, rather than introducing it halfway through.

• I would build the mobile flow in parallel with desktop from Step 04, not defer it to Step 07. The hi-fi mobile mockups (Step 07 Deliverable 2) were designed after the desktop flow was complete. This sequencing meant that mobile-specific design decisions — the two-step bottom sheet, the long-press trigger, the deferral-to-desktop model for precision work — were made after the desktop interaction model was already established. Some of those decisions were correct precisely because they diverged from the desktop model. But having to diverge in hi-fi is harder and riskier than building divergence into the design from the first sketch. Desktop and mobile are different contexts; they should have been treated as parallel design problems from the concept phase rather than as a desktop-first design with a mobile adaptation.
• I would specify the edge cases at the end of the lo-fi phase, not the end of the hi-fi phase. The Step 07 Edge Case Screens were produced as part of the hi-fi developer handoff. Several of those edge cases — particularly EC-04 (network failure) and EC-09 (first-session onboarding) — had implications for the lo-fi design that would have been worth knowing earlier. EC-09's progressive disclosure approach to onboarding, for example, could have informed how the lo-fi prototype introduced the overlay trigger to Step 05 participants, potentially producing richer discoverability data in Round 1 testing.
• I would design the Review Timeline as a primary surface earlier. The Review Timeline was designed as a post-session review tool — a place to clean up and publish. P10's Round 2 behavior (using it as a primary tagging surface) revealed that it could be more than that. If the Review Timeline had been designed with a "Tag from timeline" entry point from the beginning — as a parallel path to the overlay trigger, for coaches who prefer watch-then-annotate over watch-and-tag — it would have been testable in both rounds rather than identified as a deferred V2 feature after the second round of testing.

• I would include T3 (clip boundary adjustment) in Round 1 testing, not only Round 2. T3 was added to the Round 2 task set specifically to test the hi-fi clip boundary control. But the lo-fi prototype in Step 05 included a version of the boundary adjustment UI — and the comparison between the lo-fi and hi-fi versions of that task would have been directly measurable if T3 had been in both rounds. The absence of T3 in Round 1 means the 82% T3 time reduction can be attributed to the design iteration but cannot be quantified against a Round 1 baseline.
• I would administer the authorship confidence question (Q3) in Round 1, not just Round 2. Q3 was introduced in Round 2 specifically to probe the Assist comparison. But the authorship question is relevant to the lo-fi prototype comparison as well — and having a Round 1 baseline for Q3 would have made the Round 2 authorship score more interpretable. As it stands, the 4.8 score for Condition B in Round 2 is the only data point; there is no Round 1 comparison to assess whether the hi-fi fidelity improvement contributed to the authorship confidence score or whether it was stable across fidelity levels.
• I would run at least one session of unmoderated first-session testing before the Round 2 protocol. All Round 2 testing was moderated — participants were introduced to the prototype by the researcher before the session began. The progressive onboarding (contextual tooltips, EC-09) was never tested in a true first-session, unmoderated context. A round of unmoderated testing — participants receive a link to the prototype and nothing else — would have tested the discoverability of the trigger and the effectiveness of the onboarding tooltips in the conditions they were actually designed for.

• I would write the Design Rationale document (Step 06 Deliverable 3) in parallel with the lo-fi design, not after it. The Design Rationale documents every major design decision with the chain of evidence behind it. Writing it in parallel with the design — adding a decision record every time a significant choice is made, not reconstructing it afterward — would have made the document more accurate and would have served as a useful forcing function: if a design decision can't be stated in the "research finding → design decision → implementation choice" format, it may not be well-grounded enough. Writing the rationale after the fact means reconstructing motivations that were clearer at the time of the decision than in retrospect.
• I would produce the Three-Way Comparison Frame (Step 08 Deliverable 4) at the start of the project, not at the end. As noted in the problem framing section above — the three-way comparison is the right frame for the entire project, and producing the comparison frame early would have kept that framing explicit throughout every step rather than introducing it in the prototyping phase.

If forced to name the single change that would have the greatest positive effect on the quality of this project — the one that would not just improve an individual step but change the trajectory of the whole — it is this: recruit an Assist subscriber in the first round of Step 02 interviews.

The Assist subscriber is the most strategically important persona in this project. They are the coach who has already concluded that the base interface is too slow, found an external solution, and is paying for it despite its limitations. They are the user whose behavior most directly tests the redesign's core claim. And they are the user whose voice is absent from the first 6 steps of the project, present only as a composite inference drawn from base-tier user interviews and a competitive analysis of the Assist service.

Having a real Assist subscriber in the Step 02 interview set — before the problem was framed, before the competitive analysis was written, before the first sketch was drawn — would have made the Assist question not a late-arriving strategic complication but a founding design constraint. The authorship gap, the workaround motivation, the reliability threshold, the tournament-scale scope boundary — all of these were discovered in Step 09. All of them could have been known in Step 02.

The project would have been different. Whether it would have been better is genuinely uncertain — there is an argument that developing the design against the base-tier user persona first, then stress-testing it against the Assist subscriber persona later, produced a more robust solution than designing for both simultaneously from the beginning. But the honest answer is: I don't know, because I didn't try the other order. That's the open edge of this reflection, and it's the right place to end a project that has tried throughout to be clear about what it knows and what it doesn't.