Мы не агитируем пить. Мы берем состояние «устал / отвлёкся / под градусом» как стресс-тест интерфейса. Если в таком режиме человек не теряется, то в обычной жизни ему будет ещё проще.
Почему мы вообще говорим про алкоголь в корпоративном блоге?
Спокойно, давайте разбираться.
Представим ситуацию: по возвращению после тяжелого рабочего дня (абсолютно трезвого, честно) домой, приняв горячий душ и пропустив бокальчик… кофе, и вдруг вспоминаете, что завтра генеральный ждет от вас отчет за прошедший квартал.
Предвкушая «самую приятную ночь за последние полгода», вы открываете CRM-систему, и, вспомнив всех родственников разработчиков до третьего колена, пробираетесь через полотна сплошного текста и миллион одинаково желтых кнопок к нужным цифрам.
Параллельно:
- завтра на работу к девяти;
- курьер просит «спуститься, я не поднимаюсь»;
- вышла новая серия любимого сериала;
- кран на кухне внезапно решил, что он фонтан.
Представили?
А отчёт сам себя не напишет. Время 3:17, цифры плывут вслед за мозгом, заявление по собственному уже лежит под пятой кружкой кофе.
А при чём тут алкоголь?
Правда в том, что пользователи любого сервиса 90% времени находятся в состоянии «слегка изменённого сознания».
И сейчас речь не только про промилле. Эффект от тасок, дедлайнов, митингов и прочей рабочей возни очень похож:
- сниженное внимание;
- замедленная реакция;
- проблемы с восприятием реальности;
- попытки убедить себя, что это всё рано или поздно закончится.
Мы накопили достаточно большой опыт в проектировании интерфейсов и выработали одно ключевое правило:
Если пьяный человек способен разобраться в интерфейсе, то трезвый разберётся с ним играючи.
Мы называем такой подход DDD — drunk-driven design.
Какие интерфейсы нуждаются в «drunk»-тестах?
Если кратко — все. Реально.
- Лендинги. От понятности зависит конверсия. Если человек устал, отвлёкся, параллельно сидит в мессенджерах — он всё равно должен понять, что здесь за продукт и что от него хотят.
- Мобильные приложения. Банк, такси, доставка — это вообще в первую очередь. Люди часто пользуются ими ночью, в дороге, на эмоциях.
- Корпоративные админки. Особенно для ночных смен. Сотрудники поддержки и дежурные операторы часто находятся в состоянии «трезвого невменоза» — мозг вынужден обрабатывать огромное количество информации.
- Финансовые и рискованные операции. Если ошибка пользователя стоит дорого, интерфейс просто обязан быть понятным. Ошибка в таком сценарии — не «ой, страница не туда скролльнулась», а «куда-то уехали деньги / что-то удалилось навсегда».
А что там на практике?
Главную цель мы уже озвучили: интерфейс должен быть понятным.
Вот несколько критериев, по которым мы проверяем, получилось ли этого добиться.
1. Один экран – один сценарий
Никаких пяти равноправных кнопок рядом с основным действием.
Если страница посвящена расчёту прибыли — кнопку заказа еды рядом не ставим.
Если задача — перевести деньги — не прячем это действие в третий уровень меню.
2. Читаемый текст и большие кнопки
Кнопка должна быть сделана так, чтобы по ней было сложнее не попасть, чем попасть.
С текстом аналогично:
- пользователь не должен быть снайпером, чтобы прочитать текст с расстояния вытянутой руки;
- адекватный размер шрифта;
- нормальный межстрочный интервал;
- контраст, при котором не нужно щуриться.
3. Отказ от корпоративного буллщита
Не «Инициировать транзакцию», а «Отправить деньги».
Не «Подтвердить операцию», а «Да, перевести 1500 ₽».
Не «Выгрузить», а «Сохранить отчёт».
Так сразу понятно, что случится, если нажать на кнопку, и «пьяному» пользователю не приходится додумывать.
4. Ясная визуальная иерархия
- Один цвет для главного действия, чтобы выработался рефлекс:
«Я что здесь делаю? Ага, оформляю заказ, значит жму вот сюда — на такую же кнопку, как на прошлом шаге». - Порядок элементов тоже важен: взгляд должен сразу цепляться за главное — заголовок, ключевые цифры, основное действие.
5. База, но важная: защита от глупых ошибок
У пользователя всегда должна быть возможность откатить нежелательное действие.
Доступ к критическим функциям должен быть намеренно усложнён — так, чтобы одним неверным движением руки нельзя было снести половину системы.
Здесь живут:
- модальные окна с вопросом «Действительно хотите…?»;
- история изменений;
- корзина/архив вместо моментального удаления.
Сюда же — понятный фидбэк от приложения:
- что произошло;
- почему так вышло;
- что делать дальше.
6. Линейные сценарии вместо лабиринта
Интерфейс должен вести пользователя по шагам:
шаг 1 → шаг 2 → шаг 3
а не «гуляй по вкладкам, как Бог на душу положит».
Хороший помощник здесь — прогресс-бар с простым посылом:
«Осталось два шага, держимся».
Как это встроить в процессы команды?
Пьяный ревью как дизайн-ритуал
Простая практика: дизайнер показывает макет и задаёт вопрос:
«Представь, что тебя разбудили в три часа ночи и попросили оплатить заказ. Сможешь за 5 секунд понять, что делать?»
Если команда начинает спорить – макет на доработку.
Прототипы и быстрые тесты
Простой тест из трех вопросов для самопроверки:
- Понимаешь ли ты, где находишься?
- Что от тебя хочет система?
- Очевидно ли, куда ведет главная кнопка?
Если дизайнер затрудняется ответить хотя бы на один из этих вопросов, макет упрощается.
Трезвый взрослый в комнате
Спойлер: речь про дизайн-систему.
Проектировщик запрещает пользователю одной кнопкой снести половину данных, а дизайн-система запрещает проектировщику придумывать каждый раз новый способ это сделать.
Дизайн-система — это:
- единые паттерны кнопок, форм, уведомлений;
- понятные правила, как выглядит главное действие, вторичное, опасное;
- ограничения на «самодеятельность» на каждом новом экране.
Чем меньше рандома, тем проще пользователю — в любом состоянии.
Подведем итоги
Чтобы развеять барное впечатление о 2nights: мы не пьём (по будням) и никого не призываем. Километрового текста «минздрав предупреждает» не будет.
Но мы искренне рекомендуем задуматься о том, что DDD — drunk-driven design — реально заботится о конечных пользователях, уважая их самое уязвимое состояние.
Если интерфейс проходит drunk-тесты — это хороший интерфейс.
А хороший интерфейс — это тот, который комфортен людям в обычной жизни, когда вокруг дедлайны.