Tongyan: A Clear Path to Joining Your First Project

Table of Contents

• 1. From Requirements to Prototype
• 2. Project Division of Labor and Team Collaboration
• 3. Interface Prototype Design Process
• 4. Prototype Results and Interactions
• 5. Key Challenges and Solutions
• 6. Team Reflections and Teammate Evaluations
• 7. Classroom Demonstration Route
• 8. Prototype Design Checklist

1. From Requirements to Prototype

Tongyan serves university students who want to participate in research, competitions, undergraduate innovation projects, and course projects. First-time participants should be able to understand the prerequisites, weekly commitment, role responsibilities, and beginner eligibility before applying. After joining a team, they can continue their work through a lightweight task board.

Our earlier survey received 66 valid responses, including 64 from first-year students. Among these 64 students, 68.8% did not know which teams accepted beginners, 85.9% most wanted to know the prerequisites before joining, and 76.6% wanted to know what to learn in advance. These findings led us to prioritize understandable requirements, useful preparation guidance, and clear application feedback.

The interface answers three successive questions: Which projects suit me? What should I prepare before joining? What happens after I apply? AI supports recommendation explanations, preparation advice, and answers with sources. Competition clubs provide participation opportunities, while experience shared by senior students supports learning paths.

Figure 1 outlines the user journey. Recommendations support decision-making; team formation requires both the project leader's review and the student's acceptance of an invitation. Generated task drafts also require user confirmation before entering the task board.

This prototype includes nine main pages and dialogs for details, sources, and related information. The online version uses sample data and local interactions to demonstrate layouts, recommendation results, and the main workflows.

2. Project Division of Labor and Team Collaboration

2.1 Tasks Organized by Group

Our 13-member team consists of one overall coordinator and six working groups. This assignment covers prototype design, business-rule checks, and documentation. Tasks are organized by group. Individual contributions are listed as 10% for the overall coordinator, 8% for each group leader, and 7% for each group member, totaling 100%.

2.2 Handovers Between Groups

We continue to communicate through Feishu. Discussions follow three questions: What does the user want to accomplish? What information does the page need? Which operations change a state? The product group explains scenarios and fields; the business group supplies state conditions; the AI and knowledge-base groups check explanations and sources; the frontend group implements them in the interface; and the testing group checks the same journeys.

A page handover specifies its entry point, required fields, operation results, failure messages, and return destination. For example, an application page needs to explain where to complete missing profile information, how to leave an expired application, and why submitting an application does not immediately make the student a team member. Changes to these rules require checks across the project library, application page, and workspace.

Documents and prototypes are checked against the same version. Project names, skill tags, and state labels are drawn from a shared list wherever possible. The frontend group's practice of explaining each newly learned feature to a teammate and saving screenshots after changes also provides a useful handover method.

2.3 Schedule and Implementation Status

The following table summarizes progress recorded in the frontend design process.

3. Interface Prototype Design Process

3.1 Tool Selection and Learning

We used MoDao as our specialized prototype design tool. Starting with canvases, components and page navigation suited our learning needs better than beginning with tools that required an understanding of masters, dynamic panels and event systems. Our goal was to create high-fidelity pages, explain the interactions, and retain a reviewable process record. The deployed website provides an accessible interactive demonstration.

The frontend group learned the tool in this order: canvas and text → alignment and guides → components and text styles → grouping and duplication → forms → navigation and state changes → dialogs → multiple selection and error states → sharing and preview. Nine learning sessions from October 18 to 26 totaled approximately 10 hours.

Each newly learned operation had to be reproducible: evenly spaced navigation, synchronized button changes, stable duplicated cards, and detail dialogs that opened and closed. This connected tool learning directly to page construction.

3.2 Shared Visual Rules

Figure 2 summarizes the visual specifications. The primary color is #2465E8. Sans-serif body text uses a 14 px size and 1.6 line height. On the 1440 px canvas, the content area extends from x=120 to x=1320. Cards have a 12 px corner radius; buttons and inputs use 8 px; borders are consistently 1 px light gray.

The rules also establish information hierarchy. Primary buttons handle the current main action, such as “View and Apply,” “Submit,” or “Publish.” Bookmarking is secondary. States use both color and text, including “Pending Review,” “Invitation Awaiting Acceptance,” and “Joined.”

3.3 Three Passes: Structure, Content, and Detail

