Fourth Assignment — Prototype Design | MIN-roamer Travel Planning and Social Platform

Course: EE308FZ — Software Engineering
Team: MIN-roamer
Project: Travel Planning and Social Platform（旅行规划社交平台）
Assignment: Fourth Assignment — Prototype Design
Deadline: November 1, 2026, 23:59
Prototype design tool: Figma
Interactive prototype: MIN-roamer — Figma high-fidelity prototype
Documentation status: Prototype-design report with supplied screenshots, SRS mapping and an evidence-based review. Live interaction outcomes are not claimed without a recorded click-through.

目录

1. Assignment Overview and Format Description

Item	Information
Course	EE308FZ — Software Engineering
Assignment title	Fourth Assignment — Prototype Design
Team name	MIN-roamer
Project name	Travel Planning and Social Platform（旅行规划社交平台）
Main demonstration city	Fuzhou, Fujian, China
Assignment requirement	Teaching assistant's Fourth Assignment — Prototype Design notice, published October 19, 2026 (requirements provided in the course announcement)
Assignment objective	Translate the approved SRS into a coherent, high-fidelity interface prototype, document key interaction paths and present the design process and outcomes.
Specialized prototype design tool	Figma (Web high-fidelity prototype)
Interactive prototype URL	Open the MIN-roamer Figma interactive prototype
GitHub supporting assets	MIN-roamer documentation assets
Prototype presentation (PPT/PDF)	A separate Assignment 4 slide deck URL was not provided with these materials. The GitHub assets folder is a reference-material directory, not a verified presentation URL.
Prior SRS	Travel Planning and Social Platform — SRS v1.0

1.1 Assignment Deliverables

This blog is organized around the transition from the earlier Software Requirements Specification (SRS) to the present interface prototype. Screenshots provide visual evidence of page composition and design; they are not, on their own, proof of backend implementation or persistent data storage.

1.2 Assignment Grading Checklist

Grading item	Points	Where it is addressed
Table of contents, format description and published prototype link	5	Section 1; Figma prototype URL included
Markdown blog layout	5	Headings, tables, screenshots and links throughout
Key points and difficulties	4	Sections 5 and 8
Member tasks and contribution proportions	6	Section 4; 14 members, contributions total 100%
Specialized prototype design tool	5	Section 5; Figma interactive-prototype link
Prototype design process and results	25	Sections 5–7 and live prototype
Accurate, clear and vivid results report	15	Section 6 and interface annotations
Challenges, attempts, resolution status and lessons	15	Section 8
Real collaboration photos and peer reflections	8	Section 9
Plan execution and workload distribution	4	Sections 4 and 9
PPT demonstration and prototype interaction	4	Section 10 and classroom presentation
Report	4	Sections 1–10 and presentation deliverable
Total	100	Blog + prototype + presentation

The 20 presentation-related points require an actual classroom report and demonstration. They cannot be obtained simply by including more screenshots in the article.

2. Project Overview and Design Objectives

2.1 Background and Problem Statement

Travelers commonly move between map applications, itinerary notes, saved travel guides, social posts, messages, and expense spreadsheets. For group travel, separating these functions increases the effort required to maintain a consistent itinerary and coordinate with travel companions. MIN-roamer aims to bring important planning and social activities into one Web-based workspace, using Fuzhou as the demonstration city.

The previous SRS (version 1.0, dated October 15, 2026) defines the major functional groups: user and profile management; trip planning and map interaction; destination information; budget and expenses; community and social collaboration; and AI travel assistance. Requirements are classified into P0 (core), P1 (important enhancement) and P2 (optional extension).

2.2 Main Users and User Goals

The prototype targets both individual travelers who want to discover places and organize an itinerary, and groups who want to plan together. Public visitors can explore shared material, while registered travelers can create private itineraries and manage their content according to the permission model in the SRS. Trip owners and invited members have different capabilities, especially for deleting a trip and managing membership.

