Покупной корпус не всегда оказывается лучшим решением.
В одном из проектов мы разрабатывали браслет для строителей.
Типовой корпус не подошёл сразу по нескольким причинам: в него не помещалась вся электроника, браслет был слишком громоздким и неудобным, а после работы на стройке быстро терял внешний вид.
Поэтому корпус решили разрабатывать с нуля.
Носимое устройство должно быть эргономичным по умолчанию. Неважно, кто им пользуется — строитель на площадке или человек с фитнес-браслетом. Если устройство постоянно ощущается на руке и мешает работать, хороший продукт из него не получится.
И оказалось ещё кое-что интересное.
При том тираже, что планировал заказчик, собственный корпус вышел дешевле покупного.
В одном из проектов мы разрабатывали браслет для строителей.
Типовой корпус не подошёл сразу по нескольким причинам: в него не помещалась вся электроника, браслет был слишком громоздким и неудобным, а после работы на стройке быстро терял внешний вид.
Поэтому корпус решили разрабатывать с нуля.
Носимое устройство должно быть эргономичным по умолчанию. Неважно, кто им пользуется — строитель на площадке или человек с фитнес-браслетом. Если устройство постоянно ощущается на руке и мешает работать, хороший продукт из него не получится.
И оказалось ещё кое-что интересное.
При том тираже, что планировал заказчик, собственный корпус вышел дешевле покупного.
❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Почему корпус может месяцами ходить от дизайнера к конструктору и обратно?
Потому что одно решение приходится проверять с нескольких сторон: удобно ли пользователю, можно ли это произвести и сколько всё это будет стоить.
Дизайн и конструкция редко рождаются последовательно: чаще это несколько итераций туда-обратно.
А иногда дизайнер и конструктор ещё и начинают тянуть продукт каждый в свою сторону.
Об этом рассказываем в видео.
YouTube
RuTube
VK-видео
Потому что одно решение приходится проверять с нескольких сторон: удобно ли пользователю, можно ли это произвести и сколько всё это будет стоить.
Дизайн и конструкция редко рождаются последовательно: чаще это несколько итераций туда-обратно.
А иногда дизайнер и конструктор ещё и начинают тянуть продукт каждый в свою сторону.
Об этом рассказываем в видео.
YouTube
RuTube
VK-видео
💯3❤2🔥1
Media is too big
VIEW IN TELEGRAM
Пользователю не нужен ваш продукт.
Ему нужно решить свою задачу.
Допустим, мы разрабатываем систему охлаждения. Можно сделать ее мощнее всех аналогов. Но клиент будет сравнивать не только цифры в характеристиках, а разные способы решить свою задачу.
Иногда выиграет менее мощное устройство. Иногда — вообще другое техническое решение.
Поэтому при разработке полезно несколько раз спросить: «Чтобы что?».
Зачем нужна такая мощность? Чтобы охладить оборудование. Чтобы что? Чтобы оно работало в нужном температурном режиме.
Вот это уже задача продукта. А мощность — лишь один из способов ее решить.
Об этом — в видео.
YouTube
RuTube
VK-видео
Ему нужно решить свою задачу.
Допустим, мы разрабатываем систему охлаждения. Можно сделать ее мощнее всех аналогов. Но клиент будет сравнивать не только цифры в характеристиках, а разные способы решить свою задачу.
Иногда выиграет менее мощное устройство. Иногда — вообще другое техническое решение.
Поэтому при разработке полезно несколько раз спросить: «Чтобы что?».
Зачем нужна такая мощность? Чтобы охладить оборудование. Чтобы что? Чтобы оно работало в нужном температурном режиме.
Вот это уже задача продукта. А мощность — лишь один из способов ее решить.
Об этом — в видео.
YouTube
RuTube
VK-видео
❤2
Видим сейчас интересный процесс — все больше задач от заказчиков формулируется с помощью нейросетей, но и с нашей стороны происходит тоже самое — все больше таких задач прогоняется через нейронку, а уже потом смотрится живым спецом.
И в целом, в этом нет ничего плохого или негативного. Просто та подготовительная работа, которая раньше делалась со стороны клиента (формулирование требований, задач, результатов, вводных) сейчас делается на сильно более ранних этапах проекта и нейронкой. Фактически это означает ускорение проектов и их запуск, в среднем по больнице.
Или если проще — это не про замену человека, а просто про ускорение старта разработки во времени.
А вы что об этом думаете, коллеги?
И в целом, в этом нет ничего плохого или негативного. Просто та подготовительная работа, которая раньше делалась со стороны клиента (формулирование требований, задач, результатов, вводных) сейчас делается на сильно более ранних этапах проекта и нейронкой. Фактически это означает ускорение проектов и их запуск, в среднем по больнице.
Или если проще — это не про замену человека, а просто про ускорение старта разработки во времени.
А вы что об этом думаете, коллеги?
👍1🤔1
В техническом задании может быть 50 требований. Но это не значит, что все 50 одинаково важны.
У разных участников проекта свои интересы.
Пользователю нужно, чтобы устройство было удобным. Производству — чтобы его было проще изготовить. Сборщикам — собрать. Сервису — обслуживать. Бизнесу — чтобы всё это укладывалось в экономику проекта.
И довольно быстро требования начинают конфликтовать.
Можно сделать корпус дешевле, но менее удобным. Упростить сборку, но усложнить обслуживание. Добавить характеристику, которая выглядит преимуществом на бумаге, но пользователю вообще не нужна.
Поэтому собрать все пожелания в ТЗ недостаточно. Их нужно расставить по приоритетам.
▪️В первую очередь — требования, из-за которых продукт не купят первый раз или не купят второй.
▪️Затем — то, с чем непосредственно сталкивается пользователь: удобство, безопасность и другие важные для него свойства.
После этого остальные требования проверяют относительно этих приоритетов: где можно упростить конструкцию, оптимизировать производство или снизить себестоимость, не испортив продукт для пользователя.
У разных участников проекта свои интересы.
Пользователю нужно, чтобы устройство было удобным. Производству — чтобы его было проще изготовить. Сборщикам — собрать. Сервису — обслуживать. Бизнесу — чтобы всё это укладывалось в экономику проекта.
И довольно быстро требования начинают конфликтовать.
Можно сделать корпус дешевле, но менее удобным. Упростить сборку, но усложнить обслуживание. Добавить характеристику, которая выглядит преимуществом на бумаге, но пользователю вообще не нужна.
Поэтому собрать все пожелания в ТЗ недостаточно. Их нужно расставить по приоритетам.
▪️В первую очередь — требования, из-за которых продукт не купят первый раз или не купят второй.
▪️Затем — то, с чем непосредственно сталкивается пользователь: удобство, безопасность и другие важные для него свойства.
После этого остальные требования проверяют относительно этих приоритетов: где можно упростить конструкцию, оптимизировать производство или снизить себестоимость, не испортив продукт для пользователя.
❤6🔥1
Дизайн корпуса не всегда начинается с дизайна.
В проекте ЭЗС «АТТАР Солана» мы начали с компоновки.
У станции четыре зарядных коннектора. Кабели длинные, тяжёлые и жёсткие — их нужно удобно вытянуть к машине, а после зарядки убрать так, чтобы они не болтались и не путались.
При этом внутри станции — силовые модули и другая электроника. Нужно организовать вентиляцию, отдельно отводить горячий воздух от силовых модулей, обеспечить IP55 и IK10, оставить доступ для обслуживания — и уложить всё это в минимальные габариты по ширине.
🔺Поэтому сначала мы разбирались, как человек будет пользоваться станцией и как под эту задачу должна быть устроена конструкция.
Смоделировали разные варианты расположения кабелей и в итоге разместили их на подвесах под крышей станции, добавили систему сматывания с барабаном, а коннекторы утопили в узкие панели корпуса.
🔺И только когда с компоновкой стало понятно, начали делать эскизы внешнего вида. Так сформировалась форма ЭЗС — лаконичная, технологичная и рассчитанная на интенсивную эксплуатацию в городской среде.
В хорошем ТЗ много требований. Но проектировать продукт — не значит просто выполнить их все по списку. Нужно понимать, какие решения определяют, насколько продукт будет удобен в реальной эксплуатации.
В проекте ЭЗС «АТТАР Солана» мы начали с компоновки.
У станции четыре зарядных коннектора. Кабели длинные, тяжёлые и жёсткие — их нужно удобно вытянуть к машине, а после зарядки убрать так, чтобы они не болтались и не путались.
При этом внутри станции — силовые модули и другая электроника. Нужно организовать вентиляцию, отдельно отводить горячий воздух от силовых модулей, обеспечить IP55 и IK10, оставить доступ для обслуживания — и уложить всё это в минимальные габариты по ширине.
🔺Поэтому сначала мы разбирались, как человек будет пользоваться станцией и как под эту задачу должна быть устроена конструкция.
Смоделировали разные варианты расположения кабелей и в итоге разместили их на подвесах под крышей станции, добавили систему сматывания с барабаном, а коннекторы утопили в узкие панели корпуса.
🔺И только когда с компоновкой стало понятно, начали делать эскизы внешнего вида. Так сформировалась форма ЭЗС — лаконичная, технологичная и рассчитанная на интенсивную эксплуатацию в городской среде.
В хорошем ТЗ много требований. Но проектировать продукт — не значит просто выполнить их все по списку. Нужно понимать, какие решения определяют, насколько продукт будет удобен в реальной эксплуатации.
👍4❤2🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Мы оцениваем продукт ещё до того, как начали им пользоваться.
Достаточно посмотреть на ручку инструмента, чтобы предположить, удобно ли будет его держать. На корпус оборудования — чтобы решить, кажется ли оно надёжным. На форму автомобиля — чтобы считать его мощным или быстрым.
Причём реальная характеристика и то, как мы её воспринимаем, — не всегда одно и то же.
Поэтому задача промышленного дизайна — не только обеспечить нужные свойства продукта, но и помочь пользователю их считать.
Как это работает — показываем в видео.
YouTube
RuTube
VK-видео
Достаточно посмотреть на ручку инструмента, чтобы предположить, удобно ли будет его держать. На корпус оборудования — чтобы решить, кажется ли оно надёжным. На форму автомобиля — чтобы считать его мощным или быстрым.
Причём реальная характеристика и то, как мы её воспринимаем, — не всегда одно и то же.
Поэтому задача промышленного дизайна — не только обеспечить нужные свойства продукта, но и помочь пользователю их считать.
Как это работает — показываем в видео.
YouTube
RuTube
VK-видео
❤3