PROCEEDINGS of the
23rd International Congress on Acoustics
9 to 13 September 2019 in Aachen, Germany

A Design Method for UI-sounds for Electrical Appliances
Sanae H. WAKE
1

Doshisha Women’s College of Liberal Arts, Japan

ABSTRACTElectric products emit a range of artificial sounds. For example, a microwave may make button feedback
sounds, play a “completion melody,” or make an “alert” sound, in normal operation. These sounds are allpart of the user-interface (UI) of a product, and are therefore called “UI-sounds.” UI-sounds should bedesigned to be functional, to clearly convey messages to users, as well as to suit a particular product. In thispaper, we consider the importance of designing UI-sounds for products, and detail a method for designingthese sounds. We discuss how it is first necessary to determine the purpose of each UI-sound. Next, sounds
should be designed logically using elements such as timbre, pitch, and on/off patterns, to express theirfunction. In addition, sounds should be designed like art or music, to improve the user experience. Since UIsounds follow an operation sequence, each sound is one component of a total UI-sound stream. This process
is demonstrated by considering the case study of a POS cash register.
Keywords: Sound Design, User Interface, UI-Sound, Electrical appliances

1. INTRODUCTION
Modern electrical appliances typically have physical buttons and/or touchscreen displays that
constitute a user interface (UI). In many cases, these appliances also employ beeps, alerts, or melodies
as UI-sounds. For example, the microwave I have uses seven UI-sounds to convey eleven messages,
including feedback from the function select and cancel buttons, a start message, a complete message,
and a message to remind the user that a function has already been completed. In spite of this prevalence,at present, UI-sounds for electrical appliances are inadequately designed.
Well-designed UI-sounds can improve a product’s usability. Such sounds can convey informationthat supports users, reducing their cognitive load, and enabling them to operate appliances efficiently
and comfortably. UI-sounds also contribute to the realization of universal designs, for instance,
enabling visually impaired people to operate different appliances. In addition, well-designed UIsounds can give users a good impression of a product, and, by extension, its manufacturer. In contrast,
poorly designed UI-sounds can irritate users, leaving them with negative impressions of a product andits manufacturer.
The process of UI-sound design broadly concerns how to use a UI-sound, and designing the sounditself. In determining how to use a UI-sound, the information conveyed by this UI-sound and the time
when the UI-sound is used are selected, decisions which are the fundamental part of the design process.
Similarly, the process of designing the sound itself is also important. Since a UI-sound is required toconvey information to users, the sound should be designed such that the function it signifies isunderstood intuitively. Finally, UI-sounds should be designed to be comfortable. The functionality ofa UI-sound can be guaranteed if these design principles are applied successfully. In this paper, I
introduce a UI-sound design method (1, 2) and a case study describing its implementation.

1

swake@dwc.doshisha.ac.jp8017

2. UI-SOUND DESIGN PROCESS

Figure 1 – An illustration of the UI-sound design process
Two kinds of UI-sounds exist: operation feedback sounds and message sounds. Our design process,illustrated in Figure 1, is applicable to both kinds of UI-sound. The process consists of five steps:“investigating the appliance,” “designing how to use UI-sounds,” “deciding the impression the UIsounds expresse,” “designing the sounds,” and “evaluation.”
Our process has been designed as a collaboration between developers of appliances and sounddesigners. Although product developers are apt to create UI-sounds themselves, it is necessary todesign sounds to convey a specific impression. To design sounds in this way, experience of design
tools and techniques is needed. Therefore, developers should defer to sound designers on the practicalaspects of sound design. In the following sections, each step of the UI-sound design process will be
explained from the developer’s and the designer’s perspective, as appropriate.