Our key interface goals are to keep navigation understandable, make the map and daily itinerary visible together, reduce friction between destination discovery and planning, and display costs and social content in a consistent visual language. The AI assistant is planned as supporting functionality rather than a replacement for user decisions.

2.3 From Requirements to Interface Evidence

SRS requirement group	Intended user-facing experience	Interface evidence in this blog
FR-AUTH	Account/profile, personal trips and preferred language	Figures 11–12
FR-TRIP	Day-based schedule, places and map route	Figure 8
FR-DEST	Discovery, attractions, food, weather, transport, reviews	Figures 1–7
FR-BUD	Budget summary, spending and expenses	Figure 9
FR-SOC	Public trips, travel-buddy posts, publication entry	Figures 10 and 13
FR-AI	Trip generation and travel Q&A	AI entry visible in Figure 8; independent assistant screen not supplied

The original SRS contains low-fidelity layouts to describe information architecture. The figures in this assignment present the newer, visually refined interface direction. This distinction matters: a screen can faithfully illustrate an intended function even when its live behavior still needs to be tested.

3. Assignment Scope, Design Boundaries and Key Points

The scope of this stage is interface prototype design and explanation, not a claim that every server-side API has been deployed. The screenshots show intended components, example content, and possible actions. Features such as identity verification, current weather, transport routes, follower statistics, public reviews and payment-like information must be accurately labeled as simulated or data-backed according to their actual state.

The key design problems are: (1) how to make six function modules feel like one coherent product; (2) how to connect the daily schedule with geographical information; (3) how to make multi-step and multi-category forms understandable; (4) how to communicate the difference between public and private content; and (5) how to preserve a legible interface using a dark visual theme.

The visible design uses a dark navy/teal background, orange for primary actions and active selections, cyan accents for secondary information, large photographs, and reusable cards, tabs and pill-shaped filters. This is an observation from the supplied screens, not a claim that a formal design-system specification has been completed.

4. Project Division of Labor and Contributions

4.1 Team Organization

MIN-roamer consists of 14 students organized into six functional teams: Group A (User & Personal Profile), Group B (Trip Planning), Group C (Destination Information), Group D (Budget & Expense Management), Group E (Community & Social Features) and the AI Group. Chen Hang coordinates the overall project. This division follows the team organization established in the previous assignment and provides the corresponding structure for prototype review and handoff.

4.2 Member Responsibilities and Contribution Table

Student ID	Member	Prototype-stage responsibility aligned with module assignment	Contribution
832401103	Chen Hang	Team lead; requirements alignment, progress coordination and account-related review	8%
832401120	Qiu Yuqi	User/profile and community interface alignment; cross-module coordination	8%
832401130	Zhuang Yijun	Destination backend and supporting AI backend / integration assistance	7%
832402119	Wang Jingling	Trip-planning UI layout and visual design direction	7%
832402130	Zou Jiayu	Trip-planning frontend interaction mapping and page review	7%
832401105	Qiyang Chen	Trip workflows, data requirements and backend-facing interface review	7%
832401206	Wenjie Huang	Attraction, destination and food-discovery frontend alignment	7%
832401115	Kang Ciqi	Weather-related frontend and destination-information presentation	7%
832401208	Huang Qiwei	POI-related backend/data review and destination-search requirements	7%
832401107	Chen Yibing	Budget/expense interface presentation and interaction requirements	7%
832401104	Chen Kongzhou	Expense backend rules, summary data and validation review	7%
832401101	An Liuzhi	Community posting and browsing interface requirements	7%
832401102	Zha Shi	Community permissions and social backend interaction requirements	7%
832402107	Yuhe Jiang	Primary AI feature planning and integration	7%
Total	14 members		100%

4.3 Collaboration and Workload Measurement

