Действие, не состояние

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

Неизвестная ошибка

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

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

Ошибка — попробуйте ещё раз или напишите нам

Или вот вы тест с несколькими вариантами на выбор. Если пропустить, появляется красненькая надпись:

Не выбрано ни одного пункта

Вроде пытаемся что-то донести, но что — еще надо додумать. Почему бы не избавить пользователя от лишних додумываний?

Выберите хотя бы что-то

Действует практически во всём. Попробуйте еще раз и напишите, если не получится.

Тестовые задания

Что думал в начале 2019
- Тестовое задание — важный этап при найме дизайнеров.
- Не всегда по портфолио удаётся понять, насколько у человека сильны навыки и как именно он мыслит. Например, человек мог работать в большой команде, и его личный вклад в итоговый результат не так уж значителен. Или его работы под NDA.
- Тестовое хорошо подсвечивает сильные и слабые стороны.
- Естественно, в качестве задания берётся ненастоящая задача, хотя и реалистичная. Если кандидат переживает, что компания воспользуется результатами его труда, это многое говорит о кандидате.
- Поскольку кандидат потратил на тестовое задание немало времени, нанимающая сторона тоже должна потратить время и дать развёрнутую обратную связь.

Что думаю в начале 2020
- Тестовые задания — это прошлый век. Гугл, Фейсбук, Интерком полностью отменили тестовые задания при найме дизайнеров.
- Главная причина — тестовые сильно перекашивают выборку кандидатов в сторону более молодых и менее опытных. Если человек уже состоялся в профессии, если у него есть свои проекты, семья, дети, коты и т. д., у него может и не быть нескольких свободных вечеров, ночей и выходных, чтобы сидеть над тестовым.
- Больше всего времени в работу над тестовыми заданиями готовы вкладывать молодые и свободные начинающие специалисты. Но далеко не всегда мы хотим нанимать только их.
- Особенный зашквар — тестовые про продукты самой компании (типа «нарисуйте нам новое приложение»). У кандидата заведомо нет и доли того контекста, который есть у людей внутри. Что ожидают увидеть нанимающие? Что кандидат угадает, о чём они думали последние полгода?
- Как без тестового получить достаточный сигнал при найме? Не так уж и сложно. Например, мы просим кандидата презентовать несколько своих последних проектов перед группой наших дизайнеров. И задаём очень много вопросов про всё: какая была задача, почему всё сделано именно так, какие ещё варианты рассматривались, как всё в итоге сработало, что бы человек сейчас переделал по-другому. Сразу и коммуникационные навыки проверяются, важные в нашей работе.
- Хороший процесс найма с несколькими этапами интервью и презентацией портфолио позволяет получить сигнал не менее точный, чем тестовое задание.
- А что если кандидат сам просит, чтобы ему дали тестовое? Иногда такое бывает. Не вопрос — пусть сам себе его и придумает, пусть сделает, заодно в портфолио выложит, сплошная польза.

Нечто большее

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

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

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

Таким образом, получился бы сервис, который с одной стороны собирает заказчиков-исследователей: они назначают задания и указывают стоимость за их выполнение; а с другой стороны имеются исполнители — ребята полевики, которые заинтересованы заработать и прокачаться в урбанистике.

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

Представьте, что вы как заказчик, оставляете заявку и вам за считанные дни проводят целое исследование. Прелесть!

Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

Проблема в том, что непонятно, кто заблокировал IP и почему. В большинстве случаев это и неважно, но иногда пригодилось бы для разбора. Решить проблему элементарно — добавить поле «комментарий».

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.

Комментарий — элемент хаоса. Но с ним система устойчивее.

Итог по блоку исследования

Так как блок исследования был впервые в программе, я думаю важно оставить обратную связь.

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

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

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

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

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

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

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

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

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

Олег Большаков написал о проектировании системы уведомлений.

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

2. Создайте каркас: первый столбец таблицы — для событий, остальные столбцы — для уведомлений для каждой пары «задействованная роль и канал связи» (пуш-уведомления, письма, персональная лента). Например: «Персональная лента: Исполнитель».

3. Выпишите события, которые могут произойти в рамках процесса. События группируйте по ролям, которые их создают.

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

5. Заполните ячейки с уведомлениями по каждому событию для каждой пары «канал связи: роль». Ставьте прочерк там, где уведомления не будет.

— Старайтесь переиспользовать формулировки;
— Выделяйте переменные среди основного текста;
— Не забывайте о правилах хороших уведомлений: краткость, максимум полезной информации, тон соответствует бренду.

6. Доработайте события. Добавьте формулировки:

— Для массовых событий. Например: «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»;
— Для последовательностей действий. Например: если пользователь удалил одного утверждающего и добавил другого, пишите «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ».