Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25063 — Context of Use Description (CIF for Usability)
Systems and software engineering — SQuaRE — Common Industry Format for usability: Context of use description (ISO/IEC 25063:2014)
Introduction to ISO/IEC 25063
ISO/IEC 25063:2014 is part of the SQuaRE extension division and specifies the Common Industry Format (CIF) for documenting context of use descriptions. Context of use — defined as the users, tasks, equipment, and the physical and social environments in which a system is used — is foundational to human-centred design. Without a clear understanding of the context in which a product will be deployed, usability efforts are reduced to guesswork. This standard provides a structured framework for capturing, documenting, and communicating context of use information throughout the system development lifecycle, from initial concept through deployment and follow-up evaluation.
The context of use description serves as a “living repository” of information that evolves throughout the design process. It is not a one-time deliverable but a continuously refined resource that grows in detail as understanding of the user, task, and environment deepens.
Elements of a Context of Use Description
Clause 5 of ISO/IEC 25063 defines the mandatory and optional elements that constitute a complete context of use description. A detailed description must include all five core elements, while other types (initial outline, evaluation context, product description) require only subsets.
| Element | Required Content | Engineering Relevance |
|---|---|---|
| Subject (5.2) | System identification, purpose, preconditions and constraints | Establishes scope boundaries and design assumptions |
| User Population (5.3) | User groups, psychological/social characteristics, physical/sensory characteristics, demographics | Informs persona development and accessibility requirements |
| Goals and Responsibilities (5.4) | User group goals, organizational goals/policies, responsibilities | Aligns design objectives with actual user intentions |
| Tasks (5.5) | Task attributes, frequency, complexity, dependencies, task representations | Drives workflow design and interaction specification |
| Environment (5.6) | Technical/technological, social/organizational, physical environment | Determines platform requirements, constraints, and deployment conditions |
The standard emphasizes that not all characteristics need to be documented — only those judged likely to affect usability. This risk-based approach to documentation scope prevents excessive overhead while ensuring critical factors are captured. The assessment of which characteristics are likely to affect usability should be based on human factors knowledge and previous experience with similar systems.
User population description is particularly detailed in the standard, covering psychological characteristics (cognitive abilities, cultural background, language, literacy), physical and sensory characteristics (body dimensions, biomechanical capabilities, visual and auditory abilities), and demographics (age, gender, education). The standard specifically addresses accessibility by requiring inclusion of users whose characteristics are at the extremes of the normal range, ensuring that design accommodates the full spectrum of user capabilities.
A common pitfall in practice: teams often over-specify the context of use with irrelevant details (“sufficient electrical power” for office software), while under-specifying genuinely impactful characteristics. The standard explicitly warns against both under-specification and over-specification, noting that each carries distinct risks for the resulting design.
Types of Context of Use Descriptions
ISO/IEC 25063 recognizes that context of use information is needed at different levels of detail and for different purposes throughout the system lifecycle. The standard defines five primary types:
1. Initial Outline (4.2): Based on project assumptions and business case, this high-level description provides a starting point for user research. It identifies known aspects such as potential user groups and broad environmental factors. Even for innovative products where the context will change significantly, an initial outline is a useful first step.
2. Detailed Context of Use (4.3): This includes descriptions of the current context (existing or similar systems), the intended context (for the new design), the specified context (as part of user requirements), the implemented context (actual deployed system), and the deployed context (post-deployment reality). Each type serves a different purpose: the current context identifies baseline issues and opportunities, while the intended context guides design decisions.
3. Context for Evaluation (4.4): Derived from the relevant context of use type, this is tailored specifically for usability testing scenarios. It defines the specific subset of contextual factors that must be reproduced in the evaluation environment to ensure valid and generalizable results.
4. Context as Part of Product Description (4.5): Intended for acquirers and users, this describes the intended context of use to help potential customers assess suitability. The level of detail may vary — web-based descriptions can be more detailed than printed materials.
Key insight: the context of use description is not an isolated document. It feeds directly into the user needs report (ISO/IEC 25064), user requirements specification (ISO/IEC 25065), and evaluation reports (ISO/IEC 25066). Figure 2 of the standard illustrates how these CIF documents interconnect within the human-centred design process defined in ISO 9241-210.
Engineering Design Insights
From an engineering perspective, effectively implementing context of use descriptions requires attention to several key practices:
1. Persona-Driven Design: The standard explicitly endorses persona development as a technique for communicating context of use information. Personas — fictional but realistic representations of user types — serve as powerful communication tools that keep the development team focused on actual user needs rather than abstract requirements. Each persona should capture behaviour patterns, goals, skills, attitudes, and environmental context.
2. Task Analysis and Representation: The standard provides extensive guidance on task representation techniques including workflow diagrams, task sequences, user/task matrices, procedural descriptions, flowcharts, and scenarios. The choice of technique depends on the complexity of the system and the specific design questions being addressed. For complex systems, hierarchical task analysis may be necessary to decompose high-level goals into actionable design requirements.
3. Environmental Characterization: The physical, social, and technical environments are often the most overlooked elements of context of use. Temperature extremes, ambient noise, lighting conditions, vibration, and social dynamics (interruptions, team structures, supervisory practices) can dramatically affect usability. For example, call-centre software used under time pressure and performance monitoring requires very different design considerations than the same software used in a quiet office.
| Environment Type | Key Factors to Document | Design Impact |
|---|---|---|
| Technical | Hardware, software, network, mobility, assistive technologies | Platform constraints, compatibility requirements |
| Social/Organizational | Group dynamics, time pressure, interruptions, organizational culture | Error tolerance, training needs, workflow integration |
| Physical | Space, lighting, noise, temperature, vibration, location | Hardware design, display readability, input method suitability |
Frequently Asked Questions
Q1: How detailed should a context of use description be?
The standard recommends documenting only characteristics that are judged likely to affect usability. The extent of the description is a matter of professional judgment based on human factors knowledge and experience with similar systems. Both under-specification (missing critical factors) and over-specification (including irrelevant details) carry risks.
The standard recommends documenting only characteristics that are judged likely to affect usability. The extent of the description is a matter of professional judgment based on human factors knowledge and experience with similar systems. Both under-specification (missing critical factors) and over-specification (including irrelevant details) carry risks.
Q2: How does ISO/IEC 25063 relate to other CIF standards?
ISO/IEC 25063 is the first in a planned series of CIF usability information items. It provides context of use information that feeds directly into the user needs report (ISO/IEC 25064), user requirements specification (ISO/IEC 25065), and usability evaluation reports (ISO/IEC 25066). Together, these form an integrated framework for human-centred design documentation.
ISO/IEC 25063 is the first in a planned series of CIF usability information items. It provides context of use information that feeds directly into the user needs report (ISO/IEC 25064), user requirements specification (ISO/IEC 25065), and usability evaluation reports (ISO/IEC 25066). Together, these form an integrated framework for human-centred design documentation.
Q3: Can a context of use description be reused across multiple projects?
Yes, the standard explicitly notes that information about a particular context of use can be used in the development of more than one interactive system. This is particularly valuable for organizations developing product families or systems for similar deployment environments.
Yes, the standard explicitly notes that information about a particular context of use can be used in the development of more than one interactive system. This is particularly valuable for organizations developing product families or systems for similar deployment environments.
Q4: What is the difference between intended context and specified context?
The intended context represents the design target — what the team hopes to achieve. The specified context, documented as part of user requirements, defines the actual conditions under which the system is required to achieve acceptable levels of usability. Practical constraints may result in a specified context that is narrower (or broader) than the originally intended context.
The intended context represents the design target — what the team hopes to achieve. The specified context, documented as part of user requirements, defines the actual conditions under which the system is required to achieve acceptable levels of usability. Practical constraints may result in a specified context that is narrower (or broader) than the originally intended context.
📥 Standard Documents Download
No download files available yet