The division combines user-facing UI responsibilities with backend and data support. Work in one module depends on information from others: a trip uses destinations; expenses belong to a trip; public posts may refer to shared itineraries; and AI assistance uses both destination and itinerary context. The AI role has been clarified in this assignment: Yuhe Jiang leads AI integration, while Zhuang Yijun provides auxiliary backend support. The agreed percentages describe the team's allocation of contribution for this assignment and do not imply that each member designed an equal number of screens.

5. Prototype Design Tools and Process

5.1 Specialized Tool and Prototype Deliverable

Figma is the specialized tool selected for the MIN-roamer high-fidelity Web prototype. The supplied Figma prototype link is the primary interactive design deliverable:

• Open Figma prototype
• GitHub assets and accompanying project documentation

The interface uses a coherent dark navy/teal visual theme, orange primary actions, reusable navigation bars, pills, cards, panels and modal dialogs. Using a specialized prototyping workspace makes it possible to organize page states and define click targets and transitions. The Figma link identifies the prototype project; the existence of a link alone does not verify every specific transition, API or persistence operation.

Prototype versus implementation: Figma is used for interface and navigation demonstration. The prior SRS describes a proposed React / Spring Boot / H2 system architecture, but it does not follow that those backend services are operational simply because the Figma pages exist.

5.2 Design Stages

Stage 1 — Requirements review. The team starts from SRS v1.0, using the six functional groups and their priority labels (P0/P1/P2) to decide which experiences are central to the prototype.

Stage 2 — Information architecture. The high-fidelity screens provide four clear top-level entries: Discover, Trip Planning, Budget, and Travel Community. Personal information, city selection and Chinese/English switching are reached through the global navigation area.

Stage 3 — High-fidelity visual system. The prototype applies repeated tab bars, destination cards, category filters, orange call-to-action buttons and carefully grouped information panels. Large images are used for travel discovery; compact cards and labels support scanning in analytical screens.

Stage 4 — Scenario mapping. The supplied screens illustrate user-centered journeys: search and discover a place, arrange a multi-day trip, inspect budget information, browse community posts, enter post creation and inspect profile/verification states.

Stage 5 — Review against the SRS. The prototype and screenshots are compared with requirement IDs and acceptance scenarios, with attention to map–itinerary ordering, financial display consistency, simulated data and publishing permissions. This report records the issues and proposed resolutions; it does not assert that changes were implemented without visible proof.

5.3 Visual and Interaction Conventions

The repeated dark surfaces and orange highlights establish continuity across pages. In the Discover module, every tab uses a similar search area and category navigation, while the lower content changes to fit attractions, food, weather, transport, reviews or guides. In the planning and budget modules, important summary information remains prominent while detail is organized into columns and cards. Figma's prototype navigation should be used in class to show these relationships directly rather than relying exclusively on screenshots.

6. Interface Prototype Design and Results

6.1 Discover Fuzhou: Destination Overview

Figure 1. Discover Fuzhou — Destination Overview.

The Discover Fuzhou page groups city information into seven sections: Overview, Attractions, Food, Weather, Transport, Reviews and Guides. A prominent search bar and quick destination tags provide direct entry points. The overview presents compact cards for weather, recommended attractions, food and transport, followed by a photograph-oriented city selection area.

This composition follows a progressive information strategy: provide a rapid city summary first, then let visitors enter a dedicated information category. The search box and category tabs remain consistent across the destination subpages, reducing the learning cost of switching tasks.

6.2 Attractions: Search, Filters and Cards

Figure 2. Attraction browsing and filtering.

The Attractions tab shows filters for district, attraction type and sort order. For example, a traveler can narrow places by Gulou District, select a historic neighborhood or park, and choose between recommendation, rating and distance-oriented sorting. The result area uses large destination photographs, place names, short descriptions, tags and a “View Details” entry.

Design intention: combine fast scanning with lightweight filtering so that users can move from city browsing to a specific destination without needing to open many unrelated pages. Data note: ratings and review counts shown in example cards must be treated as demonstration values unless their source and authenticity are verified.

