Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC 30122 — Voice Commands for User Interfaces
Information Technology — User Interfaces — Voice Commands
🎙️ The BS ISO/IEC 30122 series provides an internationally harmonised design and specification framework for voice commands in user interfaces, adopted identically in the UK from ISO/IEC 30122. As voice assistants, voice input, and accessible voice control become widespread, the usability, consistency, and cross-language localisation of voice commands are now key factors in user experience and ICT accessibility. BSI Technical Committee ICT/-/6 (ICT Accessibility) is responsible for UK participation, classified under ICS 35.240.20. This article presents the series as a whole: its structure, key requirements, and engineering practice.
💡 Good voice command design is not just about “accurate recognition” — commands must be speakable, understandable, and predictable. ISO/IEC 30122 provides a consistent quality baseline from framework, through construction and testing, to localisation.
1. Series Overview 📌
The ISO/IEC 30122 series is organised around “framework — construction and testing — localisation — management”, with each part addressing a different stage of the voice command lifecycle:
| Part | Edition | Subject | Main Content |
|---|---|---|---|
| BS ISO/IEC 30122-1 | 2016 | Part 1: Framework and general guidance | Defines the overall framework, terminology, and general requirements/recommendations for voice commands. |
| BS ISO/IEC 30122-2 | 2017 | Part 2: Constructing and testing | Specifies the phonetics of command phrases, construction methods, and testing requirements to ensure commands are recognisable and predictable. |
| BS ISO/IEC 30122-3 | 2017 | Part 3: Translation and localization | Provides guidance for translating and localising voice commands, addressing cross-language and cross-cultural adaptation. |
| BS ISO/IEC 30122-4 | 2016 | Part 4: Voice command management | Addresses registration, management, and maintenance mechanisms for voice commands (scan version; written from public domain knowledge). |
⚠️ Part 4 (30122-4:2016) is a scan-only file in the source material; its content is summarised from public domain knowledge. Always refer to the official BSI published version.
2. Framework and General Requirements 🧩
Part 1 (Framework and general guidance) defines user scenarios and quality dimensions for voice commands, covering general requirements and recommendations such as understandability, memorability, consistency, feedback, and error tolerance. The framework emphasises that voice commands should be designed as user interface elements: beyond technical metrics such as recognition accuracy, one must consider how naturally users speak the command, how the system responds, and how errors are recovered.
Part 2 (Constructing and testing) focuses on the phonetics of command phrases, specifying phonetic composition, distinguishability, and test methods. For example, command phrases should avoid words that sound alike and are easily confused, reducing speech recognition ambiguity; usability tests should verify command performance in real noisy environments and with different accents.
| Design Dimension | Focus | Typical Requirement |
|---|---|---|
| Understandability | Users grasp the meaning | Use natural language familiar to users |
| Memorability | Users can remember commands | Short, intuitive phrases; avoid excessive length |
| Consistency | Same operation, same wording | Unified terminology and phrasing; avoid multiple words for one meaning |
| Distinguishability | Commands are not confused | Avoid phonetically similar words; control homophones |
| Feedback and error tolerance | Response when recognition fails | Clear prompts, cancellable, retryable |
3. Localisation and Translation Requirements 🌍
Part 3 (Translation and localization) addresses the cross-language use of voice commands. Unlike text translation, voice command localisation must simultaneously consider phonetics, grammar, cultural conventions, and usability: direct transliteration or word-for-word translation often produces commands that are hard to pronounce or unnatural in the target language. This part provides a localisation process and quality requirements, including semantic equivalence, natural pronunciation, length constraints, and test verification of localised commands, ensuring localised commands remain usable and predictable in the target language environment.
🚨 Voice command localisation cannot be “machine translation”. Pronunciation, length, ambiguity, and cultural acceptability must be redesigned and verified in the target language — otherwise you get commands that are “recognisable but not speakable or not understandable” by users.
4. Engineering Practice 🛠️
- 🗣️ Voice interaction design: when designing voice assistants, in-vehicle voice, and smart home voice commands, follow the framework to design command sets that are understandable, memorable, and distinguishable.
- ♿ Accessibility support: provide reliable voice control entry points for users with motor or visual impairments, fulfilling ICT accessibility requirements.
- 🧪 Usability testing: per Part 2, test recognition accuracy and user success rates under real noise and accents, iterating on the design.
- 🌐 Multilingual products: use Part 3 to localise multilingual voice commands systematically, reducing inconsistent command behaviour across languages.
- 📋 Command asset management: maintain command inventories, versions, and registration data through Part 4 mechanisms to support product iteration.
5. Frequently Asked Questions ❓
❓ Q: How does ISO/IEC 30122 differ from speech recognition technology standards?
A: ISO/IEC 30122 concerns the user-interface level of voice commands — how to design, construct, test, and localise them; the technical performance of recognition engines belongs to speech processing and language resource domains. They operate at different layers and complement each other.
A: ISO/IEC 30122 concerns the user-interface level of voice commands — how to design, construct, test, and localise them; the technical performance of recognition engines belongs to speech processing and language resource domains. They operate at different layers and complement each other.
❓ Q: Why should voice commands avoid phonetically similar words?
A: Speech recognition easily confuses phonetically similar words under noise and accent variation. If a command set contains homophones or near-homophones, recognition accuracy drops and misoperations occur; distinguishability must therefore be ensured by design.
A: Speech recognition easily confuses phonetically similar words under noise and accent variation. If a command set contains homophones or near-homophones, recognition accuracy drops and misoperations occur; distinguishability must therefore be ensured by design.
❓ Q: Who are the primary users of this series?
A: On one hand, ordinary users’ usability needs when using voice interaction products; on the other hand, accessibility needs — providing alternative interaction entry points for people who cannot or find it difficult to use touch, keyboards, and similar methods.
A: On one hand, ordinary users’ usability needs when using voice interaction products; on the other hand, accessibility needs — providing alternative interaction entry points for people who cannot or find it difficult to use touch, keyboards, and similar methods.
❓ Q: How does voice command localisation differ from ordinary text localisation?
A: Text localisation mainly ensures semantic equivalence; voice command localisation must additionally satisfy natural pronunciation, suitable length, unambiguity, and cultural acceptability, and be verified at the speech level — it involves more constraints than text localisation.
A: Text localisation mainly ensures semantic equivalence; voice command localisation must additionally satisfy natural pronunciation, suitable length, unambiguity, and cultural acceptability, and be verified at the speech level — it involves more constraints than text localisation.