Project Brief Template

Submit your first version via LMO Turnitin by Friday March 27, 2026, 23:59 Beijing Time (same deadline for all sessions). You can update it any time until April 10 — after that it is locked. The graded version is the one you resubmit in your Week 11 Portfolio (worth 5%). The March 27 submission is a check-in, not a grade.

This page gives you the template, guidance, word counts, and examples for each section. For context on why you’re writing it and how to choose your project, see the Week 3 Guide.

---

Formatting Requirements

Requirement	Specification
Length	2 pages maximum
Font	Times New Roman or Calibri, 12pt
Line spacing	1.5
Margins	Standard (2.54 cm), justified
Referencing	APA 7th edition if external sources are cited
File format	Word document (.docx)
Filename	Session[X]Group[Y]_ProjectBrief.docx
Submission	LMO Turnitin, one submission per team — uploaded by group leader

Cover page

Include the cover page provided on LMO as the first page of your document. It must show your group number and all student IDs.

---

Section 1 — The Problem

Guiding question: Why does this matter? Who is affected, and how often?

Describe the problem in plain language. Do not mention your product or solution in this section. Focus entirely on the situation that exists today and why it is a problem.

What to include:

• Who experiences this problem (be specific — not “everyone”, but a type of person in a concrete situation)
• How they currently deal with it (their workaround)
• Why the current workaround is not good enough

Suggested length: 100–150 words

Example — Problem

“Second-year students in shared university accommodation frequently encounter disagreements over shared household expenses. When one person pays for groceries, utilities, or cleaning supplies, there is no agreed system to track what others owe. Most groups use WeChat transfer or a shared notes app, which requires one person to act as an informal accountant — a role no one wants and everyone disputes. The problem escalates in apartments of 6–8 people where trust is still developing and social conflict is high-cost. Existing expense apps like Splitwise exist but require everyone to download and use the same app, which groups rarely maintain beyond the first week.”

---

Section 2 — Target Users

Guiding question: Who exactly are you building for?

Describe your primary user as a real type of person — not a demographic category like “18–25 year olds”. Give enough detail that someone reading the document could picture who you mean.

What to include:

• A brief persona: who they are, what they do, what they care about
• Why they would want your product (their motivation)
• (Optional) Why they do not already use an existing solution

Suggested length: 60–100 words

Example — Target Users

“Our primary user is an international student in their second or third year of study, living in shared accommodation of 5–8 people. They are socially motivated but conflict-averse — they want fairness in shared costs but avoid direct confrontations about money. They use WeChat daily but have never consistently used a dedicated expense app. A secondary user is the team’s informal ‘treasurer’ — the person who usually pays first and chases others — who is most motivated by anything that reduces the administrative burden.”

---

Section 3 — The Solution

Guiding question: What are you building, and what does it do for the user?

Describe your product in one paragraph. Write from the user’s perspective — what they experience — not from a technical perspective. Save architecture and technology choices for your Technical Documentation (Week 11).

What to include:

• What the product is (one sentence)
• The core feature — the main thing users will do
• How it solves the problem you described in Section 1

Suggested length: 100–150 words

Do not include: technology stack, database choice, API details, or implementation approach. Those belong elsewhere.

Example — Solution

“We are building a mobile app that lets shared households track and split expenses without any single person acting as the accountant. Users add a shared expense in under 10 seconds by entering the amount, selecting who is involved, and confirming — the app automatically calculates balances. At the end of each week, every member sees exactly what they owe or are owed, and can settle with a single tap. The core feature is fast expense entry: we deliberately removed every optional field and configuration so that the barrier to adding an expense is lower than sending a WeChat message.”

Key Features (optional, recommended)

List 3–5 features you plan to build. Use plain language. One line each.

This is not a commitment — it is a starting point. You will refine and prioritise the list as you build.

Example:

• Users can add a shared expense in under 10 seconds
• App shows each person’s running balance at a glance
• Users can mark a balance as settled with one tap
• Optional: weekly summary notification via WeChat

Suggested length: 3–5 bullet points

---

Section 4 — Success Metrics

Guiding question: How will you know if your product is actually working?

List 3–5 specific, measurable outcomes. These are your criteria for success — they should be things you can actually test or observe during your user testing sessions.

What to include:

• At least one metric about usability (can users do the core task?)
• At least one metric about adoption or engagement (do users keep using it?)
• At least one metric you can realistically measure in your testing sessions

Suggested length: 50–100 words (bullet list is appropriate)

Example — Success Metrics

- Users can add a shared expense in under 30 seconds without reading any instructions - 80% of test users describe the balance summary as “clear” or “easy to understand” when asked - At least 5 members of one real household use the app for a full week without being prompted - Zero instances of “I didn’t know I owed that” in a two-week household trial - The informal “treasurer” reports less time spent on expense tracking after 2 weeks of use

---

Development Log Link

Add your Dev Log link here before submitting. This is how your pathfinder accesses your weekly updates throughout the semester.

Development Log (SharePoint): [paste your link here]

Make sure sharing is set to “Anyone at XJTLU with the link can view and comment” before you paste the link. Your pathfinder cannot open it otherwise.

Why this goes in the brief

Submitting the link inside the Project Brief creates a permanent record from day one. Your pathfinder receives it automatically when reviewing the brief — no separate message needed.

---

Before You Submit

Checklist before submitting

• Cover page included (from LMO template) with group number and all student IDs
• Section 1 describes the problem, not the solution — no mention of your product
• Section 2 describes a specific type of person, not a vague demographic
• Section 3 starts with “We are building…” and describes the user experience, not the tech
• Section 4 has 3–5 metrics that are specific and measurable (not “users will like it”)
• Document is 2 pages or fewer, Times New Roman or Calibri 12pt, 1.5 line spacing
• Filename is Session[X]Group[Y]_ProjectBrief.docx
• All team members have reviewed and agreed on the content
• Dev Log link included — sharing set to “Anyone at XJTLU with the link can view and comment”
• Submitted via LMO Turnitin by group leader before Friday March 27, 2026, 23:59 Beijing Time

---

AI Use Policy

You may use AI tools to draft and improve your brief — this is encouraged. The requirement is that the strategic thinking (problem identification, user insight, success criteria) comes from your team’s own research and discussion, not from AI alone.

A useful approach: draft your own rough version first, then ask AI to improve the language and identify gaps.

Effective prompt for brief writing

“I am writing a 2-page product brief for a student project. Here is my rough problem statement: [paste your draft]. Improve the language to make it more precise and professional. Then ask me 3 questions that would make the brief stronger.”