Assignment 4 CS2 Smart Replay Platform

- Software Engineering Team Project

Format Description

Content Index

• 1. Team division of labor and contribution
• 2. Interface prototype design
  • 2.1 Prototype tool
  • 2.2 Design process
  • 2.3 Screens and interactions
  • 2.4 Prototype link
• 3. Challenges and solutions
• 4. Takeaways and team evaluation
  • 4.1 Three main takeaways
  • 4.2 Real feedback from teammates
  • 4.3 Feedback issues and developer responses
• 5. Team discussion photos (non-posed)
• 6. PPT link

1. Team division of labor and contribution

The prototype design phase (4th assignment) marked an important step for the team moving from requirements analysis toward product visualization. Unlike the 3rd assignment, which focused on document writing, the core deliverable of this assignment is an online-accessible, clickable high-fidelity interactive prototype, along with a defense PPT and blog documentation. Therefore, the division of labor shifted from "document chapter ownership" to "ownership by prototype module, presentation task, and blog section," ensuring every deliverable has a clear owner while avoiding overlap.

2. Interface prototype design

2.1 Prototype tool

Tool: Modao

For this prototype design, Modao was selected as the primary tool. During the tool selection phase, the team compared common prototyping tools such as Axure RP, Balsamiq Mockup, and Figma, and ultimately chose Modao based on the following four considerations:

(1) Online sharing, no installation
(2) Hotzone interaction, cross-page jumps
(3) Component reuse, visual consistency
(4) Team collaboration space

2.2 Design process

The prototype design was not accomplished overnight but went through six stages of progressive convergence. Each stage had clear deliverables, and the output of the previous stage served as the input for the next, avoiding the chaos of "drawing pages while changing requirements."

Stage 1: Requirements Analysis

Based on SRS V1.1, the team confirmed 22 functional requirements and 3 core use cases. The key at this stage was clarifying the prototype scope—which functions must be reflected in the prototype and which can be replaced by text annotations. For example, real Demo upload and backend parsing are not within the prototype scope, but the four-step parsing status on the "New Review" page must be displayed upfront in the prototype so reviewers understand the asynchronous flow of the real product.

Stage 2: Information Architecture

Determined 6 left navigation items (Overview, My Reviews, Aim Training, Campus Squad, Players & Friends, Personal Center) and a list of 10 pages. This stage solved the question of "whether the four modules can fit into the same workbench"—unified left navigation, login state, and page skeleton, avoiding each module being built separately.

Stage 3: Low-Fidelity

Drew wireframe sketches based on Chapter 7 of the SRS, focusing on confirming page layout and information hierarchy. The low-fidelity stage did not fuss over colors and fonts, only answering "what should be seen at first glance on this page."

Stage 4: High-Fidelity

Determined the dark theme, navigation, and component library. The UI teammate defined dark backgrounds, panel hierarchies, orange accent colors, button styles, and metric card styles, and made them reusable components. The key at the high-fidelity stage was visual consistency—10 pages placed together should not feel like they were made by different people.

Stage 5: Hotzone Interaction

Cross-page jumps + state annotations. This stage linked buttons, navigation, cards with real usage paths: Login → Overview → New Review → Report → My Reviews, as well as branches to training, squad, and friends from the overview. After hotzone configuration, the prototype changed from "static screenshots" to a "clickable demo" interactive prototype.

Stage 6: Review & Iteration

Prototype review, walkthrough, and revision. QA teammates walked through hotzones and field consistency against SRS use cases, UI and frontend teammates provided improvement suggestions from their perspectives, and revisions after review were synchronized to the blog. This stage ensured the prototype is not only "clickable" but "clickable correctly."

2.3 Screens and interactions

The prototype includes 10 high-fidelity pages covering four modules: Smart Replay, Campus Squad, Aim Training, and Account Center. Each page has a clear functional positioning and interaction path, described below by module.

Page 01 Overview

