Основатель британской дизайн-студии cxpartners Жиль Колборн написал советы для коллег о том, как начать применять самообучающиеся алгоритмы в своих продуктах. Разработчики “умной” системы редизайна старых сайтов сделали адаптированный перевод этого материала.

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

Как сказал Алан Купер: “Неважно, насколько крут пользовательский интерфейс, главное — чтобы его было как можно меньше”. Меньше интерфейса значит меньше действий со стороны пользователя. В наши дни, когда разрабатывается все больше интерактивных продуктов, никто не хочет, чтобы интерфейсы для взаимодействия с ними были громоздкими и отталкивающими.

Это одна из причин, почему в сообществе столь широко обсуждается тема алгоритмов и искусственного интеллекта. Мощь новых технологий можно использовать для упрощения взаимодействий. Но что это значит применительно к созданию дизайна на практике?

Алгоритм подталкивает к целевому действию

Раз в неделю Spotify отбирает для вас дюжину музыкальных треков, которые, как считает специальный алгоритм Spotify Discover Weekly, должны понравиться конкретному человеку. Для многих пользователей эта функция — одна из причин продлевать подписку на сервис.

Это плейлист, такой же как и любой другой. В чем здесь должен быть вклад дизайнера? Ведь содержимое интерфейса определяется поведением пользователя, которое анализируется алгоритмом. А алгоритмы создаются инженерами.

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

Давайте возьмем более сложную ситуацию: бронирование железнодорожного билета в Великобритании. Наши дизайнеры тратили часы на протяжении нескольких лет, чтобы понять, как лучше организовать отображение сложного и подчас нелогичного ценообразования на билеты в этой стране.

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

Дизайн вокруг алгоритмов

Представим, что нам необходимо создать приложение для клиентов пассажирской компании. Нужды пользователя в этом случае просты — ему нужно знать, где его автобус. Сразу понятно, как здесь может помочь алгоритм: скормив ему уникальные данные, можно построить уникально ценный сервис.

У нас есть данные о расписании движения: известно, где и когда должны быть автобусы разных маршрутов. Но это открытая информация. Еще есть GPS-данные с маяков на автобусах. Это уже уникальные данные, которые есть только у транспортной компании. Теперь можно сопоставить расписание с тем, как в действительности передвигаются автобусы. Например, можно легко узнать, когда они выбивались из графика — это интересно, но не очень ценно.

Можно добавить данные о погоде, затруднениях трафика, школьных каникулах, дорожных работах. Можно выявить какие-то корреляции в прошлом и выработать прогнозы на будущее.

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

Но алгоритмы – это не магия, их создают и обучают. Поэтому, если хотите делать подобные приложения, нужно подробнее разобраться в теме алгоритмов, чтобы продуктивно пообщаться с инженером о том, что и как можно сделать.

Разговор с инженерами

Инженерную задачу можно представить примерно так:

1. На входе существует данных — в нашем случае, это информация о расписании автобусов и все, что мы отберем (данные о каникулах, погоде, заторах и т.п.).
2. Затем идет сам алгоритм.
3. На выходе имеем результат: скажем, прогноз того, опоздает автобус или прибудет вовремя.

Дизайнеру лучше начинать беседу с инженером в обратном порядке.

3. Результат

Дизайнер должен представлять, какой результат будет полезен пользователю. Стоит ли просто уточнять, что опоздание превысит пять минут, или лучше выдать точное значение — например, «задержка составит восемь минут»? Чем детальнее описан результат, тем более детальной становится инженерная задача. Детали лучше прорабатывать заранее, общаясь с будущими пользователями и показывая интерактивные прототипы.

2. Алгоритмы

В начале разработки любой “умный” алгоритм будет “сырым”. Только со временем он достаточно натренируется в распознавании и генерировании. Для этого ему предоставят наборы входных данных (погода, дорожные работы и т.п.) и некоторые известные результаты (на сколько в таких условиях автобус задерживался в прошлом). Это уже задача инженера — выбрать подходящий под задачу алгоритм и улучшать его таким образом, чтобы повысить точность результата при заданных входных параметрах.

1. Входные данные

