Для розробки продуктів у MilTech потрібні не лише інженери. Чому інтерфейс на полі бою — це питання безпеки
Абсолютно природно, що для розробки нових оборонних систем та їхньої цифровізації насамперед шукають інженерів, конструкторів та архітекторів ПЗ. Проте, коли справа доходить до інтерфейсів, з якими безпосередньо працюють оператори БПЛА, систем РЕБ чи координації, виникає критичний розрив.
Часто не враховується головне: в умовах високого стресу людина має миттєво зорієнтуватися в ситуації. Інтерфейс оборонного софту повинен не просто відображати дані, а мінімізувати когнітивне навантаження на бійця.
Саме цим, визначенням реальних болей операторів, аналізом потреб командування та проектуванням логіки взаємодії, займаються продуктові дизайнери та UX-дослідники. На основі глибокого дослідження користувачів та вивчення військових стандартів (таких як MIL-STD-1472H) ми допомагаємо адаптувати складні технології під жорстке, живе середовище.
Чому це критично?
- Зниження когнітивного стресу. Під час виконання бойового завдання мозок оператора і так перевантажений зовнішніми факторами. Інтерфейс має підсвічувати лише те, що важливо «тут і зараз», прибираючи весь інформаційний шум.
- Швидкість прийняття рішень (Time-to-task). Мій досвід проектування складних індустріальних систем у Comarch (Industry 4.0) показав: правильна архітектура інформації та усунення зайвих кроків дозволяють скоротити час виконання операцій оператором на 20%. У цивільному житті це економить гроші компанії, на полі бою — рятує життя.
- Тестування в реальних умовах, а не в кабінетах. Софт, який ідеально працює на моніторі в офісі розробника, може стати нечитабельним під прямим сонцем, у рукавицях чи під час вібрації. UX-дослідження допомагають виявити ці критичні баги інтерфейсу ще на етапі прототипів.
Проєктування під високий когнітивний стрес вимагає глибокого розуміння життєвого циклу систем, тож варто фокусуватися на створенні людино-центрованої ясності для MilTech та HealthTech продуктів.
Технології перемагають тоді, коли вони інтуїтивні для тих, хто ними керує.
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівАбсолютно згоден з автором. Проблема більшості систем — інформаційний шум. Організація інформації у різних форматах (чи то тактичні карти, чи то ТЗ) має підкорятися фрактальній логіці: Фільтр (відсікання зайвого) ➔ Офіс (структурування зв’язків) ➔ Пульт керування ( HUD, де залишається лише кнопка дії). Будь-який масив даних у стресі має згортатися в Атом сенсу. Реалізую цей підхід через чистий Client-side JS, щоб інтерфейс не залежав від хмар чи зв’язку.
Абсолютно згодна з вами! Те, що ви описали — це саме той флоу, який життєво необхідно впроваджувати.
мені цікаво, нащо цей нейрослоп. візьміть якийсь поточний інтерфейс який масово застосовується ЗСУ — Кропива, дельта, графіт, віраж тощо і продемонструйте як ви можете його покращити для
та
Дякую за коментар! У даній сфері просто взяти й публічно покращити Дельту, Кропиву чи Віраж не зовсім можливо через те, що скріншоти та реальна логіка роботи цих систем — це закрита інформація. Робити публічні редизайни критичного військового софту на загальнодоступних платформах означає створювати загрозу безпеці.
Багато хто не розумію специфіку дизайнерів, ми не просто беремо і перемальовуємо щось, це UI дизайн. Дизайн складних систем не робиться не в офісі. Щоб реально знизити когнітивний стрес у тій же Кропиві, потрібно сидіти поруч з артилеристами, розуміти їхній контекст, бачити, на якому залізі (планшетах) це запускається, яка там яскравість екрана вночі чи на сонці, та які радіопротоколи передачі даних накладають обмеження на швидкість оновлення інтерфейсу. А це означає проведення реального дослідження.
с чого це вона закрита? на ютубі навіть є посібники,
та і команда Кропиви доступна по контактам на сайті. Додало б практичності статті, а не вигляд тексту згенерованного ллм
Ви скинули відеоінструкції з програм, але там не вказано з чого брали ці дані, чому саме вони представлені. Лише інструктор навчає, як користуватись. Схоже, ви не розумієте взагалі мою специфіку.
мені здається що ви без ллм теж не дуже розумієте
ні, не закрита
моя початкова теза була про відсутність практичності у вашій статті, якщо це частина резюме, то вона не має бути у статтях, якщо ви нас чомусь хочете навчити — там нема прикладів, якщо (раптово!) продуктова дизайнерка, UX дослідниця захотіла домогти Силам Оборони, то є системи де можна прикласти свої зусилля і без розголошення секретних таємниць розказати як впровадження
допомогло. Можливо ціль статті була в іншому, от поки не зрозуміло в чому