The Overview is the workbench homepage, responsible for "seeing status and next steps at a glance." The top of the page is the value proposition "Turn the last match into the next advantage," with the primary action button "+New Review" leading directly to the creation flow. The middle shows status: 3 matches reviewed, average Rating 1.18, average ADR 89.3, match win rate 67%. The bottom has three "Next Step" cards: analyze the last match, practice a set first, play together next match, leading to review, training, and squad respectively.

Page 02 - Login & Register

The Login & Register page is an entry point connecting the workbench and backend identity. The left side has the welcome message "Next progress starts here," and the right side has the account input area with username demo_player and password; the formal product verifies identity via backend, as annotated on the prototype page. Two actions: "Login and Enter" goes to the workbench, "Create Account" for new user registration. Permission boundary: review, squad, and personal center require login; aim training supports no-login access, with scores stored locally first.

Page 03 - My Reviews

My Reviews is the match archive page, with the core design principle "original Demo stays local." The top of the page prompts "Original Demo stays local; here shows the analysis report and history for each match," clarifying the boundary of "file locally, report on platform" to avoid players misunderstanding the upload behavior. The match list includes three recent matches: Mirage, Inferno, Ancient, with dates, scores, rounds, and status. Each record has "View Report" to enter the review, and the top allows creating a new review.

Page 04 - New Review

The New Review page puts the four-step flow upfront, with zero-threshold sample data. The page offers two import methods: automatic import and manual ZIP upload, with a drag-and-drop area to initiate analysis. Four-step flow: 01 Read data → 02 Identify rounds and players → 03 Calculate performance metrics → 04 Generate report. The page clearly annotates "The defense prototype uses sample data and does not upload real Demo." Parsing is an asynchronous process, and the prototype uses four-step states to display the real states of "queuing, parsing, completed, failed" upfront.

Page 05 - Review Report

The Review Report is the core page of FR-1 Smart Replay, and the report must strictly match the current match and player. Match header: Mirage / DE_MIRAGE, 2026/10/24, 23 rounds, our team 10:13 opponent. Key metrics: KDA 33/14/2, ADR 141.6, contribution round rate 78.3%, headshot rate 30.3%. Tabs and charts: four tabs of Match Overview, Round Review, Utility & Survival, Detailed Data; 23-round influence bar chart.

Page 06 - Aim Training

The Aim Training page shows five modes: Grid Tap, Reaction Test, Large Flick, Precision Micro-adjustment, Smooth Tracking, corresponding to FR-3 requirements. The prototype shows mode selection and operation entry, with a unified "Select Mode" action. The page annotates: the actual frontend training module contains the complete game; the prototype does not redraw the game screen. Aim training is a pure frontend module, retaining the original game running method; the prototype only does the entry and flow.

Page 07 - Campus Squad

The Campus Squad page turns team formation from QQ group word-of-mouth into a lobby list with filters, rank, and region information. Three-step flow: Get team code → Join in game → Captain starts, closing the campus scenario loop. Filters: All Modes, Competitive Match, Priority Mode, Partner Mode; 6 practice squad cards. Squad cards include map, rank, region; "+Publish Squad" initiates recruitment.

Page 08 - Players & Friends

The Players & Friends page supports searching players and finding teammates by specialty. The top search box supports finding players by nickname. The friend list includes Alice, Bob, Charlie, annotated with specialties in entry fragging, utility communication, and online time. Each friend has "View Card" to enter the player card page to understand level and needs. Friend cards make "role complementarity" explicit, providing a basis for squad matching.

Page 09 - Personal Center

The Personal Center page is the landing point of FR-4, linking player profile, friends, and squad together. Personal card: Demo Player, East China · Perfect C+, tags: Looking for Teammates, Mirage, Competitive Match. Profile editing: nickname, Steam friend code, personal signature, synchronized after saving. Two entries: View Friends goes to Players & Friends, Find Squad goes to Campus Squad.

Page 10 - Player Card

