В России окончательно заблокировали Телеграм. Чтобы он продолжил работать, нужен либо VPN (сложный путь) либо SOCKS5-прокси (простой путь). Я выбираю простой. Есть готовые прокси, но если вы хотите поднять собственный — вот как это сделать.

Прежде всего, потребуется виртуальный сервер. Я лично предпочитаю Digital Ocean (реферальная ссылка, по которой бесплатно дают $10 — хватит на 2 месяца). Но можно попробовать другие облака, у которых есть бесплатные микро-сервера:

• Amazon EC2
• Google Cloud Platform
• Microsoft Azure

В качестве операционной системы я выбрал Ubuntu 16.04. Рекомендую отключить вход под рутом и настроить сертификат — вот инструкция.

Когда виртуальный сервер готов, заходим на него по SSH и устанавливаем SOCKS5-сервер Dante:

sudo apt update
sudo apt install -y dante-server

В убунте ставится древняя версия Данте — 1.1.19. Но её вполне достаточно.

Настраиваем Данте в файле /etc/danted.conf. Редактировать проще всего программой nano:

sudo nano /etc/danted.conf

Удаляем содержимое и вставляем свой конфиг:

logoutput: stderr
internal: eth0 port = 1080
external: eth0

method: username
user.privileged: root
user.notprivileged: nobody
user.libwrap: nobody

client pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    log: error
}

pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    log: error
}

Выходим из редактора с сохранением: Ctrl+O, затем Enter, затем Ctrl+X

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

sudo useradd --shell /usr/sbin/nologin telegram
sudo passwd telegram

Запускаем Данте:

sudo systemctl restart danted

Готовим ссылку для автоматической настройки телеграма:

tg://socks?server=IP_АДРЕС&port=1080&user=telegram&pass=ПАРОЛЬ

Вместо «IP_АДРЕС» подставьте IP-адрес сервера, а вместо «ПАРОЛЬ» — пароль пользователя, которого создали чуть раньше.

Скидываем ссылку в личный чат в телеграме (Saved Messages), тыкаем на неё и соглашаемся применить настройки. Всё, телеграм работает через прокси.

Я предложил читателям телеграм-канала «интерфейсов без шелухи» такую задачку:

Спасибо всем, кто прислал свои варианты! Давайте разберём решение. Начнём с исправления проблем в существующем интерфейсе, а закончим альтернативными вариантами.

Будем исходить из того, что и личное фото, и фото паспорта действительно нужны сервису (допустим, юристы требуют). В противном случае решение было бы слишком простым ツ

Редизайн: личное фото

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

Сначала кажется, что инструкция предельно понятна: «загрузите личное фото». Полагаю, надо ткнуть на изображение камеры и сделать селфи. Но зачем тогда внизу кнопка «добавить фото»? Из текста под заголовком становится понятно, что можно загрузить уже готовое фото.

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

В поясняющем тексте было много мусора. «Пожалуйста» лишнее, «для продолжения регистрации» — тоже. Требование загрузки в формате .jpg — просто абсурд. А поскольку мы убрали вариант с загрузкой, от пояснения удалось целиком избавиться.

Редизайн: фото паспорта

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

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

Крестик удаления фото микроскопический — сложно будет попасть пальцем. Да и зачем удалять фотографию? Если получилась неудачная, можно просто переснять.

Исправляем:

Альтернатива: отдельные экраны

С первым экраном (личное фото) есть проблема: он предлагает лишнее действие. Можно без потери смысла фотографировать сразу на нём. Тогда логично и фото паспорта разнести по отдельным экранам. Такой вариант предложил Алексей Демьяновских (макеты участника с моими правками):

Альтернатива: длинный экран

Возможно, при регистрации помимо фотографий требуются и другие данные. Если приложение не умеет распознавать текст с фотографий, то придётся указывать и ФИО, и дату рождения, и номер-серию паспорта вручную. Это значит, что получается минимум три экрана: текстовые данные, личное фото, фото паспорта.

Можно упаковать всё в один длинный экран. Чуть менее наглядно, но зато сразу видно всё, что требует приложение для регистрации. И легко вернуться к предыдущему шагу. Пример из приложения Belka Car:

Ну или хотя бы сделать общий экран с фотографиями. Макет прислал анонимный участник:

Если оставлять отдельные экраны, хорошо бы добавить индикатор прогресса («шаг 2 из 3»). На это указали многие участники, а Антон Лютиков отрисовал весь сценарий:

Альтернатива: чат

Олег Бухтияр обратил внимание на вариант с «чат-ботом», который использует Яндекс.Драйв:

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

• невозможно вернуться к предыдущему шагу,
• непонятно, сколько ещё шагов впереди.