6.3 Food: Category and Spending-Oriented Discovery

Figure 3. Food discovery page.

The Food tab reuses the same visual navigation and search components as Attractions, but adapts its filters to cuisine and dining needs. Visible choices include fish balls, meat swallows and other local foods, alongside recommendations such as low per-person spending and nearby results. Each food card combines a short introduction, category, indicative price/distance and details entry.

Design intention: consistency of search/filter controls across content types, while allowing domain-specific attributes such as cost and culinary specialty. Any displayed prices, review counts or travel distances should be clearly understood as example data if they are not connected to verified services.

6.4 Weather: Seven-Day Information and Travel Advice

Figure 4. Weather page with seven-day presentation.

The Weather tab shows a current-condition summary and seven forecast cards. The example presents temperature, humidity, wind and air-condition labels, followed by activity-oriented tips such as walking, carrying an umbrella or using sun protection. A short disclaimer identifies the content as illustrative forecast information.

Design intention: convert weather data into traveler-facing advice without obscuring the forecast itself. The SRS expects weather information to follow the selected city; whether the final prototype uses live or mock data must be verified independently. A real-service failure should have a clear fallback state.

6.5 Transport: Route Search and City Transit Guidance

Figure 5. Transport route inquiry and urban transit information.

This screen separates a route inquiry form from the city's metro guidance. The user can provide a starting point and destination and choose walking, public transit, metro or driving. The result card demonstrates one proposed path; the adjacent panel lists metro lines and the lower cards provide arrival advice for major rail stations.

Design intention: keep transport planning and reference information on one page. The screenshot explicitly identifies route suggestions as static examples rather than live navigation, so the Blog does not claim real-time routing, dynamic fares or guaranteed travel duration.

6.6 Reviews: Travel Experiences and Community Content

Figure 6. Review feed and experience-filter interface.

The Reviews tab uses content categories and sorting chips to organize travel experiences. Each entry includes author information, a rating indicator, location/context tags, a brief narrative and a read-more entry. The screenshot also labels the displayed reviews and ratings as prototype examples.

Design intention: turn destination exploration into social proof and allow travelers to compare personal experiences. In an eventual system, user-generated content would need publishing permissions, moderation expectations and authentic review data; these are not established merely by the prototype screenshot.

6.7 Guides: Discovering Curated Routes

Figure 7. Travel guide selection.

Guide cards present alternative trip patterns with day count, theme, short route descriptions and a detail entry. Visitors can filter by the intended duration (one day, two days, three or more) and preferred style such as historical exploration, food or scenic photography. An additional button invites users to take ideas into their own trip plan.

Design intention: bridge passive content discovery and active itinerary creation. The guide provides inspiration; the trip planner provides the personalized schedule that follows.

6.8 Trip Planning: Calendar, Schedule and Map

Figure 8. Trip Planning — day panel, schedule and map.

This is the central interface of MIN-roamer. The prototype presents a named three-day trip, day-selection cards, timestamped activities, a place-search field, and a map with numbered markers and a suggested route. Important actions at the top include AI Assistant, Invite Members, and Add Place.

The three-pane layout serves distinct but connected tasks: selecting the travel day on the left, reading the ordered schedule in the middle, and understanding geographic relationships on the right. Displaying these simultaneously reduces unnecessary back-and-forth navigation between a list and a map.

Requirement correspondence: FR-TRIP-01–09, especially the core requirements for creating/editing trips, placing items into dated schedules, and maintaining an association between map markers and itinerary entries. A screenshot shows that these controls exist visually; the group still needs to test clicking, dragging, saving and refresh persistence to claim functional completion.

Review finding: in the screenshot, the schedule lists Three Lanes and Seven Alleys at 09:00, fish-ball dining at 12:30, and West Lake Park at 16:20, whereas the map labels appear numbered in the reverse place order. The map sequence and schedule should be reconciled or explicitly explained if they represent different route directions.

