Раньше граница ответственности дизайнера заканчивалась на Figma-макете. Ну, в крайнем случае, на проверке верстки. Но когда в игру вступает ИИ, привычный процесс ломается. Ты можешь нарисовать идеальную кнопку, продумать микровзаимодействия и плавные переходы, но если модель под капотом выдает токсичный бред или ошибается в классификации простых объектов, твой UX мертв.

Я часто слышу: "Разметка данных — это скучная рутина для джунов или аутсорса". Чушь. В мире машинного обучения разметка датасета — это и есть проектирование продукта. Это создание фундамента, на котором строится пользовательский опыт. И если дизайнер не залез в этот процесс по локоть, он не контролирует результат.

Мусор на входе — мусор в интерфейсе

Принцип "Garbage In — Garbage Out" в дизайне ИИ ощущается особенно больно. Представьте, что вы проектируете систему для интернет-магазина одежды, которая должна автоматически распознавать фасоны по фото. Если в датасете, на котором училась модель, под тегом "платье" были только вечерние наряды в пол, то в интерфейсе пользователь никогда не получит адекватный результат для летнего сарафана.

Проблема не в коде. Проблема в том, что на этапе сбора данных никто не подумал о разнообразии сценариев. Дизайнер — это адвокат пользователя. Именно он должен следить, чтобы в выборке не было предвзятости (bias). Если модель предвзята, никакой "красивый шрифт" не спасет юзера от чувства фрустрации.

Дизайнер как куратор данных

Сегодня нам нужно менять роль с "рисовальщика интерфейсов" на "куратора смыслов". Когда мы проектируем модель Computer Vision или NLP, мы фактически создаем иерархию классов. И это чертовски похоже на создание дизайн-системы.

Вам нужно решить:

Какие категории объектов важны для пользователя, а какие можно объединить?
Как разрешать спорные случаи (edge cases)?
Какова структура ответов модели?

Если вы не участвуете в создании структуры классов, вы отдаете логику продукта на откуп дата-сайентистам. А у них другие приоритеты — им важна метрика точности (Accuracy), а не то, насколько логично категории выглядят в глазах живого человека.

Автоматизация на Qubu: Как не сойти с ума от разметки

Размечать вручную тысячи картинок или текстовых строк — это ад. Мы в своих проектах давно используем инструменты автоматической разметки (Auto-labeling) на платформе Qubu. Это работает как магия: вы размечаете вручную буквально пару сотен примеров, а затем запускаете модель-помощник, которая размечает остальное.

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

# Пример того, как мы подключаем скрипт для первичной валидации данных в PostgreSQL
# Дизайнеру полезно понимать, как отсеять явный брак в данных
SELECT id, image_path, label 
FROM datasets 
WHERE confidence_score < 0.8 
ORDER BY created_at DESC 
LIMIT 100;

Да, современному дизайнеру нужно уметь написать простой SQL-запрос. Зачем? Чтобы не ждать неделю, пока разработчик выгрузит вам данные для проверки. Вы должны иметь возможность зайти в "базу" и своими глазами увидеть, на чем учится ваш продукт.

"Золотой сет" и этика

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

В этот сет должны входить самые сложные, спорные и этически тонкие моменты. Если вы делаете чат-бота, в "золотом сете" должны быть вопросы с подвохом, попытки спровоцировать агрессию или манипуляции. Если модель проходит этот тест и отвечает в рамках заданного вами ToV (Tone of Voice), значит, UX в безопасности.

Это и есть современный "авторский надзор".

Почему SQL и форматы данных — это новые "сетки"

Понимание структуры PostgreSQL или форматов JSON/CSV становится таким же базовым навыком, как знание теории цвета. Данные — это материал. Как архитектору нужно знать свойства бетона, так продуктовому дизайнеру нужно понимать, как хранятся и передаются данные.

Если вы понимаете, что данные в базе лежат в определенном формате, вы можете спроектировать интерфейс, который учитывает ограничения этого формата. Вы перестаете рисовать "воздушные замки" и начинаете создавать работающие системы.

Был случай: мы проектировали фильтр для сложной аналитической системы. Дизайнер нарисовал 15 уровней вложенности, не зная, что структура данных в базе плоская. В итоге пришлось всё переделывать, потому что запросы к такой структуре работали по 10 секунд. Если бы дизайнер глянул в схему базы в первый день, мы бы сэкономили две недели жизни команды.

Итог

UX больше не начинается с чистого листа в Figma. Он начинается с первой строчки в вашем CSV-файле для обучения.

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

Потому что в мире ИИ интерфейс — это просто тонкая кожа, а скелет и мышцы — это ваши данные.

А вы когда-нибудь проверяли, на каких данных учатся ваши продукты? Или доверяете команде разработки на слово?

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

В следующий раз поговорим о том, как объяснять пользователю, что ИИ ошибся, и при этом не потерять его лояльность. Спойлер: одной фразы "Извините, я еще только учусь" уже давно недостаточно.

UX начинается с данных: Почему Product-дизайнеру нужно участвовать в разметке датасетов

Похожие статьи

Поделиться в соц. сетях

Комментарии