We first established the global navigation and content boundaries, then inserted realistic titles and descriptions, and finally checked colors, spacing and states. Screenshots from each stage explain why the pages changed.

Figure 3 records the navigation framework, the hero and recommendation area, and the project, club and experience modules in the lower part of the homepage.

The project library needs more information than the homepage cards. A homepage card introduces a project; a library card helps the user decide whether to apply. The frontend group rebuilt the cards with identity, content and requirements layers, adding prerequisites, weekly commitment, vacancies, deadlines, and primary and secondary actions.

The club page prioritizes available learning support. The experience library exposes the author, version and update date directly in its list. Both help students decide whether to explore further.

3.4 Key Iterations and Reasons

4. Prototype Results and Interactions

4.1 Pages and Requirements

The table lists the nine pages from this design record and maps them to the relevant FR identifiers in the SRS.

4.2 Homepage: Express Intent and Check the Explanation

The homepage places “Find Projects” and “Ask About Experience” in one input area. Sample questions help new users get started. Conventional project, club and experience entry points remain available below for direct browsing.

Figure 7 uses local rules and sample data. After the user enters “I know Python and can spend six hours per week,” the prototype returns related projects with time-commitment explanations, prerequisites and preparation advice. “Check Role Requirements” leads the user to further details.

4.3 Projects and Applications: Requirements and State Transitions

Project details show prerequisites, responsibilities, weekly commitment, vacancies and deadlines. The application journey is “State Intent → Leader Review → Confirm Joining.” The student becomes a member after accepting an invitation.

The right-hand image in Figure 8 shows the deadline check. During the October 30 walkthrough, the sample project had already closed on October 25. The application page displayed “Currently Unavailable for Application” and offered a link to other projects.

The workflow provides specific messages and return entry points for incomplete profiles, duplicate applications and expired projects. Submission checks cover identity, project state and vacancies.

4.4 Clubs and Experience: Learning Support and Sources

The club page organizes information around prerequisites, advanced directions and learning support. It provides website, Q&A and recruitment entry points so students can inspect participation requirements.

Experience entries show their author, version and update date in the list. Articles include sources and usage information. This prototype uses one self-authored sample entry to demonstrate reading and source inspection.

4.5 Workspace and Team Collaboration: States and Next Actions

The workspace brings together applications, bookmarks, profiles and initiated projects. Application states determine the next action: a pending application can be awaited or withdrawn; an invitation requires a decision; joined members can enter their team workspace. Empty lists also provide an exit, such as “Browse Projects.”

Team collaboration uses four task columns. Submitted work enters “Awaiting Acceptance,” and the project leader accepts it or returns it for revision. AI-assisted decomposition generates task drafts. Users check the assignee, deadline and output, then select and save the drafts. Activity records show who issued invitations or changed states and when.

5. Key Challenges and Solutions

5.1 Problems Encountered by the Frontend Group

The following table records problems encountered during prototype construction and preview, along with the attempts, results and lessons learned.

5.2 Cross-Group Risks and Responses

Alongside the recorded frontend problems, the following three areas are priorities for cross-group walkthroughs and subsequent development.

6. Team Reflections and Teammate Evaluations

Figure 13 comes from the frontend process materials and shows the two frontend members discussing the interface.

The frontend record shows the two members gradually establishing a shared method. Whenever one learned a component or dialog, they demonstrated it to the other. When a discussion reached no conclusion, they tested realistic copy in the layout. After making changes, they saved screenshots.

Teammate evaluations focus on specific behavior. One member carefully checked alignment and adjusted cards even when they differed by only two or three pixels. Another passage describes a teammate listing changes and restoring a layout step by step after a section had been accidentally moved apart. These actions maintained consistency and made rework manageable. Explaining unfamiliar operations, experimenting together and finishing carefully were especially valuable in this collaboration.

The same approach applies across groups: rules need examples, references need to be inspectable, and problems need to be reproducible. Evaluations should consider clear handovers and joint problem-solving as well as written output.

7. Classroom Demonstration Route

Start from the online prototype homepage and follow a beginner finding a project and understanding the next step. Screenshots explain the design process; the classroom demonstration uses the live website.

Click through the buttons, page transitions and return paths in sequence, using sample data to explain recommendation reasons, application states and task operations.

8. Prototype Design Checklist

This iteration follows a beginner's path into a project and establishes consistent information hierarchy, state messages and entry points across nine pages, providing a clear interface reference for subsequent development.