Всё о корпусах — дизайн, прототипы, производство

Первый прототип оказался недостаточно солидным Мы разрабатывали корпус для линейки аудиооборудования TiERRA. По дизайну должно было сразу считываться, что перед нами техника высокого класса. Поэтому здесь имели значение не только форма корпуса, но и материал, обработка алюминия, графика, шрифты, расположение элементов управления и даже крепёж — по требованиям заказчика его вообще не должно было быть видно. Первый прототип сделали в цвете натурального алюминия. И уже на реальном корпусе стало понятно, что это не то. Серебристый вариант не давал нужного ощущения премиальности, поэтому второй прототип сделали чёрным — он выглядел гораздо солиднее. Сам усилитель от этого, конечно, лучше звучать не стал. Но ещё до того, как человек его включит, внешний вид уже формирует ожидания от продукта.

Мы оцениваем продукт ещё до того, как начали им пользоваться. Достаточно посмотреть на ручку инструмента, чтобы предположить, удобно ли будет его держать. На корпус оборудования — чтобы решить, кажется ли оно надёжным. На форму автомобиля — чтобы считать его мощным или быстрым. Причём реальная характеристика и то, как мы её воспринимаем, — не всегда одно и то же. Поэтому задача промышленного дизайна — не только обеспечить нужные свойства продукта, но и помочь пользователю их считать. Как это работает — показываем в видео. YouTube RuTube VK-видео

Дизайн корпуса не всегда начинается с дизайна. В проекте ЭЗС «АТТАР Солана» мы начали с компоновки. У станции четыре зарядных коннектора. Кабели длинные, тяжёлые и жёсткие — их нужно удобно вытянуть к машине, а после зарядки убрать так, чтобы они не болтались и не путались. При этом внутри станции — силовые модули и другая электроника. Нужно организовать вентиляцию, отдельно отводить горячий воздух от силовых модулей, обеспечить IP55 и IK10, оставить доступ для обслуживания — и уложить всё это в минимальные габариты по ширине. 🔺Поэтому сначала мы разбирались, как человек будет пользоваться станцией и как под эту задачу должна быть устроена конструкция. Смоделировали разные варианты расположения кабелей и в итоге разместили их на подвесах под крышей станции, добавили систему сматывания с барабаном, а коннекторы утопили в узкие панели корпуса. 🔺И только когда с компоновкой стало понятно, начали делать эскизы внешнего вида. Так сформировалась форма ЭЗС — лаконичная, технологичная и рассчитанная на интенсивную эксплуатацию в городской среде. В хорошем ТЗ много требований. Но проектировать продукт — не значит просто выполнить их все по списку. Нужно понимать, какие решения определяют, насколько продукт будет удобен в реальной эксплуатации.

В техническом задании может быть 50 требований. Но это не значит, что все 50 одинаково важны. У разных участников проекта свои интересы. Пользователю нужно, чтобы устройство было удобным. Производству — чтобы его было проще изготовить. Сборщикам — собрать. Сервису — обслуживать. Бизнесу — чтобы всё это укладывалось в экономику проекта. И довольно быстро требования начинают конфликтовать. Можно сделать корпус дешевле, но менее удобным. Упростить сборку, но усложнить обслуживание. Добавить характеристику, которая выглядит преимуществом на бумаге, но пользователю вообще не нужна. Поэтому собрать все пожелания в ТЗ недостаточно. Их нужно расставить по приоритетам. ▪️В первую очередь — требования, из-за которых продукт не купят первый раз или не купят второй. ▪️Затем — то, с чем непосредственно сталкивается пользователь: удобство, безопасность и другие важные для него свойства. После этого остальные требования проверяют относительно этих приоритетов: где можно упростить конструкцию, оптимизировать производство или снизить себестоимость, не испортив продукт для пользователя.

Видим сейчас интересный процесс — все больше задач от заказчиков формулируется с помощью нейросетей, но и с нашей стороны происходит тоже самое — все больше таких задач прогоняется через нейронку, а уже потом смотрится живым спецом. И в целом, в этом нет ничего плохого или негативного. Просто та подготовительная работа, которая раньше делалась со стороны клиента (формулирование требований, задач, результатов, вводных) сейчас делается на сильно более ранних этапах проекта и нейронкой. Фактически это означает ускорение проектов и их запуск, в среднем по больнице. Или если проще — это не про замену человека, а просто про ускорение старта разработки во времени. А вы что об этом думаете, коллеги?