3.1.2 - Formative project skills: stakeholder needs
A solution can function correctly and still fail the people who need it. You will practise identifying stakeholders, finding evidence of their needs and explaining why particular solution choices fit those needs. All examples and activities are formative project-skills practice, rather than assessed H446/03 candidate work.
Identify people with different interests
A stakeholder is an individual or group with an interest in a solution, whether or not they directly operate it.
An end user interacts with the solution. Other stakeholders may commission it, maintain it, rely on its outputs or be affected by its decisions. Identifying a role is not enough: describe what that role does and why the proposed change matters to it.
In a fictional bicycle-repair booking service, a receptionist records appointments, a mechanic uses the job list and a customer relies on the promised appointment. The receptionist needs to see available slots while entering a booking. The mechanic needs clear job details before work begins. Customers may not use the software at all, yet incorrect appointment information still affects them. A maintainer may need a way to recover backed-up records. These are distinct interests, not four interchangeable copies of “needs an easy system”.
Stakeholders can be described as named individuals, groups or a persona representing the target end user. A useful persona combines relevant characteristics: for example, a part-time reception volunteer who has little training and often serves customers while entering details. Those characteristics explain interface needs. Invented personal details that change no design decision add little. Make clear whether a persona is based on research or is a provisional assumption to investigate; it is not evidence that a real interview occurred.
OCR does not require a real customer to sign off every stage, and interviews are not mandatory. A target audience can be valid. Nevertheless, the needs and appropriateness of the solution require reasoning. “I am the only user” is not a reason to leave that analysis out; describe your role and investigate the task honestly.
Investigate the task before choosing features
A need is an outcome or constraint important to a stakeholder; a suggested feature is one possible way to address it.
“Give us a red button” is a suggestion. “We need to distinguish urgent jobs without reading every note” is a need that explains the suggestion. Investigating the underlying task allows other suitable choices, such as an explicit urgency label and filter. Colour alone may be insufficient for users who cannot distinguish it.
Use a research method that can answer the question. Observation can reveal actual sequences and interruptions; an interview can explore reasons and exceptional cases; a questionnaire can gather responses from a wider group; existing records can reveal recurring errors or demand. No one method is automatically required or sufficient. A small convenience sample cannot prove that every potential user shares its preferences.
For the fictional repair service, an observation notes that the receptionist switches between a paper diary and a separate job sheet. A follow-up question asks, “What happens when an appointment changes?” rather than “Would a new app make changes easier?” The first invites a description of the problem; the second pushes a desired conclusion. The receptionist explains that the job sheet is sometimes left unchanged. This supports a need for one consistent appointment record, rather than simply a request for a fashionable interface.
Keep observation, interpretation and assumption distinguishable. “Two observed changes left the job sheet inconsistent” is evidence about those cases. “Changes may be a source of mismatches” is an interpretation. “Every volunteer has a laptop” is an assumption until checked. Conflicting information should prompt follow-up, not removal of inconvenient responses. Collect only appropriate information and report research truthfully; fictional lesson evidence must never be presented as a learner's actual consultation.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account