3. DEVELOPER’S PART
3.1 Investigation of the Product
Before designing UI-sounds, the target appliance should be investigated, focusing on the following
information about the appliance, and typical user behavior:(1) User interaction flows and the state of the appliance(2) Current UI-sounds and running noise(3) Purpose of the appliance and frequency of use(4) Environs of the appliances (environmental sounds and people around the appliance)
(5) Problems and needs of users with respect to the current appliance(6) Sound system, data format, and speaker quality Particular attention should be paid to user interaction flows, as the most important information
detailing a user’s control of the appliance. Sequence patterns for UI operations should be investigated,for example, in what order different buttons are pushed to produce a given response. It should be notedthat several different interaction flows may exist for a single appliance. Hence, typical operations, aswell as special/non-standard operations, should be characterized.
3.2 Designing how to use UI-sounds
In this step, the time when a UI-sound is used in the interaction flow, and the purpose of the UIsound, are decided. Here, “when” refers to which operation(s) require a feedback sound, and whichappliance state(s) require a message sound (e.g. errors). While the purpose of the sound can vary, from,for example, expressing information, assuring users about their operation of the appliance, or moregenerally, giving users and bystanders a good impression of the appliance, the reason for using thespecific UI-sound should be clear. Following this, the order in which a UI-sound is activated in theinteraction flow, as well as its frequency of occurrence, should be decided.
Next, “an explicit level” should be determined for each UI-sound, based on its purpose and8018

frequency of occurrence. Table 1 illustrates our recommendations for assigning sounds to a scale offive explicit levels. Necessary UI-sounds, such as alerts that require the user to modify their behavior
immediately, are assigned to level 5, meaning that the sound should be able to be heard in all contexts,
and leave a strong impression on listeners. In contrast, a frequently used UI-sound, such as feedback
sounds for number buttons, should be assigned to level 1, i.e., these sounds should be barely audible.
Finally, a sound list (such as the example in Table 2), which details all UI-sounds along with theirassigned feature, is generated.
Table 1 – Explicit levels for different UI-sounds

Table 2 – Example of a UI-sound list (for MFP)

3.3 Deciding the Impression that UI-sounds ProjectIn this step, the impression projected by the UI-sounds should be determined by considering
information such as the purpose of the appliance, where it will be used, the manufacturer’s corporate
identity (CI), and attributes of a typical user. Following this, a list of descriptive words, phrases,
and/or images detailing this impression (e.g., “pretty,” “high class,” “cool,” or “natural”) should becollated, to aid the sound designer in creating an appropriate sound.
In addition, the three different sound types, defined as “Beep type,” “Rich-timbre type” and“Melody type” for UI-sounds, should be considered. Beep type sounds are formed from simple timbres(like sine-waves or square-waves), and have simple rhythmic patterns and pitch patterns. Rich-timbre8019

type sounds are made using more complex timbres that are similar to the timbres of musicalinstruments, sound effects in video-game-UIs, or animation content. As inadequate attention to thesetimbres means that sounds of this kind might be perceived to be hokey or unnatural, they should beselected or designed to fit the target product’s UI. Finally, melody type sounds consist of a complex
series of pitches and timbres, typically played at the start or completion of a task.
3.4 Instructions to Sound Designer
Listed below is information a developer should share with a sound designer following completionof the first three steps of our procedure.
(a)Information about the product(b)
UI-sound list(c)
Image concept(d)Sound type(e)
Sound data format and specifications of the product’s sound system.
In addition to this information, when possible, the designer should be supplied with “an interactive
UI-prototype” of the product, such as software running on a tablet PC, which enables easy replacement
of UI-sound files to verify their effectiveness in the user interaction flow. This UI-prototype simplifies
the trial and error process for sound design, such that the quality of the UI-sounds can be improved.
Similarly, providing an opportunity to adjust and equalize UI-sounds using the product’s system, in aprocess similar to the mixing and mastering performed in music production, is recommended.
3.5 Evaluation of UI-sounds
In the final step, the effect of individual UI-sounds and/or sets of UI-sounds are evaluated. These
tests are conducted by the users of the appliance, evaluating the sounds emitted directly from it (orthe UI-prototype) in its typical environment (or a simulated noise environment), as well as people
who will be around during its normal operation. In evaluating the UI-sounds, the UI itself should also
be evaluated for factors such as ease of operation, ease of identifying information, and ease inmaintaining operation. Favorableness or harmoniousness to the environment should also be evaluated.

