Chapter 7. Interviewing
THE INTERVIEW STAGE SHOULD give you a good feel for what’s possible, and for the overall scope of the project. After this, you should be prepared for an audit of what’s already been built, and of expectations for the product. Performing this quick review of the problem space is essential for discovering a project’s constraints and time frame. From hardware, frequency range, and tone to schedule, scope, and user experience, each aspect of the project needs to be fully investigated.
Share knowledge, ask questions, and manage expectations. By identifying and clustering the problems that need to be solved through the removal or addition of sound, you’ll find that the nature of the design space as a whole starts to take shape.
If the product is new or if you’re working with a startup, not all of the interviewing process covered in this chapter will be applicable, but it should still be a useful guide to direct your work.
Interviewing Stakeholders
If you are creating interfaces for a product or service, you are obligated to find out what kinds of sounds it makes or will make. You will need to investigate and go deep. If you are not an engineer for the project, talk to someone who is and find out what they know. Take stock of the things you can influence, as well those you cannot, bearing in mind that other brands or corporate entities might be playing sounds through your device as well. In the end, sound for interfaces deserves at least as much scrutiny as its visual and interactive counterparts.
You’ll want to do interviews within the organization to see what’s needed. You’ll also want to do preliminary user studies. Together, these will give you enough information to create a deliverables document to use as the basis for product development.
Communication between groups is essential. A good interview feels like a conversation, and can be a powerful tool for creating shared expectations. Solicit not just the facts, but the dream as well. Have people tell you what their vision would sound like if money were no object. You may discover new use cases or get new ideas from your counterparts. Even if interviewees are uncommunicative, this alerts you to possible friction in getting buy-in from them or their team.
Not everyone in the room will share a background in audio or have time to understand audio-specific terminology. If they don’t have a vocabulary with which to describe sound, they might be cautious or defensive when discussing it. Communicate and define the terms that you’ll use, and let them do the rest. Use the definitions at the beginning of this book to help expand participants’ vocabulary.
Determining the Scope of Work
Design projects can vary widely in terms of scope. You will find that your deliverables will fit into one of the following categories:
- A single design
This is usually something like a sound trademark (see Chapter 5) or a single audio branding element such as a startup sound or alarm. This isn’t necessarily limited to additive sound design. You might be asked to take an existing design and make it fit the experience better. In some cases you might discover that a subtractive approach is best, as described shortly.
Working on a single design can be extremely rewarding. Not only do you get a chance to hone your skills, but these are also opportunities to try out new design ideas. Your experiments might not get selected for further development, but testing ideas within the initial client review can help you discover what processes are worth spending your time developing.
- A comprehensive auditory experience for a product
- This is the complete auditory experience or sound design for a product. It includes all interactions with the device.
- A comprehensive auditory experience for an environment
- Comprehensive designs for exhibits, hospitals, and other environments are highly satisfying. They are an order of magnitude more complex than single designs or designs for projects. This isn’t for technical reasons, but because you’ll be working with a wide range of people with their own agendas and concerns.
- A family of auditory experiences
- This is when you are designing sound for a range of products—for example, all the different microwave ovens from a manufacturer, or all the human–machine interfaces (HMIs) for an automotive manufacturer. These projects need a core team of at least two people, with one devoted exclusively to communication.
There are many different versions of this problem. However, they have one thing in common you can’t afford to ignore: you need to break up the problem into manageable pieces and commit to calling each of those pieces “done” as soon as you can. Instead of building something that you can’t test until after you have spent a lot of time and budget, distribute your risk by working on short, achievable goals. Then if something goes haywire, the sunk costs are low.
- Subtractive deliverables
- A noisy electromechanical experience, such as a blender or vehicle, might come with requirements for specific decibel levels or an overall reduction in unwanted noise, and an annoying set of sounds may come with recommendations for simplification and reduction. For mechanical cases, you’ll need to work with a larger team of engineers and materials scientists to determine how to cancel, remove, or improve existing sounds within the constraints of an existing or new product. For a user interface, subtracting audio components may be as simple as lowering the volume or trading audio for visual notifications or haptics.
Interview Questions
When you first meet with stakeholders, you’ll need to get as much information as you can. Try to get answers to the more general questions before you write your proposal. Even if you receive a detailed request for proposal, it’s helpful to ask some clarifying questions.
Interview internal partners, clients, and suppliers. This is also the stage where you will discover other people related to the project who are excited about the auditory experience of their product.
Stakeholder Questions
- What decisions do you need run by you?
- How much information and detail would you ideally like to receive about the process?
- Who else needs to be involved?
- What are your aspirations for the project?
- What do you want it to “feel” like?
- What would you want to create if money were no object?
- How quickly does the product need to go to market?
Technology Limitations and Specifications
- If the product is software-based, will it be expected to operate on a variety of platforms? What kind of playout hardware will be used on each platform?
- What sample rates and bit depths does it support? Remember that you’ll want to design sounds that work well at different sample rates.
[ TIP ]
For more about working within hardware limitations, see Chapter 10.
- Does the product support stereo or mono playout? If the audio is mono, and you’ve mixed it for left and right channels, you might have phase cancellation when it plays back as mono. To avoid this, test with and design for the target hardware.
- What kind of physical interface does the product use? Is it a touchscreen? If so, is it capacitive or resistive? Capacitive touchscreens are more responsive than resistive touchscreens; resistive touchscreens may need to be tested for adequate response time during frequent interaction.
- Will the sounds be prerecorded, or will they be generated in real time?
- Does the product have the capability to use haptics and not just sounds?
- Does the product have a machine-listening component? If so, is there a privacy policy in place for data usage? Is there a hard “off” switch for the machine-listening component? What happens in the case of a hardware exploit?
Materials
- What materials are being used in the product?
- How might these materials influence the sound of the product?
- What inspiration can the materials lend to the sound?
Interaction Times and Triggers
- What triggers the interaction? How long are interaction times?
- Is an audio element expected with every interaction? Can the user turn the audio element off, or is it a legal requirement of the design? (Devices in the healthcare industry are one example of this requirement.)
Context
- Clarify the context and environments the product will be used in. Consider times, places, and situations beyond “ideal” scenarios. Will sounds compete with traffic or other environmental noises, or will they be used in a contained space with no interference? Will a previously stationary product be used in a mobile context?
- What time of day will the product be used? Are there times when a sound might be annoying to the user?
- What market is this product for? EU only? North America? Global? Does this market require new or existing market or demographic research? Were any previous studies done regarding sound preference for the expected user?
- How might people with different abilities use the product? Use the free, downloadable Microsoft Inclusive Design Toolkit1 to test product development assumptions, as discussed in Chapter 11.
Brand Questions
- Is this a single asset, such as a sound trademark, or a system?
- Are there guidelines for the use of sound and brand? Clarify the scope of the deliverables and their association with brand guidelines.
- Will the “on” sound be used as a sound trademark?
- What, if any, are the current identifiers of the brand? How does this product reflect those brand identifiers?
- What existing sound identity or information systems (if any) will the sound trademark live with?
- How is the product positioned (e.g., entry-level, for kids, professional, medical)? How will the product soundscape reflect this positioning?
Competitive Landscape
- What does the competitive landscape of the brand look like? Who uses sounds, and why? Are the sounds loved or hated?
- Does the competition have a product that uses sound as part of its branding strategy? Does the sound associated with the product reflect the brand?
- Do your competitors use too much sound, or sounds that are too loud or too long?
- Does the sound fit the interaction or use case? What are your competitors doing exceptionally well, and what can be learned from these concepts? Where do they lack, and what can be learned there?
Conclusion
Interviewing is important for understanding what’s possible in a project. It should help you understand who is responsible for different aspects, and who you might need to work closely with during the design phase. What you learn during the interview process can prevent unknown surprises linked to the overall scope, pricing, and duration of the project.
Interviews should feel like conversations. Your delivery type may be a single design, an entire experience for a product, or a family of auditory experiences. In some cases, you might find that the product needs subtractive sound design for mechanical noise, which could require the aid of a mechanical engineer. Interviews set your work up for the next step of the process, which is design.
In the next chapter, you’ll learn how to apply what you learned in the interviews to designing a successful product.
1 Albert Shum et al., “Inclusive Microsoft Design,” http://bit.ly/2CrYBgu