Бизнес-логика: пропустить шаги

Слава Соколов справедливо заметил:

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

Если разработчики не готовы «пустить» человека в приложение до проверки паспорта, стоит хотя бы сохранять уже введённые данные — и не требовать их, когда пользователь через два дня вернётся с паспортом.

⌘ ⌘ ⌘

Было ещё несколько предложений, которые не кажутся мне удачными:

• Брать личное фото из паспорта. Паспорт действует 25 лет и больше, люди на фото мало похожи на себя нынешних. Да и фото там так себе. Если брать откуда-то готовое фото, я бы скорее предложил соцсети (заодно и ФИО получаешь автоматом).
• Регистрация через Госуслуги (ЕСИА). Вообще, идея богатая. Коммерческие компании действительно могут использовать «Единую систему», чтобы идентифицировать пользователей (причём это юридически значимая идентификация). Но пока на Госуслугах зарегистрировано только 50% взрослого населения (в 2018 собираются довести до 70%). Так что регистрация через Госуслуги как единственный вариант не подойдёт.

Ещё раз спасибо всем участникам! Мы продолжим ツ

Мне иногда пишут «ты вот топишь за хорошие интерфейсы, а что толку — менеджмент всё равно всегда выбирает какаху, лишь бы подешевле».

Кажется, тут недопонимание.

На самом деле, нет выбора между «божественно прекрасный интерфейс задорого» и «самое убогое во вселенной отстоище задёшево». Обычно есть как минимум такие варианты:

1. Сделать плохо, потратив N ресурсов.
2. Сделать нормально, потратив те же N (или чуть больше) ресурсов.
3. Сделать отлично, потратив k*N ресурсов.

Понимать принципы создания хороших интерфейсов стоит хотя бы для того, чтобы видеть вариант 2. Иначе вы остаётесь только со «сделать плохо».

Действительно, далеко не всегда вы пойдёте по варианту 3 — потому что есть ограничения и есть приоритеты. Но почти никогда не останетесь с вариантом 1, потому что между «сделать плохо» и «сделать нормально за те же деньги» адекватный менеджер всегда выберет «сделать нормально».

На днях прочёл «Додо-книгу» — принципы ведения бизнеса от одноименной компании. Это был бы обычный занудный сборник в стиле «надо делать хорошо и не надо плохо», если бы не примеры. Каждая глава — история из жизни сотрудника компании. Истории показывают внутреннюю кухню. Истории объясняют, откуда взялся каждый принцип и чем он полезен. В результате читать интересно.

Для меня лучшая формула обучения чему угодно — «порция теории + вагон примеров». Забавно, что при этом для большинства преподавателей (да и вообще профессионалов) выдать примеры — огромная трудность.

Любой спец с лёгкостью напишет, как «лучше быть богатым и здоровым, чем бедным и больным» — но заскрипит на примерах. Если попросить профи написать статью — он изложит десяток хороших и правильных принципов, и в лучшем случае один натужный пример (хорошо если не выдуманный).

Я думаю, что успех рассылок и курсов Ильяхова именно в том, что он всегда и всё подаёт на примерах. То же самое в других хороших курсах — например, «Аналитике для предпринимателей» Алексея Куличевского или «Better Web Type» Матея Латина. То же самое стараюсь делать и я в «Интерфейсах для нормальных людей».

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

Кажется, от примеров выигрывает всё что угодно ツ

Мотивация усиливается по мере приближения к цели. Особенно хорошо это работает, если человек видит прогресс.

Продукты и сервисы вовсю этим пользуются. Хрестоматийный пример — LinkedIn с его «прогрессом заполнения профиля», но вообще приём используется повсеместно. Даже на форме заявки на кредитку пишут «шаг 1 из 4» — это тоже визуализация прогресса.

Приём работает при одном условии — человек понимает, в чём награда. Прогресс сам по себе не особо мотивирует, если я не понимаю, что получу взамен.

Яркий анти-пример — приложение заказа такси Gett. У них есть программа лояльности со статусами вроде «суперзвезда», «вожак стаи» и «босс». Но статусы ничем не отличаются, кроме названия и количества очков, которые надо набрать.

Так было несколько лет. Потом, похоже, кто-то в Gett заметил, что программа лояльности никого не делает лояльнее, и задумался о наградах. И придумал «скидку в часы пик».

И теперь эту скидку написали всем статусам выше определённого уровня. Одну и ту же ツ Но если награда везде одна и та же — это всё равно что её нет.

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

Наткнулся на классную, судя по всему, книгу — Tragic Design. Об ошибках в дизайне, которые калечат и убивают — и о том, как их избежать.

