Brief feature: proposed users

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

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

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

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

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

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

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

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

Definitions

proposed users

Fill in the Blanks

Complete each line of code by filling in the missing parts.

________ users: Year 7 students aged 12-13

_______ users: students who use it daily

User group ___________: Year 11 students

______: confident with phones, new to PCs

_____: large buttons and clear text

Spot the Error

Shade in the letter of the line that contains an 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

Question 2

A Primary users: Receptionists

B Group: budget of $5000

C Skills: confident with email

Question 3

A Users: Everyone in the world

B Skills: little tech experience

C Needs: large text, few menus

Question 4

A Primary users: Gym members

B Skills: not relevant to design

C Needs: log workouts quickly

Question 5

A Primary users: Bus drivers

B Group: adults, often on shift

C Needs: a 12 month deadline

Answer Key

Brief feature: proposed users

Section A: Quick Questions

A — The people expected to use the software

B — So the design can suit their skills and needs

A — Naming the primary users

B — Retail staff aged 18-60 with basic computer skills who need fast checkout

A — Users have limited technical skills and need large, clear buttons

Section B: 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.

Section C: Definitions

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

Section D: Fill in the Blanks

Proposed users: Year 7 students aged 12-13

Primary users: students who use it daily

User group description: Year 11 students

Skills: confident with phones, new to PCs

Needs: large buttons and clear text

Section E: Spot the Error

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.

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'.

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.

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.

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.