6.9 Budget and Expenses: Summary and Records

Figure 9. Trip Budget — summary, daily spending chart and expense list.

The budget interface places the overall CNY 3,600 budget, an approximately 46% usage ratio and CNY 1,944 remaining amount at the top. Below, a daily spending chart sits beside an expense list organized by item, category and date. A highly visible “Add Expense” button supports the intended recording workflow.

This design gives travelers a high-level financial picture before presenting detailed records. The three displayed daily totals (CNY 486, 760 and 410) sum to CNY 1,656, consistent with CNY 3,600 minus CNY 1,944. The visible four expense rows sum to CNY 1,190, however. If the list is intentionally truncated, it should say “Recent expenses”; if it is intended as a complete list, the example figures should be reconciled.

Requirement correspondence: FR-BUD-01–06, including expense editing, categories, totals, filters and charts. The page illustrates some of these features, but editing and deletion interactions require actual testing.

6.10 Community Overview: Trips and Travel Buddies

Figure 10. Travel community with featured itineraries and buddy posts.

The community page offers categories for curated trips, buddy discovery and place reviews, together with destination/date sorting controls and a content-publishing entry. A featured journey dominates the first screen, while lower travel-buddy cards display recruitment dates, destination and applicant counts.

Design intention: keep browsing and publishing in one community context, while making the distinct content types explicit. Users should be able to browse public trips without editing other users' content. The final access rules must agree with the SRS and any newly proposed verification requirements.

6.11 User Profile: Personal Trips and Saved Inspiration

Figure 11. User profile, summary statistics and personal-content tabs.

The profile page combines a photographic cover, avatar, nickname/description and account actions. The upper statistics summarize public trips, saved inspirations, buddy activity and followers. Below, the page separates profile details and verification information from tabbed content areas such as My Trips, My Favorites, My Buddy Posts and Joined Trips.

Design intention: give travelers one recognizable place to recover their itineraries and social content. Scope note: the earlier SRS treats follower relationships as P2; the example follower number must not be presented as evidence of a completed follower system.

6.12 Identity Verification: Staged Form and Demo State

Figure 12. Identity-verification interface.

This screen presents three conceptual stages: entering personal information, uploading proof and receiving a review result. Visible fields include a name, user type, institution, file-upload area and consent checkbox. The primary button explicitly reads “Submit Verification (Demo: Immediate Approval)”.

The step indicator helps the user understand the intended process, while the consent checkbox draws attention to the sensitivity of identity documents. The immediate-approval label makes this a simulated review flow, not evidence of a real identity-verification service. Production handling would require appropriate data minimization, retention, access-control and deletion policies.

Requirements change to review: the SRS describes account authentication and content permissions but does not clearly mandate identity verification before publishing posts. The team should decide whether this prototype rule is an approved addition and update the requirements accordingly.

6.13 Community Post Creation: One Entry, Three Content Types

Figure 13. Post-creation modal with travel-buddy form.

The modal includes three publication categories: Travel Buddy, Public Trip and Place Review. The visible Travel Buddy form contains a title, destination, departure/return dates, recruitment size, description and Save/Cancel controls. Opening the form as a modal preserves the context of the underlying community page.

The category tabs support several publishing workflows through one entry point while keeping different field groups logically separated. The SRS-related buddy-post requirements include creating and managing one's own posts, filtering by destination and displaying recruitment states (FR-SOC-07–09). Input validation and persistence should be checked in the interactive prototype before the Blog describes them as working.

6.14 Consistency and Readability Assessment

Across the supplied screenshots, the top navigation, discovery tabs, rounded filters and orange action buttons are used repeatedly. This helps establish a recognizable product identity. The dense dark surfaces also create challenges: secondary text must have adequate contrast, buttons should be distinguishable without relying only on color, and long pages should retain clear section hierarchy. These are design considerations to evaluate with the actual prototype, not claims of completed accessibility testing.