4. SOUND DESIGNER’S PART
4.1 Designing UI-sounds
At present, there are few dedicated UI-sound designers, with music composers and game soundcreators often fulfilling this role. In cases like this, it is important that the differences between UIsounds and music or game sounds are understood. Unfortunately, a user’s primary expectation is not
to hear a good sound, but for the product to function efficiently; the user’s aim is to operate the product,
not to listen to UI-sounds, which are to aid users in their smooth operation of these products. In spiteof this, it is possible to improve the user experience (UX) with UI-sound, as this can make users feel
good when they operate a product, or intuitively relay information to the user. UI-sound can beconsidered to be analogous to sound effects in a movie, which heighten the sense of reality in a scene
without the audience realizing this. Similarly, the aim is not that users are made conscious of the UIsound, but the usability of a product is improved by the sound.
4.2 Individual UI-sounds and Sound Stream
Each UI-sound delivers a distinct message to the user, indicating, for example, the completion ofa process, an error occurring, or button touch feedback. In addition to this, individual sounds are apiece of the product’s total UI-sound stream. The role of each sound and the sound stream desired for
the UI should both be considered during sound design, such that when pieces of UI-sound are activatedin the interaction flow during the product’s operation, they are perceived to have a musical quality.
This improves the UX, and contributes to the product establishing a distinct identity.
4.3 Evidence Based Sound Design
In creating sounds, designers should refer to evidence of the effect of these sounds on users
wherever possible, conforming to the relevant standards relating to sound generation for the particular
product field. Sounds should be designed such that their selection for a particular purpose is easily
explained.
Standards such as “ISO 24500 Ergonomics -Accessible design- Auditory signals for consumer

8020

products,” which dictates the beep patterns to be used with consumer products to convey information,
are a form of evidence to be used in sound design. Similarly, findings from the range of existing
psychoacoustic studies can also be used as evidence informing the design of UI-sounds. For example,
our previous study considered the message conveyed to the user by the musical interval between two
pitches, from which we determined that a descending major third interval conveys an “OK” message
to the user, while an ascending minor second interval conveys an “error” message (3). Other
psychoacoustic findings regarding the effects of timbre, pitch, melody, and the relationship between
sounds are introduced on our web-site (1). While such findings should be used as much as possible,
they should not be the exclusive basis for sound design. Rather, the designer should consult thesefindings in executing “artificial sound creation.”

5. CASE STUDY – POS CASH REGISTERIn this section, I discuss sound design for a POS Cash Register (4), as a case study of our process.
As self-check-out systems have become increasingly prevalent in Japan, our team decided to design
four feedback sounds for a barcode scanner: a “scan confirmation sound,” a “second scan (in a row)sound,” an “error sound,” and a “discount sound.”To design these sounds, we defined three conditions: ease of hearing, ease of distinction, and easeof message comprehension. We previously designed three different UI-sound sets to project “simple,”“ambient,” and “Halloween” impressions. In this paper, I discuss only the simple UI-sound set.
Waveforms of the resulting UI-sounds of the “simple UI-sound set” are depicted in Table 3, with thereasons and evidence for selecting these designs discussed below.
Table 3 –UI-sounds designed for a POS cash registerscore

waveform (envelope)scan confirmationsound
second scan sounderror sounddiscount sound5.1 Ease of Hearing
The ISO 24500 standard directs that “the fundamental frequency (the pitch) of auditory signals
should not be higher than 2.5 kHz.” This is because older users with age-related hearing loss havedifficulty hearing high-frequency tones. Conversely, low frequency sounds are more easily masked
by environmental noise. Therefore, the fundamental frequencies of all sounds designed for the cash
register were between 831 Hz and 1662 Hz. We selected waveforms that are similar to sine waves, asthese are easily distinguished from noise.
5.2 Ease of Distinction
To design memorable sounds that are easily distinguished from other UI-sounds, it is effective to8021

