Defining Project Scope in HCI Design

Every interface project begins long before the first wireframe is sketched or the first line of code is written. It begins with a decision about what the project is — and, just as importantly, what it is not. In Human-Computer Interaction (HCI), where the object of design is the relationship between a person and a system, that decision carries extra weight: a vague scope does not merely produce a late project, it produces an interface that serves nobody in particular. Defining project scope is the discipline of converting an enthusiastic, fuzzy idea ("let's build an app that helps people eat better") into a bounded, testable, buildable commitment ("a mobile application that lets users with diagnosed food allergies scan packaged-food barcodes and receive a safe/unsafe verdict in under three seconds").

This topic examines scope from five angles: what scope actually is and why it protects a team; how to articulate goals that are evaluable rather than aspirational; how to document the constraints of time, technology, and team capability; how to describe the target audience with enough precision that it drives design decisions; and finally how to consolidate all of this into a formal project description that functions as the team's shared contract and reference point.

What Is Project Scope?

Project scope is the agreed boundary around a project: the set of goals it will pursue, the deliverables it will produce, and the work that will be performed to produce them. In practice scope answers four questions simultaneously — what problem are we solving, for whom, what artefacts will exist when we are finished, and what are we deliberately not doing. The fourth question is the one teams most often skip, and it is the one that does the most work.

It is useful to distinguish two related concepts. Product scope describes the features and characteristics of the thing being built — the screens, the interactions, the capabilities. Project scope describes the work required to deliver that product — the research, the prototyping, the usability testing, the documentation, the handover. A team that defines only product scope frequently forgets to allocate time for evaluation, and so ships an untested interface. In an HCI project, usability testing, persona development and iteration cycles are themselves scope items and must be named as such.

A central reason to define scope is to defend against scope creep — the gradual, often well-intentioned accumulation of features that were never budgeted for. Scope creep rarely arrives as a single dramatic demand; it arrives as a succession of small, reasonable-sounding additions. "While we're in the settings screen, could we add dark mode?" "It would only take a day to let people share results to social media." Each addition consumes design time, adds interface complexity, introduces new states to test, and quietly pushes the original goals further away. The following table distinguishes creep from legitimate change:

Scope also serves a communication function. Stakeholders — a client, a course tutor, a product owner, an external partner, the end users themselves — each arrive with a private mental model of the project. If those models are never surfaced and reconciled, they collide at the worst possible moment: the demonstration. A written scope statement forces the reconciliation to happen early, when disagreement is cheap. Consider a student team building a campus wayfinding app: the tutor expects a usability-tested prototype, one team member expects a polished production release on the app store, and the facilities manager expects integration with the live room-booking database. Those three expectations cannot all be satisfied in eight weeks; naming them in week one lets the team negotiate rather than fail.

Finally, scope must be realistic against the team's actual capacity. Realism is not pessimism — it is arithmetic. A four-person student team working ten hours each per week for ten weeks has roughly 400 person-hours, of which a substantial fraction will disappear into meetings, coordination, learning new tools, and rework. Scoping to 390 hours of "productive" design and build work guarantees failure. Experienced teams scope to around 60–70% of nominal capacity and treat the remainder as buffer. Ambition belongs in the goals; realism belongs in the deliverables list.

Identifying Project Goals

A goal is not a feature. "Add a barcode scanner" is a feature; "allow an allergy sufferer to determine in a supermarket aisle, within seconds and without reading dense ingredient text, whether a product is safe for them" is a goal. The distinction matters because goals describe the problem and the value, while features describe one possible solution. Teams that write their scope as a feature list lock themselves into the first solution they thought of; teams that write goals leave room for the design process to discover a better one.

A well-formed HCI goal has three components: the user it serves, the problem or task it addresses, and the value or outcome it delivers. A simple sentence frame makes this explicit:

Enable [specific user group]
to [accomplish a concrete task]
so that [measurable value or outcome],
verified by [evaluation method].