7. Interaction Scenarios and Evidence-Based Verification

7.1 User Journeys Represented in the Prototype

Journey A — From discovery to itinerary: Enter Discover, choose Attractions or Guides, inspect a destination card, switch to Trip Planning and locate the Add Place entry. The visual structure of these steps is represented in Figures 1–8.

Journey B — Daily itinerary and map: Open the three-day Fuzhou trip, select a day, read activities in chronological order and relate the selected day to map labels. The screenshot supports the concept of a shared itinerary/map workspace, while route reordering and actual data synchronization require a live interaction check.

Journey C — Travel budget: Open Budget, read remaining funds, inspect daily spending and choose Add Expense. The prototype depicts this entry, but the response to entering a new record is not visible in the supplied images.

Journey D — Community participation: Open Travel Community, view the featured trip and recruitment cards, then use the Create Post form. Figure 13 shows the modal and fields for a travel-buddy post.

Journey E — Profile and verification: Enter the personal profile and proceed to the identity-verification page. The verification view visibly labels immediate approval as a demo behavior rather than real identity checking.

Journey F — AI support: The Trip Planner includes an AI Assistant entry. Its destination-aware assistance is a design goal, and the Figma prototype is the proper place to verify any additional screens or transitions. No dedicated AI panel was part of the supplied screenshot collection.

7.2 Verification Matrix: What Is Visible and What Still Requires Clicking

The following is an evidence audit, not a fabricated test-run report. “Visible” means that the interface element or state can be verified from the 13 supplied UI screenshots; “not verified” means a live action would be necessary to establish its behavior.

Scenario	Evidence in the provided screens	Verification status
T01 Global navigation	Discover / Trip Planning / Budget / Travel Community are visible	Visible; transitions not independently tested
T02 Destination tabs and filters	Attraction, Food, Weather and other tabs each have corresponding screens	Visible; actual filtering actions not independently tested
T03 Day-based itinerary	Day 01–03 and a map appear on the trip page	Visible; switching/synchronization not independently tested
T04 Add Place	Add Place button and search field appear	Visible; modal/submission not evidenced
T05 Add Expense	Add Expense button and spending summary appear	Visible; new-record behavior not evidenced
T06 Community categories	Curated trips, travel buddies and reviews tabs appear	Visible; category click-through not independently tested
T07 Travel-buddy form	Modal includes title, dates, recruitment size, description and Save/Cancel	Visible; validation and persistence not evidenced
T08 Profile verification	Profile links to a distinct verification-form design	Both screens visible; demo action not independently tested
T09 Chinese/English toggle	中 / EN selector appears in main navigation	Visible; translation completeness not independently tested
T10 AI assistant	AI assistant entry appears in the trip header	Entry visible; separate panel not included in screenshots

Interpretation: At the prototype-design stage, visual coverage is substantial: destination, trip, budget, community and profile screens can all be described with concrete evidence. A live classroom demonstration should separately confirm page navigation, click targets, form states and any implemented transitions. None of the entries above should be interpreted as proof of a running API or persistent storage.

8. Difficulties, Solutions, Current Status and Lessons

The following four items are concrete design-review findings based on the submitted high-fidelity screenshots and the previous SRS. Each entry separates the issue, an actionable solution, available evidence and the lesson learned. A recommended solution is not described as an already completed change.

8.1 Keeping Daily Schedules and Map Routes Consistent

Difficulty: Day 01 displays 09:00 Three Lanes and Seven Alleys, 12:30 fish-ball dining and 16:20 West Lake Park. In the map, however, the visible numbered route is West Lake Park → fish-ball stop → Three Lanes and Seven Alleys. A user could confuse geographical route order with chronological visit order.

Solution approach: Use a single ordered itinerary-data list as the source for both date cards and numbered map markers. When a user edits or reorders a place, regenerate the map numbering and route order from the same state; include a clear label if one view intentionally uses a different order.

