Skip to main content

Student

:::tip Use this page when You are documenting the role with the most day-to-day workflow activity: proposals, submissions, milestones, and defense preparation. :::

The student role is the most workflow-heavy day-to-day experience. This is where proposals, documents, milestones, and defense preparation become visible as a guided academic journey.

Why this role is the most visible

If most staff roles see the platform as a control system, students see it as the academic journey itself.

This role touches the largest number of workflow surfaces across the product. In practice, students experience proposal creation, milestone submission, feedback loops, revision cycles, progress tracking, and defense readiness as one connected path rather than as separate administrative steps.

Fastest route through this guide

  1. Read Landing area to see the student workspace.
  2. Read First actions after invitation acceptance for the first user journey.
  3. Read Core responsibilities to understand what students actually need to do, not just where they click.
  4. Read Operational checkpoints if you want the recurring progress loop.
  5. Continue to Project lifecycle if you want the full operating path.

Landing area

  • Dashboard: /dashboard/student
  • Key sections: my-project, team, submissions, milestones, upload-documents, defense, timeline, messages, announcements

First actions after invitation acceptance

  1. Change the temporary password on first login.
  2. Open the project workspace and confirm team context.
  3. Review the timeline and milestone expectations.
  4. Upload required documents and submissions.
  5. Track defense readiness and communications.

Core responsibilities

The student role is not only about uploading files. It is the role that converts platform workflow into academic progress.

Project and proposal ownership

  • understand whether the group is still in proposal mode or already operating as an approved project
  • keep the project context, team context, and required deliverables visible
  • follow the department-defined sequence instead of skipping ahead to later work
  • respond correctly when a proposal or milestone is sent back for revision

Submission and revision work

  • upload proposal, milestone, and supporting files at the correct stage
  • monitor whether a submission is still awaiting review or has already received feedback
  • revise using actual advisor or staff feedback rather than uploading another version blindly
  • track which milestone is open now and which next step is still locked

Late-stage readiness

  • monitor project progress as defense approaches
  • prepare final materials, checklists, and required readiness items
  • follow defense schedule details carefully
  • stay responsive to late-stage communications and readiness gaps

What the dashboard is designed for

The student workspace includes:

  • project progress visibility
  • milestone completion tracking
  • document and deliverable submission
  • defense preparation surfaces
  • grade or concern-related actions where available

Operational checkpoints

Students usually experience the platform as a repeating progress loop, not a single one-time submission flow.

Checkpoint 1: Current stage clarity

The first question is always whether the student understands the current academic stage correctly.

Questions to answer:

  • is the group still preparing a proposal, waiting on review, or already operating inside milestone delivery
  • which milestone or submission is active right now
  • is the next action upload, wait, revise, or prepare for defense

Checkpoint 2: Submission quality

The platform works better when students treat each upload as a meaningful academic deliverable rather than a checkbox.

Questions to answer:

  • does the current submission actually match the requested deliverable
  • has the group uploaded the right file for the right stage
  • are there missing materials that will likely trigger preventable feedback

Checkpoint 3: Feedback response

Student progress often stalls not because work is impossible, but because feedback is not interpreted well enough.

Questions to answer:

  • has the group read the latest feedback carefully
  • is the next resubmission actually addressing the advisor's concerns
  • is the group stuck in a repeated revision loop that needs clearer guidance

Checkpoint 4: Readiness for the next stage

Each stage should prepare the student for the next one, not only complete the current one.

Questions to answer:

  • is this milestone strong enough to support later evaluation work
  • is project progress healthy enough for late-stage review
  • are defense readiness tasks being handled before the schedule becomes urgent

Practical handoff model

The student role moves through a series of supervision and review relationships.

PhasePrimary student jobTypical handoff
Proposal stageprepare and submit the project idea correctlycoordinators and department heads review and decide
Milestone deliveryupload work, respond to feedback, and improve the projectadvisors review, guide, and approve progress
Evaluation preparationmaintain project quality and readinessevaluators take over formal scoring responsibility
Defense stageprepare materials and appear ready for the scheduled sessionstaff and evaluators manage the formal session workflow

What success looks like

Students are using the platform well when the project reaches this state:

  • the team always knows which stage it is in and what comes next
  • submissions and resubmissions reflect actual feedback, not guesswork
  • milestone progression stays aligned with the department sequence
  • late-stage readiness work starts before the defense window becomes rushed
  • the platform feels like a guided journey instead of a confusing set of disconnected pages

Product snapshot

Student dashboard placeholder

Onboarding note

Student onboarding only starts after the department head has invited the user and the invitation has been accepted. Unlike the department head, students do not create the environment. They enter an environment that should already be configured.

Common mistakes to avoid in the docs

  • Do not describe the student role as only a file-upload role. It is the main workflow experience of the platform.
  • Do not treat proposal, milestone, and defense work as unrelated pages. Students experience them as one connected journey.
  • Do not imply students control staffing, approvals, or evaluator assignment. Those remain staff-owned operations.
  • Do not present revision as failure only. Revision is a normal academic loop in the platform and should be documented that way.

Best page after this one

If you want to do next...Go hereWhy
Understand the full student operating pathProject lifecycleIt shows how proposals, milestones, and evaluation connect.
Understand proposal-stage expectationsProposal review and approvalIt explains the first major decision gate affecting students.
Understand milestone and submission workMilestone delivery and advisor reviewIt covers the repeated submission-feedback cycle students experience.

Best next reads