«День шлифовки»: инструкция по исправлению небольших проблем в продукте

Разработчик интерфейсов Optimizely Дэйв Рау о концепции поиска ошибок в интерфейсе проекта и их исправлении.

При внимательном рассмотрении в любом крупном приложении и на любом сайте можно найти небольшие недочёты в дизайне интерфейса. Они накапливаются по мере того, как мы вводим новые фичи, реагируем на обратную связь от пользователей или проверяем новые идеи.

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

Любой сотрудник компании Optimizely может добавлять проблемы, нуждающиеся в шлифовке, в Design Backlog. Обычно формулировку проблемы сопровождает короткое описание способа её решения и скриншот. Как только недостаток будет устранён, закладка автоматически закрывается, а сделанные изменения попадают в работу.

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

Эти пункты трудно ранжировать по важности — ведь большинство багов, касающихся пользовательского интерфейса, кажутся очень маленькими на фоне текущих проблем заказчиков и запуска новых функций. Поэтому чтобы сфокусироваться на них, мы выделили специальный Polish Day («День шлифовки»).

Наш список проблем включает в себя примерную оценку затрат на их устранение (минимальное исправление обходится в $10). Дизайнеры расставляют приоритеты, исходя из суммарной ценности в $100 за один Polish Day.

Вся работа над мелкими недочётами в UI-дизайне разделена на три простых шага:

Перед тем, как назначать Polish Day, составьте полный список существующих проблем. Хорошо организованный список позволит вам не впасть в уныние при виде того, как в него постоянно поступают всё новые и новые задачи.

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

Высокий приоритет присваивается тем пунктам, которые заметны больше других (очевидные баги исправляются быстрее). Самые неприятные пункты связаны с тем, что элементы интерфейса перекрывают друг друга (в этом случае все значения z-индекса помещаются в одно место), а также с текстом, который не помещается в шаблон. Здесь могут присутствовать следующие проблемы:

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

Менее серьёзные пункты обычно содержат пространственные несоответствия и включают в себя проблемы:

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

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

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

Каждый четверг продуктовые дизайнеры и разработчики интерфейса Optimizely расставляют приоритеты по шлифовке. Мы посвящаем около 20 минут оценке временных затрат и влияния возможных изменений CSS и обсуждаем их последовательность. Если подготовка какого-то пункта к кодированию зависит в основном от дизайнера, мы прислушиваемся именно к нему. После этого устанавливается цена.

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

Если вы исповедуете Agile-подход, можете использовать условные единицы. Нам хотелось иметь более доступный способ оценки времени, и мы создали его сами. Каждый Polish Day дизайнеры получают $100. Это виртуальные деньги, но подсчёты вполне реальны и основаны на оценке усилий. Каждая решённая закладка оценивается в доллар, а задания, работа над которыми может занять целый день (например, тщательное редактирование текста), стоят $10.

Оценив каждое задание, дизайнеры просматривают список и выбирают пункты на общую стоимость в $100.

Некоторые из наших Polish Days имеют тему, например, «шлифовка миграционных настроек аккаунта». В другие дни мы обрабатываем произвольный набор самых заметных или особенно скучных пунктов.

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

Регулярно выделяйте время на шлифовку, и тогда вам не придётся останавливать рабочий процесс и тратить недели на всяческие доработки.

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

Polish Day повысит боевой дух команды, позволит вам закрыть несколько рабочих проблем и в целом повлиять на пользовательский опыт.

#Интерфейсы