Вторая глава с захватывающим названием «Design Can Kill» есть в открытом доступе. Там разобраны 4 ситуации, когда ошибки в интерфейсе продукта привели к фатальным последствиям:

• Аппарат для лучевой терапии, которые стрелял в пациентов направленным пучком в 17000 рад (в 85 раз больше нормальной дозы).
• Паром, у которого «газ» и «тормоз» менялись местами в зависимости от режима (вспоминается классическое программистское «define TRUE FALSE»).
• Автомобиль, который блокировал двери и загорался при ударе сзади — и убил таким способом 180 человек.
• Самолёт, который влетел в гору, потому что путал градусы с вертикальной скоростью.

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

Design Can Kill

Есть такая штука — офбординг (offboarding). Это то, как продукт ведёт себя, когда взаимодействие с пользователем закончилось:

• человек уходит с сайта, ничего не купив;
• человек отменяет подписку на сервис;
• человек оформил заказ.

Как видно, расставание может быть на «позитиве» (оформил заказ) или на «негативе» (отменил подписку). В любом случае, маркетологам и дизайнером не хочется, чтобы продукт в этот момент стоял истуканом. И чаще всего — правильно не хочется.

Что делать при офбординге — зависит от конкретной ситуации. Я думаю, что достаточно руководствоваться одним вопросом:

Что сейчас важно для человека?

Допустим, покупатель оформил заказ в магазине. Что ему важно? Понять, чего ждать дальше. Отвечаем:

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

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

Вы приобрели подписку на сервис подсказок DaData.ru, тариф «Лёгкий». Вот инструкция по настройке

Если возникнут вопросы, пишите в службу поддержки, будем рады ответить.

Или человек отписался от рассылки. Что ему важно? 1) чтобы не выносили мозг и 2) облегчить душу, если он зол. Отвечаем:

Вы отписались от рассылки и больше не получите наших писем. Если мы чем-то вас рассердили — пожалуйста, дайте знать:
┌───────────────────┐
  место для гневного сообщения
└───────────────────┘

Или вот: человек уходит с сайта, ничего не купив. Что ему важно? Чтобы не мешали. Поэтому не делаем ничего. И конечно же, не тыкаем в него попапом с предложением невероятной скидки (привет маркетологам).

⌘ ⌘ ⌘

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

Ответить на важные вопросы или молча отпустить

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

Но проблема в другом — многие специалисты не дают себе труда разобраться в контексте проблемы.

Пример: медленно работает программа. Раньше уже были проблемы с базой данных, поэтому первым делом бегут к администратору БД. Тот смотрит и говорит:

С базой всё в порядке, проблемы в приложении, идите к разработчикам.

А потрать он пять минут и вникни в контекст, ответ мог быть таким:

Смотрите — вот этот запрос, хотя сам по себе выполняется моментально, за день был выполнен 2 000 000 раз. Может это и нормально, но выглядит странно — имеет смысл показать разработчикам.

Или таким:

80% времени на базе выполняются вот эти 5 запросов. Обратите внимание разработчиков на них.

Конечно, иногда на вникание в контекст может потребоваться время, которого просто нет. Тогда ответ мог бы быть таким:

С базой всё хорошо, и явных проблем с запросами я не вижу. Если разработчики всё же сочтут, что причина «тормозов» в базе, я могу вместе с ними подробно проанализировать профиль нагрузки и предложить варианты решения. На это потребуется N времени.

Хочу чаще встречать специалистов, которые вникают в контекст.

Возможно, вы слышали о грандиозном UX-провале на Гавайях: там из-за плохого интерфейса оператор ошибся и отправил жителям оповещение о ракетном ударе (с милым дополнением «ЭТО НЕ УЧЕБНАЯ ТРЕВОГА»).

По этому поводу Гавайи и плохие интерфейсы простебали уже все кому не лень. Из основных проблем выделяют визуальную схожесть кнопок тестовой и реальной тревоги, плохое подтверждение действия и не-сценарность интерфейса (он выглядит просто как свалка ссылок).

Но главная беда, на мой взгляд, такая:

Нет отмены ошибочной операции

Кажется, у необратимых операций всегда должна быть отмена. Это контринтуитивно (мол, какая же отмена, если операция необратимая). Но именно таким операциям и нужна отмена.

Простейший способ добавить отмену необратимого действия — выполнять его не по факту нажатия на кнопку, а отложенно, через N секунд. Обычно человек моментально понимает, что сделал что-то не то — и успевает отменить. Если вы когда-нибудь по ошибке отправляли письмо не тому человеку, то знаете, как это бывает ツ

Два самых распространённых «необходимых зла» в интерфейсе — регистрация и оплата.

• зло — потому что пользователю они не нужны, у него другая задача;
• необходимое — потому что без них не получить результат.