Первое, о чем каждому стоит беспокоиться в работе с данными, – это их качество. В нашем примере с автобусами важна точность GPS-данных. В идеале, они должны быть супер-точными. В жизни, собранные данные (дата-сет) для тренировки алгоритма могут быть "зашумленными": например, если GPS не очень хорошо работает на каких-то участках маршрутов. Работа с зашумленными данными может приводить к циклу переобучения, если алгоритм после обучения начнет выдавать неточные прогнозы. К такому повороту тоже нужно быть готовым.

0. Заранее продумайте объем данных

Инженеры всегда нервничают, когда дизайнеры пытаются добавлять новые уровни данных: для тренировки нашего алгоритма-примера и так потребуются данные GPS за целый год, а может и за два, а в процессе вы решите добавить данные о погоде...

Поэтому дизайнеру нужно анализировать, действительно ли определенный уровень данных, добавленный к основным, нужен для решения задачи пользователя. Скажем, сделает ли информация о школьных каникулах и дождях более точными прогнозы о времени прибытия автобусов?

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

Бывает: выбирая из двух зол

Помимо переизбытка данных, вы можете столкнуться и с обратной проблемой: когда большого количества данных нет. Добиться точности от алгоритма в этой ситуации будет непросто. И тут существуют два базовых “зла”, из которых придется выбирать.

• Первое зовется "высоким смещением" (high bias). Это значит, что вы ошибаетесь, но предсказуемым образом.
• Второе зовется “высокая вариативность” (high variance). И означает, что в среднем вы правы, но любое конкретное предположение может быть очень далеко от истины.

Рассмотрим на нашем примере. Вы можете создать систему с высоким смещением, которая всегда будет немного "привирать" о времени прибытия автобуса. А можете позволить приложению выдавать “точное” время: но из-за высокой вариантивности, оно не всегда будет совпадать с реальным временем прибытия автобуса.

Какое "зло" выбрать? Решать вам, но в первом случае пассажиры скорее смогут быть на остановке в нужное время.

Бывает: сложные входные данные

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

Скажем, вы решили добавить в автобусное приложение данные о погоде. Ведь она влияет на задержки транспорта. Задача усложняется. Нужно ли знать точное время начала дождя? Или достаточно знать, что дождь прошел или пройдет в конкретный час? Или что он просто “был утром”? Нужно ли делать различия между ливнем и небольшим дождиком?

Каждый из этих ответов будет влиять на то, сколько информации окажется в наборе данных, относящемся к погоде. При этом "всего побольше" — не всегда лучшее решение.

Для примера возьмем более сложную ситуацию: алгоритм распознавания естественного языка для банка, в обучении которого применяются расшифровки диалогов сотрудников контакт-центра с клиентами. Такой набор данных можно и нужно упростить — скажем, сфокусироваться только на выборке диалогов, завершившихся решением проблемы клиента. А в этой выборке обратить внимание на те беседы, что привели к успеху за наименьшее возможное количество шагов.

Иногда использование более простых данных на входе приводит к более точному результату на выходе: это как подкрутить контрастность отсканированного текста, чтобы сделать его более читабельным.

Бывает: первый блин комом

В один момент ваш алгоритм кажется достаточно обученным и генерирует нужные результаты на основе отобранных данных. Наступает время "прогнать" его на данных реальных.

Всегда есть шанс, что результаты, полученные на реальных данных, не будут очень уж точным. Скорее всего, команде придется выделить энное время на закрытое бета-тестирование и активно собирать обратную связь. Зато потом вы подойдете к моменту, когда алгоритм cможет работать без присмотра кого-то из вашей команды и “подкрамливания” его новыми тестовыми данными.

P.S. Машина предсказаний

Итак, момент настал. Вам удалось построить настоящую машину предсказаний и генерации волшебного для пользователя результата.

Поверьте, на всем этом пути к успеху вы будете постоянно общаться с инженерами, определяя и переопределяя, каким должен быть конечный результат и как он должен выглядеть для пользователей.

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

***

Перевод: команда uKit AI, сервиса, который делает редизайн сайтов с помощью нейросети.