TGTGInsightinteligencia telegramLIVE / telegram public index
← Protraktor
Protraktor avatar

TGINSIGHT POST

Post #132

@protraktor

Protraktor

Vistas320Número de vistas
Publicado11 abr11/04/2023, 22:09
Contenido del post

Contenido

Запрос про реверс-ЮХ В последнее время стал чаще встречаться с «обратным UX», эдакий семантический реверс-инжиниринг, когда нужно продумать наилучший опыт исходя из того что есть от инженеров/программистов — например, от структуры имеющейся базы данных, хранящей кучу таблиц, либо от API, который содержит форматы данных и запросов/результатов. Это становится всё более распространенным, потому что: 1) Далеко не всегда возможно взять и поменять UX с нуля, системы усложняются, приходится ковыряться в легаси, включая большие объемы накопленных данных, и ограничения кода/данных становятся очень существенными. Нужно мыслить стратегически, а не «ща я всё сделаю зашибись». 2) Если говорить о сложных инженерных системах (и, кстати, я верю что это верно — особенно верно — и для нейросетей), то чтобы сделать красивую и удобную обертку для потребителя системы, нужно создать навороченный доступ к «подкапотному» пространству — то есть сеттинги. И никакой UX дизайнер ну не сможет взять, опять же, и пойти от сценариев настройки каких-нибудь протоколов данных, сенсоров и отображений без изначальной постановки инженеров. Вот возьмите придумайте с нуля управление контроллерами, сигналами, алгоритмами и всякими ModBUS с позиций бизнес-требований. Брехня же. «Обратность» тут хорошо проявляется — часто мы идём от технологий (будь то авиация, атомная электростанция или ChatGPT), приспосабливая её к человеку/бизнесу, а не от придумывания технологий по запросам бизнеса/человека. Чтобы не звучало абстрактно, дополню примеры: 1) Любые системные настройки, инструменты разворачивания системы с нуля (в том числе аппаратного — вот есть у вас пустой мостик судна или шахта, и вам нужно это «автоматизировать». В каком порядке раскладывать сервера, провода и настраивать сенсоры так, чтобы сервисный инженер успел сделать пока судно стоит в порту, а не застрял на три недели в рейсе? с какого устройства это делать? а будет ли вайфай и необходимые данные?). Чистый сервисный дизайн, надо сказать, но совершенно не тот что в супермаркетах. 2) Любые сервисы, которые решают задачи высоко-автоматизированно. СППР, типа предупреждения столкновений судов/самолётов, или финансовые платформы с роботами, которые исследуют кучу сигналов и по сумме их выдают прогноз. Ну и те же самые нейросетки, которые постоянно поднастраивают, чтобы черная кошка из стори не была воспринята чем-то непотребным (реальный кейс, случившийся на днях) 3) Как говорил уже, инфосистемы с большим количеством данных. Попробуйте взять, и поменять формат БД с журналами записей за несколько лет, чтобы показать разбивку по категориям, которой сейчас нет, а очень полезно для пользователей? И еще ваша БД сейчас имитирует бумажные журналы, где каждая запись в БД — отдельная строчка в журнале, даже если несколько строчек связаны по смыслу (тоже реальный кейс из практики). Как поставить задачу, дабы не быть посланным разработчиками? 4) Автогенерируемые штуки на уровне UI. Представим что у вас сотня видов объектов и вам нужно сделать UI с информацией о каждом из них (опять же, морские навигационные карты — типичная история). Рисовать 100 макетов в Фигме и просить их разработать каждый? Или формализовать генератор UI с группировками полей разных видов, и добавлением этих групп и приоритетов в изначальную структуру данных? Но вообще тема очень мутная, сложная и трудоёмкая (ещё и планировать её трудно), похожая на поиски назначения в косе проводов автомобиля. Я не уверен что это так уж нужно/интересно моей аудитории. Поэтому ниже опрос — стоит ли об этом писать, и если считаете что стоит, отметьте в комментах что конкретно вас мучает в таких историях — тогда при позитивном раскладе я попробую поделиться своим опытом более сфокусированно.