Когда работаешь со «злом», главное — минимизировать боль и сохранить контекст.

Минимизировать боль

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

Плохая регистрация

Хорошая

Из оплаты всё не выкинешь, но можно оставить только платёжные реквизиты:

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

Сохранить контекст

После того, как человек закончил с регистрацией или оплатой, хороший интерфейс вернёт его ровно туда, где он до этого остановился.

Регистрация должна возвращать на тот же экран, но актуализировать состояние интерфейса:

До регистрации

После регистрации

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

Если после оплаты человека выкинет на главную страницу или в начало сценария — это не дело. Лучше продолжить сценарий с той точки, где отвлеклись на оплату:

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

⌘ ⌘ ⌘

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

Правила для таких ситуаций одни и те же:

Минимизировать боль и сохранить контекст

Люди любят объяснять провалы «техническими причинами»:

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

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

Поезда ходят с интервалом 5–10 минут.
Платежи картой заработают 25 января.
Часы работы: 10–18

Но если уж так хочется объяснять проблемы «причинами», предлагаю включать фантазию:

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

Даже сделал специальный сервис для этого:

Генератор причины провала

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

Когда-то Хром (самый популярный браузер, на Андроиде работает по умолчанию) показывал такие запросы в маленькой всплывашке, которая не особо мешала работать с сайтом.

Потом команда Хрома исследовала вопрос и обнаружила: 90% запросов на пуш-оповещения люди игнорируют.

Какой вывод из этого сделал бы рядовой обыватель:

Пуш-оповещения никому не нужны, давайте их отключим.

Какой вывод сделала команда блестящих инженеров и дизайнеров Гугла:

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

С тех пор Хром показывает запрос на пуш-оповещения в модальном окне, которое блокирует работу, пока человек не выберет — разрешить или нет.

Гениально.

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

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

Банки в СМС-оповещениях не делают разницы между блокировкой и списанием (может и правильно), потому присылают «с карты списано NNN рублей».

Если клиент пользуется услугой в первый раз, он начинает вибрировать: «ничего не сделали, а деньги уже списали, кидалы, а-а-а». Начинаются нервные звонки в поддержку и ругань в соцсетях. Ситуация проясняется, но осадок остаётся.

А избежать неприятных последствий просто: достаточно объяснить человеку, что происходит. Например, Qlean присылает такую СМС:

Конечно, на самом деле это не «всего лишь проверка». 50% суммы они спишут в любом случае, даже если отменить уборку (в качестве штрафа).

Но эти нюансы в СМС не объяснишь, да и до штрафа дело доходит редко. А так клиент спокоен, доволен, и не отвлекает поддержку.

Как писать в интерфейсе по-человечески

Если пользователь не понимает, что происходит, он бесится. Когда пользователь бесится, подходят самые разные нехорошие вещи. Лучше его не злить.

Лучший способ не злить пользователя: в любой потенциально непонятной ситуации объяснять, что происходит и чего ожидать.

Как это сделать:

1. Заметить, что вот этот конкретный экран, шаг или событие в интерфейсе плохо понятен. Если проводите юзабилити-тесты, такие участки заметны по вопросам «это чё», «что за фигня произошла» и «что мне с этим делать». Если не проводите — включите эмпатию или покажите коллеге.

2. Объяснить происходящее вслух, как объяснили бы хорошему знакомому. Прямо проговорить. Начните с универсального «ну бл*, короче» — чтобы снять писательский блок. Запишите объяснение на диктофон.

3. Сделать выжимку самого главного и записать. Короткий вариант пойдёт в виде надписи в интерфейсе. Длинный — в виде статьи в базе знаний.

Готово, вы восхитительны.

P.S. Есть нюанс. Иногда разрулить непонятность лучше не дополнительным объяснением, а наоборот: убрать лишнее или вовсе перепроектировать участок интерфейса. Но на то и дизайнер, чтобы отличать такие ситуации, верно?

Программы часто хотят лишнюю информацию от людей. Пол, почтовый индекс, ИНН — всякое такое.

Иногда эта информация вовсе не нужна (просто бизнес собирает «чтобы было»). Иногда — реально используется. Но даже в этом случае кучу сведений можно получить автоматически, не дёргая человека.

Например:

• Пол по ФИО.
• Индекс, район города, ближайшее метро и почтовое отделение по адресу.
• Все реквизиты компании по названию или ИНН.
• Страну, оператора связи и часовой пояс по телефону.
• Банк по номеру карты.
• Аватарку по емейлу.

Большинство данных легко получить из готовых API (Яндекс, Гугл, Дадата, ...). Какие-то можно скачать в машиночитаемом виде и приделать самостоятельно.

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

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