Applied: "Enable part-time mature students to locate and book a free study room on campus in under 60 seconds from a mobile device, so that they stop wasting time walking between buildings, verified by a timed task in moderated usability testing with six participants." Note what this version gives the team that "make a room booking app" does not: a user group to recruit for testing, a task to script, a numeric threshold to pass or fail against, and an evaluation method that itself must be scheduled into the plan.

Goals must be specific enough to evaluate. The classic SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound) apply, but HCI projects benefit from attaching explicit usability metrics to goals. Common measures include task completion rate, time on task, error rate, number of assists required, and post-task satisfaction scores (for example, a System Usability Scale score). The table below contrasts weak and strong goal statements:

Goals also function as a decision-making instrument. Design is a continuous sequence of trade-offs — speed versus discoverability, density versus clarity, automation versus user control — and in the absence of ranked goals those trade-offs are resolved by whoever argues most forcefully. With ranked goals, the argument becomes evidence-based. If the primary goal of the supermarket scanner is "a verdict within three seconds in a noisy, one-handed, time-pressured context," then an onboarding tutorial that must be dismissed on every launch is objectively wrong, and a large single-colour verdict panel objectively beats an elegant nutritional breakdown. Teams often formalise this with a MoSCoW ranking (Must have, Should have, Could have, Won't have this time) applied to features, each traced back to the goal it serves. A feature that traces to no goal is a candidate for removal.

Finally, goals should be user-centred rather than technology-centred. A recurring failure pattern in student and hobby projects is that the technology is chosen first — "we want to use augmented reality" or "we want to try a large language model" — and a user problem is reverse-engineered to justify it. The result is almost always an interface that performs a trick rather than solving a need. Grounding goals in observed human behaviour (interviews, contextual inquiry, surveys, analysis of how the task is performed today) protects against this. A useful test: for each goal, ask "whose day gets better, and how would they describe the improvement in their own words?" If the answer can only be phrased in technical terms, the goal is not yet user-centred.

Defining Constraints

Constraints are the fixed walls of the design space. Far from being obstacles to creativity, documented constraints are what make design tractable: an unconstrained problem has infinite solutions and therefore no basis for choosing among them. Constraints should be written down at the start, dated, and revisited, because an undocumented constraint invariably resurfaces later as an unpleasant surprise.

Time constraints define the overall delivery window and the milestones inside it. A single end date is insufficient; it provides no early warning. Instead the timeline should be decomposed into checkpoints with associated artefacts, so that slippage is visible weeks before the deadline. In HCI projects the schedule must explicitly reserve time for evaluation and iteration, because these are the first activities sacrificed under pressure and the ones whose loss most damages the final product. A workable ten-week structure might look like this:

Technical constraints arise from the chosen platform, the available APIs, the devices in users' hands, and the environment in which the system runs. These are deeply intertwined with HCI because platform capability determines what interactions are even possible. A mobile application can access the camera, GPS, accelerometer, haptics and push notifications, and can function offline — but it must work on a small screen, under one-handed use, with touch targets of at least roughly 44×44 points, and subject to app-store review. A web application reaches any device with a browser and updates instantly without user action, but historically has weaker access to device sensors, depends on connectivity, and must be responsive across an enormous range of viewport sizes. A desktop application offers generous screen area, precise pointer input, rich keyboard shortcuts and heavy local processing, but requires installation, platform-specific builds, and update distribution. Other technical constraints include browser or OS version floors, data-protection obligations that forbid storing certain information on device, bandwidth limits in the user's context, and integration with legacy systems whose APIs cannot be changed.

Team constraints concern the skills, availability and composition of the people doing the work. A team with strong front-end web skills and no native mobile experience faces a real cost if it commits to a Swift application: the learning curve consumes weeks that were budgeted for design. Bandwidth matters as much as skill — a team member with a part-time job and two other modules may realistically contribute six hours a week, not twenty. Other team constraints include the distribution of the team across time zones, access to licensed software or test devices, the presence (or absence) of someone able to moderate a usability session, and the "bus factor" risk when only one person understands a critical component. Honest documentation of these constraints is not an admission of weakness; it is the basis of a plan that will actually survive contact with reality.

A compact constraints register keeps all of this visible:

Documenting constraints early also performs an expectation-management function with stakeholders. A client who is told in week one that the booking API is read-only will accept a "find a room" product; the same client told in week nine will perceive a failure. The constraint did not change — only the moment of disclosure did.

Scoping the Target User Audience

"Everyone" is not an audience. An interface designed for everyone optimises for no one, because the needs of a 19-year-old computer science student and an 82-year-old first-time tablet user genuinely conflict in matters of information density, text size, terminology, error tolerance and pacing. Scoping the audience means choosing, explicitly and defensibly, whose needs will be prioritised — and, by implication, whose will not be the primary driver of design decisions this time around.

A usable audience definition covers at least three dimensions:

• Demographics and situation: age range, occupation or role, language, location, relevant physical or sensory characteristics, and any accessibility requirements. These shape typography, colour contrast, language register and localisation needs.
• Technical proficiency: familiarity with the platform's conventions, frequency of use (one-off visitor versus daily expert), tolerance for abstraction, and existing mental models drawn from tools they already use. Novices need visible affordances, generous labelling, forgiving defaults and undo; frequent experts need speed, keyboard shortcuts, batch actions and the ability to suppress hand-holding. Many real systems must serve both, which is why progressive disclosure and accelerators exist.
• Context of use: the physical and social environment in which the task is performed. Is the user seated at a desk for an hour, or standing on a cold warehouse floor wearing gloves for fifteen seconds? Is the screen viewed in bright sunlight? Are hands free? Is the user interrupted constantly? Is the task performed under emotional stress, as with a patient portal or a bereavement service? Context of use frequently constrains design more sharply than demographics do.

These dimensions are usually captured in personas — evidence-based composite characters — paired with scenarios that place the persona in a situation with a goal. For example: "Marcus, 34, a delivery driver, uses a cracked mid-range Android phone with 2GB of data a month. He checks the app one-handed while the engine runs, in bright daylight, and needs to confirm the next drop in under ten seconds." Nearly every consequential design decision for that product — contrast ratio, touch target size, payload weight, offline caching, the decision not to put critical actions at the top of the screen — follows directly from that paragraph. A persona that produces no design consequences is decoration; a persona that constrains choices is doing its job.

Audience definition also determines which features belong in scope. If research shows that the primary users of a community-garden app are volunteers who visit twice a month, then a sophisticated analytics dashboard serves nobody, while a simple "what needs doing today" list serves everyone. Features should be traceable to a documented user need; those that cannot be traced are candidates for the out-of-scope list. It is worth distinguishing primary users (whose goals drive the design), secondary users (who use the system occasionally and must not be blocked), and stakeholders who are affected but never touch the interface — a parent paying for a child's learning app, for instance, has interests that shape requirements without making them the primary user.

Crucially, the audience's device access and platform habits directly determine platform selection. This is where audience scoping and technical scoping meet. The table below illustrates how audience facts translate into platform consequences:

Defining the audience early also has an organisational benefit: it gives the team a shared referent. When a designer and a developer disagree about whether a confirmation dialogue is necessary, "would Marcus, one-handed with the engine running, thank us for this?" resolves the argument faster than opinion exchange. Over a project, this shared vision reduces the number of decisions that must be escalated and keeps the interface internally coherent rather than a patchwork of individual preferences.

Writing a Formal Project Description

The formal project description — variously called a project brief, scope statement, or design brief — is the artefact in which everything above is consolidated. Its purpose is not bureaucratic. It exists because human memory of verbal agreements is unreliable and self-serving: three weeks after a meeting, four team members will sincerely recall four different versions of what was decided. A written, dated, circulated document converts a cloud of individual assumptions into a single shared reference that can be pointed at.

A good project description is short enough to be read in one sitting — typically two to four pages for a student or small-team project — and structured so that any section can be located quickly. A dependable structure is:

• Title, version and date: version control matters, because the document will change. "v1.3, 14 March" prevents arguments conducted against different copies.
• Problem statement: two or three sentences describing the human problem that exists today, with evidence. What do people currently do, and why is it unsatisfactory?
• Project goals: the ranked, evaluable goal statements, each with its success criterion and evaluation method.
• Target audience: primary and secondary users, with a summary of demographics, proficiency and context of use, and a pointer to the personas.
• Platform decision and rationale: the chosen platform, the alternatives considered, and the reasons — tied to audience and constraints — for the choice.
• In scope: the deliverables and features the team commits to, ideally ranked (Must / Should).
• Out of scope: explicitly named exclusions, with a one-line reason for each.
• Constraints and assumptions: the constraints register, plus any assumptions being made that, if false, would change the plan.
• Success criteria: how the team and stakeholders will jointly judge the finished work.
• Milestones and responsibilities: who is doing what, by when.
• Change process: one short paragraph stating how scope changes will be requested, assessed and recorded.

The out-of-scope list is the highest-value section of the document and the one most often omitted. Stating what will not be built removes ambiguity that silence leaves open. "User accounts and login" is either in or out; if the document says nothing, the developer assumes out and the client assumes in. Exclusions should be specific and reasoned, for example:

OUT OF SCOPE (v1.0)
- Native iOS build .............. no team iOS experience; web reaches all target users
- Payment / checkout ............ no merchant account available within the timeline
- Admin content-management UI ... content edited directly in the data file for v1
- Multi-language support ........ target audience surveyed are English-speaking; defer to v2
- Real-time chat support ........ no capacity to staff it; FAQ page instead
- Offline editing ............... read-only offline cache only; sync conflicts out of scope

Equally important is recording the rationale behind key decisions, particularly platform choice. A decision recorded without its reasoning cannot be revisited intelligently: six weeks later nobody remembers whether "we chose a responsive web app" was a considered judgement or a coin toss, so the question gets reopened and re-argued. A short decision record solves this:

The description should also be used, not filed. In practice this means three habits. First, every new feature proposal is tested against the document: which goal does it serve, which constraint does it strain, and what comes out to make room for it? Second, the document is reviewed at each milestone and updated with a new version number when scope legitimately changes, so that the latest copy is always authoritative. Third, the success criteria in the document become the script for the final evaluation — if a goal said "task completion in under 60 seconds for six of eight participants," then that is precisely the test that gets run, and the result is reported honestly whether it passes or fails.

A brief worked illustration ties the whole chain together. A team identifies a problem: mature part-time students waste time hunting for free study space. The goal becomes "enable a part-time student to identify a free, bookable study room within 60 seconds on a phone." Audience research shows these students are between classes, on mobile, often with poor indoor signal, and strongly resistant to installing single-purpose apps. Constraints are a ten-week timeline, a read-only timetable API, and no native mobile skills. The platform decision therefore falls to a responsive progressive web app with offline caching. In scope: room search, availability display, filtering by building and facilities, cached last-known data. Out of scope: booking (API is read-only), accounts, notifications, multi-campus support. Success criterion: six of eight test participants complete the find-a-room task unaided in under 60 seconds, with a mean SUS score of at least 72. Every element of that chain is traceable to the one before it — which is precisely what a well-scoped project looks like.

Alignment with Learning Outcomes

• MO1: The treatment of technical constraints and of audience device access sets out the differing capabilities of mobile, web and desktop platforms — sensors, screen real estate, input precision, installation and connectivity — and shows how each is weighed against the needs and context of a defined user group, supporting direct comparison on HCI design grounds.
• MO2: The platform-decision record, the audience-to-platform mapping table and the constraints register provide the evidence base and documentation format needed to select a platform and justify that selection against stated project requirements, constraints and user research.
• MO3: The topic as a whole is the direct preparation for this outcome: it defines evaluable goals, documents time, technical and team constraints, scopes the audience, and specifies the structure, in-scope/out-of-scope content and success criteria of a formal project description.