Status / evidence: The ordering discrepancy is visible in Figure 8. A corrected screen or recorded Figma interaction was not provided, so resolution is not independently established.

What we learned: Interface consistency includes the meaning of shared data across components, not simply matching colors and typography.

8.2 Ensuring Financial Example Data Is Internally Consistent

Difficulty: The Budget screen shows CNY 3,600 total and CNY 1,944 remaining, meaning CNY 1,656 spent. Its three daily bars total CNY 1,656, but the four visible expense rows total only CNY 1,190. Readers cannot tell whether the expense list is intentionally partial.

Solution approach: Either show all records whose amounts contribute to the summary or label the visible list as Recent Expenses and provide an all-expenses navigation entry. Recalculate mock totals whenever example rows change, even if the prototype does not connect to a real database.

Status / evidence: The summary arithmetic matches the three daily bars, but the visible list needs explanation. A revised budget screenshot is not included, so the item remains a documented review recommendation.

What we learned: Credible demonstration data supports user trust and makes an early-stage interface easier to assess.

8.3 Reconciling Login Requirements with Identity-Verification Prompts

Difficulty: The profile states that completing identity verification enables certain posting features, while the community describes login as the condition for publishing. The previous SRS mainly specifies login and content permissions rather than this additional identity-verification gate.

Solution approach: Define a single permission rule, map the decision to each content type and update both profile and community messages consistently. If identity verification is adopted, add it as an explicit requirement and clarify how users are informed about data collection. The button's Demo: Immediate Approval behavior must stay visibly distinguished from real document review.

Status / evidence: Both differing messages are present in the supplied screens. Whether the team adopted a revised rule is not verified by the images.

What we learned: Prototype reviews can uncover new business-rule decisions that should be sent back into requirements engineering.

8.4 Distinguishing Mock Data from Live Information

Difficulty: Weather, route advice, ratings and review counts can appear authoritative even when they are used only as example data. This may lead reviewers to overestimate the implemented behavior.

Solution approach: Apply consistent Demonstration Data / Example Only labels to relevant panels, show unavailability or empty states when services are absent, and avoid presenting illustrative values as verified forecasts, reviews or navigation results.

Status / evidence: The weather and transport screens already identify sample information. Other example ratings and counts are visible, but their source has not been independently verified. This is partially addressed visually, with further data-source clarity recommended.

What we learned: Accurate presentation of capabilities is part of sound UX design and makes prototype assessment more meaningful.

9. Team Collaboration, Schedule and Reflections

9.1 Team Discussion Evidence

Figure 14. Candid classroom discussion as team members examine a laptop-based interface.

Figure 15. Team members jointly view and discuss a laptop screen.

These two photographs document face-to-face teamwork, as requested in the assignment. They show members gathering around a computer and reviewing screen material rather than a posed group portrait. Exact meeting times and the contents of individual remarks are not documented by the images, so we do not attribute specific comments or decisions to photographed individuals.

9.2 Planning Framework and Evidence of Progress

The original SRS is dated October 15, 2026, the Assignment 4 announcement is dated October 19, 2026, and the current Figma prototype and screenshot collection serve as the design-stage deliverables. The following table records the intended task progression and available output evidence, not an invented daily attendance record.

Period	Workstream	Output / evidence available in this report
Requirements baseline (before Oct 19)	Review SRS v1.0 and its six module boundaries	Chinese/English SRS and named functional requirements
Prototype organization	Define key navigation groups, visual styles and page states	Consistent navigation and tabs across Figures 1–13
High-fidelity screen design	Prepare Discover, Trip, Budget, Community and Profile screens in Figma	Figma prototype link and 13 supplied interface screenshots
Design review and reporting	Map screenshots to SRS and identify contradictions	Section 7 evidence matrix and four Section 8 review findings
Submission stage (by Nov 1)	Publish Blog, prepare classroom presentation, demonstrate the prototype	Blog and Figma link available; Assignment 4 PPT/PDF public URL not supplied here

