Кто отвечает за звук продукта

Звук уведомления, щелчок кнопки или звук закрывающейся двери автомобиля кажутся естественной частью продукта. Но каждый такой звук кто-то придумал, спроектировал или реализовал.

При этом тот, кто решает, каким должен быть звук, не всегда сам его создаёт и добавляет в продукт. А иногда за звуковое поведение продукта вообще никто не отвечает целиком.

В разных продуктах звук появляется по-разному. В приложении может использоваться системный звук, потому что другого решения в проекте не предусмотрели. А в физическом устройстве звук может возникнуть как следствие конструкции, материалов и работы механизма.

Так кто же всё-таки отвечает за звук продукта? Чтобы ответить, сначала нужно понять, как вообще появляется звук в продукте.

Звук, который добавили, и звук, который возник из работы продукта

В 2013 году в книге Advances in Industrial Design Engineering есть глава Product Sound Design: Intentional and Consequential Sounds, в которой звуки продуктов разделяются на два типа.

Intentional sound, или намеренный звук, добавляют в продукт специально. Это может быть уведомление, сигнал ошибки, звук включения или подтверждение действия.

Consequential sound, или обусловленный звук, возникает в результате работы и устройства самого продукта. Так звучат двигатель, механизм кнопки, вентилятор или автомобильная дверь.

Обусловленный звук можно проектировать, но изменить его простой заменой аудиофайла не получится. Для этого приходится работать с материалами, геометрией, деталями, сборкой, режимом работы или акустической обработкой продукта.

Авторы предлагают рассматривать проектирование звука как отдельный процесс, который идёт параллельно разработке продукта. Он включает четыре этапа: анализ звука в контексте использования продукта, поиск концепции со звуковыми эскизами, создание работающих и звучащих прототипов и финальную настройку звука перед производством.

В приложении звук часто выбирает разработчик

Если в команде никто отдельно не отвечает за звук, его часто подключает разработчик. Он может использовать системный сигнал или добавить звук, который уже выбрали до него.

Но разработчик не обязательно решает, каким должен быть этот звук. Он может выполнить требования продуктовой команды, использовать системное значение по умолчанию или просто закрыть техническую задачу, в которой звук отдельно не обсуждался.

При этом платформа задаёт технические ограничения. Например, в iOS для уведомления можно использовать системный или собственный звук либо отправить его без звука. Если пользовательский сигнал не соответствует требованиям системы, вместо него прозвучит стандартный.

Финальный результат в любом случае зависит не только от приложения. Пользователь может отключить уведомления, изменить настройки, включить беззвучный режим или снизить громкость. Один и тот же сигнал будет по-разному восприниматься на разных устройствах и в разных условиях.

Поэтому итоговое звучание продукта не определяет один человек. Продуктовая команда задаёт сценарий, специалист проектирует и реализует решение, платформа устанавливает технические рамки, а пользователь влияет на то, прозвучит ли сигнал вообще и как именно он будет воспроизведён.

Иногда звуковые решения вообще рождаются по инициативе конкретного человека.

Показательна история Джима Рикса, создавшего один из самых узнаваемых стартовых аккордов Mac. Он записал его в домашней студии на Korg Wavestation и сам инициировал его появление в системе.

Это пример того, что формального владельца звукового решения может не быть, и тогда результат зависит от инициативы одного человека. Строить устойчивый продуктовый процесс только на такой инициативе невозможно.

В физическом продукте звук зависит от конструкции

Даже если в продукте нет динамика, его звук всё равно можно проектировать. Только для этого меняют не аудиофайл, а сам продукт.

Хороший пример — звук закрывающейся автомобильной двери. Он складывается из массы, жёсткости, геометрии, материалов, уплотнений, замка, сборки и поведения всей конструкции. Инженеры сравнивают разные варианты, измеряют их и оценивают на слух.

Поэтому звук двери не обязательно возникает случайно. Он может быть такой же характеристикой продукта, как вес, форма или усилие при закрывании.

И чем позже о нём задумались, тем дороже изменения. В видео можно заменить звуковой эффект. В приложении изменить настройки или код. В физическом продукте может потребоваться менять детали, производство и конструкцию.

Кто всё-таки выбирает звук

В разных продуктах решение о звуке принимают разные специалисты. В приложении это может быть дизайнер или разработчик, в физическом устройстве — инженер.

Само по себе это нормально. Проблема возникает, когда отдельные звуки появляются независимо друг от друга и никто не отвечает за общую логику.

В системном подходе важен не только каждый отдельный сигнал, но и то, как все звуки работают вместе: что они сообщают пользователю, в каких сценариях появляются, не противоречат ли друг другу и может ли пользователь управлять ими.

Если такой ответственности нет, звуковое поведение продукта всё равно сформируется. Только его определят системные настройки, особенности конструкции и локальные решения людей, каждый из которых закрывал свою часть проекта.

Поэтому звук становится частью продукта не тогда, когда в него добавили аудиофайл, а тогда, когда за его звуковое поведение начали отвечать как за систему.