The Player Card page is a squad decision page, allowing players to quickly judge suitability before joining a squad. Player profile: Alice, East China · Perfect C+, tags Mirage, Looking for Teammates, Weekend Online. Game level Perfect C+, regular maps Mirage/Inferno. Teammate needs: friendly communication, stable play; can add friend or return to friend list. The card is a squad decision page, allowing players to quickly judge suitability before joining a squad.

Core flow:

2.4 Prototype Link

https://modao.cc/proto/c6pYF5D8tngg2yPkh90v/sharing?view_mode=device&screen=rbpVZ2KbgPN2vHiVI #CS Demo Master 界面原型-proto

3. Challenges and solutions

Core Challenges Encountered by the Team

The most challenging part of prototype design is integrating modules from different teammates into the same platform. For example, account and team functions need to interface with backend APIs; aim training must retain the original game running method; Demo review involves local parsing, upload, and report display—data sources and states are all different. The hardest part is verifying that the report matches the current match and player, while loading large map data in batches to avoid displaying wrong data or causing page lag.

(1) Difficulty 1: Cross-Module Integration—Different Data Sources and States

Problem Description: Account and squad functions need to interface with backend APIs; aim training retains the original game running method; review involves local parsing, upload, and report display.

Attempts & Solutions: Unified the workbench framework and left navigation; mapped module states (not logged in/parsing/analyzed/recruiting); annotated API fields and data flow with sample data in the prototype, aligning frontend and backend on the prototype.

(2) Difficulty 2: Data Consistency & Map Data Performance

Problem Description: The report must match the current match and player; the map data volume is large, and loading it all at once can easily display wrong data or cause lag.

Attempts & Solutions: Strongly bound the match header (map, date, score, player) to report data; lazy-loaded map data by round and player, rendered in batches, producing the report framework first before filling in charts.

4. Takeaways and team evaluation

4.1 Three Main Takeaways

(1) Determined the unified workbench and navigation first, then built individual pages; the four modules share the same skeleton, so subsequent integration will not require rework.

(2) Used sample data to first validate page states, button paths, and chart layouts, providing a clear reference standard for real feature development.

(3) Account, squad, and review functions annotated data sources and fields at the prototype stage, significantly reducing frontend-backend communication costs.

4.2 Real Feedback from Teammates

Zhanhong Liu · UI Perspective

• Dark design has an esports style; inverted display is highly readable and adapts to low-light environments
• Left menu bar is simple and clear

Keyou Su · Player Perspective

• Content is concise and easy to understand; even zero-basis players can understand what each part does

Yanzhengyu Guo · Frontend Perspective

• Black-orange color scheme fits the positioning; unified style with strong atmosphere
• Modular information; player basic info and introduction in two separate cards with clear hierarchy
• Orange "Add Friend" button is distinct and intuitive

4.3 Feedback Issues & Developer Responses

(1) Menu font too small, folds when window is small
Reported by: Zhanhong Liu
Resolution: Adjust menu font size and responsive breakpoints; switch to icon navigation + drawer expansion at small window widths to avoid incomplete display.

(2) Only dark theme, too dark; hope for light option
Reported by: Keyou Su
Resolution: Colors managed by theme tokens; dark/light switching supported during development; prototype reserves entry in settings page first.

(3) Gray small text too small; hope for font adjustment
Reported by: Keyou Su
Resolution: Improve contrast of gray small text and provide font size options; minimum font sizes for body and auxiliary text written into design specifications.

Developer Response:

"The prototype was converted from frontend pages and has some bugs; we can ensure these issues are resolved during delivery."

All issues above are recorded in the issue list and will be regressed item by item in the Alpha phase; fix results will be updated synchronously to the course blog.

5. Team discussion photos （Non-posed）

The photos below were taken during real prototype review and walkthrough sessions (not staged). They are also published in the course blog and used in slide 20 of the defense PPT.

Photo 1 (Dorm): checking the Modao prototype page against the running screen — non-staged.

Photo 2 (Classroom): walking through hotzone paths and page flows on a tablet — non-staged.

6. PPT Link

https://github.com/2310209788-del/cs2-intelligent-review-platform/tree/main/ppt