make use of differences in rhythm (sounding pattern) and timbre (5). With the sound-set for the cash
register, we designed sounds with distinct rhythms, with the exception of the scan confirmation andthe second scan sounds (discussed further below). The scan confirmation and second scan sounds wereconfigured with “one note,” the error sound was configured with “two notes,” and the discount soundis configured with “three notes” (Table 3). It should be noted that in this instance, “notes” refer torhythm units, not pitches.
The purpose of the second scan sound is to alert operators to the fact that they have scanned thesame product twice. As doing so is not always an error, we designed this sound to be similar to theusual scan confirmation sound, with a difference in pitch to attract the operator’s attention. While thescan confirmation sound consists simply of a single pitch (C#6), the second scan sound is configured
as two simultaneous pitches (a chord), with a higher pitch (G#6) included with that of the scanconfirmation sound. In addition, since both sounds are always played sequentially, the differences inpitch are easily distinguished.
5.3 Ease of Message Comprehension
Configuration of sounds to ensure their messages were understandable was performed as below:
5.3.1 Scan confirmation soundThis sound provides operators with a “feedback feeling” following a scan. It has been shown thatto realize this feeling, the attack of a sound should be short, its length should not be too long, and thesound should be played immediately after the scan (6). Therefore, we designed our scan confirmation
sound with a short attack and a duration of 0.18 s. This sound was designed with reference to thereception signal section of ISO 24500.
5.3.2 Second scan (in a row) soundAs mentioned above, we configured the second scan sound as a chord. By selecting the first pitch
to be the same as the pitch of the scan confirmation sound (C#6), we are able to convey that these twosounds are in the same category. In addition, G#6 was selected as the second (higher) pitch because it
harmonizes well with C#6, since both pitches are separated by a major fifth interval. Hence,
distinguishing between the two UI-sounds is easy because the top note of the second scan sound isdifferent from the scan confirmation sound. In addition, by configuring this sound as a “double” pitch,
we expect that users can infer that it refers to a “second scan.”5.3.3 Error soundThis sound expresses an error feeling based on the interval between two notes played sequentially.
As an ascending minor second interval is known to suggest an “error” message to users, we made the“C#6 -> D6” phrase, which is an ascending minor second interval, our error sound.
5.3.3 Discount sound
It has been shown that sounds that short melodies associated with a “message word” can remind
users of a message, even when the word is not pronounced (7). This means that melodies that are madeto fit the intonation of the message word can remind users of the message. For example, some subway
melodies in Japan have been created to be associated with the name of the terminal station. For
instance, the subway melody for the “Tsu-ru-mi-ryo-ku-chi” terminal is created with six notes whose
melody simulates the intonation of “Tsu-ru-mi-ryo-ku-chi,” informing passengers of the destination
without them having to hear the word itself. Using this effect, we created the discount sound based ona melody associated with the word “Yat-ta-ne!”, which expresses the joy of a discount.
5.4 Projecting an Impression
To maintain the simplicity of our UI-sound set (in keeping with the sound sets for typical POS cash
registers), we adopted a simple waveform that is similar to the sine-waves used on current POS cash
registers. However, we designed sound envelopes with long enough decay forms to make the sounds
feel soft. In keeping with this principle of simplicity, we used only four different pitches for all four
UI-sounds (Table 3).

6. CONCLUSIONS
Recent UIs in electrical appliances have become more complex, making the effective use of UIsounds more important. Since UI-sounds can convey information to users, to aid in their smooth
operation of an appliance, and give them a good impression of the appliance, they should be welldesigned. In this paper, a new design process for UI-sounds for electrical appliances was described,8022

and the case study of a POS cash register was introduced. It is hoped that this design method and casestudy can help developers and sound designers in the creation of UI-sounds.

ACKNOWLEDGEMENTS
The author wishes to acknowledge Ayane Takemoto and Mayu Shintani, students of Doshisha
Women’s College, and Yasumasa Yamada, a sound designer, for their help in designing the UI-sounds
for the POS cash register. One part of this work was supported by JSPS KAKENHI Grant Number JP
16K00726. And I would like to thank Editage for English language editing.

REFERENCES
1. Wake S. The guide of UI Sound Design for products for UX. http://uisound-ux.main.jp/, 2019.
2. Wake S. Design Method for User Interface Sounds Used in Appliance. Proc. of HI2015 September 2015,
Hakodate, Japan 2015. No.3122.
3. Wake S. Nishikawa S. What do people associate with a two pitch auditory signal -2. Proc. of Research
Reports on Human Interface; Vol.12, No.1, 2010.
4. Takemoto A. Shintani M. Wake S. UI-Sound Design and Evaluation for POS Cash Register. Proc. ASJ
2018 Spring Meeting 2018. 1-13-2
5. Wake S. Uwakubo S. Fukuzumi S. Asahi T. Hiroaki T. A case study on establishing an "Matrix Design
Method for Auditory Signals" for Human Interface. The IEICE Transactions on Information and Systems;
D-II Vol.J82-D-II No.10, 1999. pp.1721-1728
6. Kimura A. Oomachi H, Shibata F. Tamura H. A Study for Presentation of Tactile Sensation with Sound
Feedback to Touch Sensor. IPSJ Transactions on HCI. 2007. 20007-HCI-124, 2007.
7. Ichikawa S. Wake S. Mitsumoto M. Melody Sign Designed Based on Intonation of the Word. ASJ 2013
Spring Meeting 2013. 3-3-5.

8023