The objective of this timeline is to make the prototype handoff explicit: requirements provide the baseline, Figma provides the shared design artifact, and the Blog connects the screens to features, usability concerns and evaluation criteria.

9.3 Collaboration Mechanism and Peer Evaluation

The project adopts module-oriented coordination. Frontend/UI contributors focus on the relevant user journeys, backend contributors check associated data entities and business rules, and the team lead coordinates relationships between modules. A shared SRS and the Figma prototype help keep terminology, screen responsibilities and decisions in a common reference. The GitHub materials directory provides a separate location for documentation assets: RoamMin_Docs/assets.

Peer evaluation based on assigned responsibilities: The trip-planning design role is important because the schedule and map must remain synchronized. Destination contributors support a wide range of content types, including attractions, food, weather and transport. Budget contributors are responsible for keeping financial calculations and displayed information consistent. Community and user contributors coordinate publishing permissions, profiles and the modal form. For AI, Yuhe Jiang takes the leading integration role, and Zhuang Yijun contributes supporting backend work. These complementary responsibilities clarify ownership and reduce the risk of contradictory assumptions across the interface.

Team reflection: The two discussion photographs and the multi-module interface collection demonstrate the importance of reviewing a prototype as one product rather than as separate screens. The largest design insights concern synchronized trip data, consistent financial examples, accurate permission messages and transparent separation between demo data and live services. These observations are grounded in the supplied design evidence, rather than invented private comments from team members.

10. Presentation and Deliverables

10.1 Deliverable Links

• Figma interactive Web prototype: MIN-roamer — High-Fidelity Prototype
• Project design assets on GitHub: RoamMin_Docs/assets
• Previous Software Requirements Specification (English PDF): SRS v1.0
• Assignment 4 PPT/PDF: A separate public presentation file URL was not provided. This is distinct from the GitHub assets directory and must be published as part of the course's slide deliverable.

10.2 Classroom Demonstration Script

1. Open the Figma prototype at the URL above; introduce the product's four principal navigation groups.
2. Present Discover Fuzhou, switching among Attractions, Food, Weather and Transport to show the unified interaction pattern.
3. Present Trip Planning with the three-day schedule and map; explain selected-day state, route numbers and the Add Place entry.
4. Present Budget with the summary, daily bars, expense list and Add Expense entry.
5. Present the Travel Community, open the Create Post form and explain its three content types and required information.
6. Present the Profile and the clearly labelled identity-verification demo.
7. Identify the AI Assistant entry and explain the current prototype boundary; demonstrate the assistant panel only if it exists in the linked Figma prototype.
8. Summarize the design-review findings in Section 8 and distinguish visual prototype evidence from working backend features.

The classroom requirement calls for clicking and navigating in the actual prototype, not simply reading screenshots from the slides. Controls should be tested in the presentation browser before demonstration. The provided static screenshot set does not by itself certify those actions.

11. Conclusion

MIN-roamer's fourth-assignment prototype provides a coherent visual direction for a travel-planning and social platform centered on Fuzhou. The supplied designs cover destination exploration, attraction and food discovery, seven-day weather presentation, transit information, review and guide content, day-based trip planning with a map, expense overview, community publishing, user profile and a simulated identity-verification form.

Compared with the earlier requirements-analysis work, the value of this stage is the concrete expression of navigation structure, information hierarchy, page composition and proposed user interactions. The prototype also exposes review issues—route ordering, financial sample consistency and publishing permissions—that are easier to address before implementation.

The AI assistant is visible as a trip-page entry, but its dedicated panel and verified interaction have not been supplied in this set of screenshots. Similarly, static screenshots do not prove that all displayed buttons, filters and persistence operations work. The project now has a named Figma prototype and a complete team contribution allocation. The remaining delivery dependency is the separate Assignment 4 presentation URL and classroom verification of clickable interactions. The design issues should remain transparently documented until a revised state is evidenced.