← VCE Software Development U3O2

Brief feature: proposed users

The people a brief names as expected to use the software, with their skills and needs, so the design can suit them.

Understanding Brief feature: proposed users in VCE Software Development U3O2

What it does: Naming the main group of people who will use the software is the core of the proposed users section. The users' skills and needs are recorded in the brief so the design can suit them, such as keeping screens simple. Proposed users describe the intended audience. Feasibility covers whether the project is achievable.

Common mistakes: Proposed users are the people who will use the finished software, not the developers who build it. The line should name the group, e.g. Year 7 students. A user group description says who the users are (age, role). A budget is an economic constraint, not a description of users. It should read like 'Group: staff aged 25 to 60'.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

This module's key terms are also in a printable crossword (Modules 2–11) and word search (Modules 2–24).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
What does the 'proposed users' feature of a software development brief identify?
The people expected to use the softwareThe programmers who will write the code
Matches
Proposed users: Everyone in the world
↓
Too vague. A brief should name specific expected users, not everyone, so the design cannot suit anyone in particular.
Applying
Meanings
Term
proposed users
Meaning
The people a brief names as expected to use the software, with their skills and needs, so the design can suit them.
Practice
Proposed users
Testing
Gaps
users: Year 7 students aged 12-13
Check Answer
Spots
1Primary users: the dev team
2Age: 12 to 13 years

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Seahorse' badge — Range Rider, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Quick Questions

1. What does the 'proposed users' feature of a software development brief identify?
A. The people expected to use the software ✓
B. The programmers who will write the code
Proposed users are the people the brief names as expected to use the software, so the design can suit them.
2. Why does a brief describe its proposed users?
A. So the project can avoid a Gantt chart
B. So the design can suit their skills and needs ✓
Knowing who will use the software lets designers match the interface and features to those users.
3. A brief says: 'Primary users are Year 7 students using the app at school.' What is this an example of?
A. Naming the primary users ✓
B. Listing a legal constraint
Primary users are the main people who will use the software directly, such as Year 7 students.
4. Which is a good user group description in a brief?
A. Some people who might like the software
B. Retail staff aged 18-60 with basic computer skills who need fast checkout ✓
A useful description gives details of the group, such as age range, skills and needs. A vague description cannot guide design.
5. Which detail belongs under 'skills and needs of users'?
A. Users have limited technical skills and need large, clear buttons ✓
B. The solution will be built in Python
Skills and needs describe the users' abilities and what they require. The programming language belongs to a different brief feature.

Match the Pairs

Proposed users: Year 7 students at a primary school → Names the primary users, the main group expected to use the software
Users: Staff aged 50+, basic computer skills, need large text → Describes the user group, including their skills and needs
A brief names the primary users so the developer knows who the design is mainly for → Primary users: Customers who order meals on a phone app
Skills and needs of users shape design choices, such as a simple layout for beginners → Users: Beginners with low IT skills -> simple screens, clear labels
Proposed users: Everyone in the world → Too vague. A brief should name specific expected users, not everyone, so the design cannot suit anyone in particular.
Proposed users: Café staff and customers → No skills or needs are given. The brief must describe what the users can do and need, such as IT skills and accessibility.

Key Term

proposed users
The people a brief names as expected to use the software, with their skills and needs, so the design can suit them.

Fill in the Blanks

1. Proposed users: Year 7 students aged 12-13
Hint: Type the word that describes users who are expected to use the software, shown before 'users' in this brief feature.
2. Primary users: students who use it daily
Hint: Type the word for the main group who use the software most directly.
3. User group description: Year 11 students
Hint: Type the word for the short written summary of who a user group is.
4. Skills: confident with phones, new to PCs
Hint: Type the label for what users can already do, such as their ability with technology.
5. Needs: large buttons and clear text
Hint: Type the label for what users require from the software so the design suits them.

Spot the Error

Question 1
A Primary users: the dev team
B Age: 12 to 13 years
C Skills: basic typing only
D Needs: big buttons, clear text
Line A — Proposed users are the people who will use the finished software, not the developers who build it. The line should name the group, e.g. Year 7 students.
Question 2
A Primary users: Receptionists
B Group: budget of $5000
C Skills: confident with email
Line B — A user group description says who the users are (age, role). A budget is an economic constraint, not a description of users. It should read like 'Group: staff aged 25 to 60'.
Question 3
A Users: Everyone in the world
B Skills: little tech experience
C Needs: large text, few menus
Line A — A brief must name a specific group of expected users so the design can suit them. 'Everyone' is too vague. It should be a defined group such as seniors aged 65 plus.
Question 4
A Primary users: Gym members
B Skills: not relevant to design
C Needs: log workouts quickly
Line B — The skills of users are a key part of the proposed users section because they shape design choices. It should state their skills, e.g. they use phones daily.
Question 5
A Primary users: Bus drivers
B Group: adults, often on shift
C Needs: a 12 month deadline
Line C — A deadline is a project constraint, not a need of the users. User needs should describe what the users require from the software, e.g. big text and one-tap input.

Student with a class code? Join your class →