Необратимые действия

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

  • отправка e-mail, СМС и прочего;
  • удаление чата;
  • удаление профиля и т.п.

Обычно перед таким действием система спрашивает: Вы уверены?
Но люди не читают, не думают наперёд, торопятся и всё равно делают необратимое действие, а потом ищут способ восстановить.
На одном b2b проекте представитель заказчика просил добавить в систему двойной вопрос на удаление:
- Вы уверены?
<Да>
- Вы точно уверены?

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

Но есть действия, которые пользователь выполняет часто и "задалбывать" его вопросами про уверенность — лишний шаг.
Приличные продукты для таких необратимых действий делают возможность оперативной отмены по горячим следам.
Например, при отправке письма в gmail можно отменить отправку по-быстрому (временем отмены можно управлять).
Или при удалении чата в Телеге можно отменить удаление в течение 5 секунд.

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

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

2. Если действие необратимо и вы решили спрашивать подтверждение — спрашивайте максимально чётко с донесением последствий действий. У меня есть отдельная мини-заметка (https://telegra.ph/UX-neobratimyh-processov--pro-udalenie-04-17) про это.

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

Core Protocols

Когда я пришел в ManyChat, я первый раз услышал про LeSS и пошел читать методичку. А в методичке по LeSS я наткнулся на отсылку к Core Protocols, про которые не слышал раньше, и тоже пошел читать про них.

И если вкратце, Core Protocols — это система фасилитационных техник, направленных на улучшение коммуникации внутри команд.

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

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

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

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

Я их переведу на русский со своими комментариями, и если вы найдете более емкие формулировки, то пишите, я дополню/исправлю:

1) Я обязуюсь участвовать, когда присутствую
Это про то, что если участвуешь во встрече, то участвуешь, а не залипаешь в ноутбуке. Дополнительно расширяется на личную внутреннюю осознанность. Если что-то делаешь, то понимаешь зачем.

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

3) Я буду использовать команды, особенно при выполнении сложных задач
Это про помощь. Ты должен пользоваться всеми видами помощи, которые можешь получить от людей вокруг, а не пытаться супергеройски вытащить проект, перегореть и уволиться.

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

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

6) Я буду избегать непродуктивных ситуаций
Если понимаешь, что 23 встречи в неделю не приводят к результату, отмечаешь это, и стараешься не участвовать им, не мешая при этом другим.

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

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

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

10) Я никому не причиню вреда—и не потерплю причинения вреда—за его или ее верность этим обязательствам
Если закомитились на core protocols, то не нужно закатывать глаза и проявлять агрессию (даже пассивную), когда тебе кто-то подсветил, что ты наваливаешь не в ту сторону.

11) Я никогда не буду делать ничего глупого нарочно
Вот да!

Это только верхушка, в следующий раз посмотрим на сами коммиты.

Вообще очень рекомендую прочитать оригинал текста с коммитами вот здесь — https://liveingreatness.com/core-protocols/the-core-commitments/

Аутсорс-дизайн

Аутсорс-дизайн

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


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


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


3. Ниндзя-дизайнеры.
В аутсорсе ты либо работаешь в том промежутке времени, в который сам оценил проект, либо уходишь в минус по деньгам.
Значит нужны люди, которые быстро во все въезжают(а каждые 4 месяца — новый проект), которые не прокрастинируют, которым не нужно нетворкаться 2/3 времени, которые не уходят в творческий кризис на неделю.
Которые за сжатые сроки делают охуенно и не устают от динамики студии.
Таких на рынке единицы. И, получается, что требования у нас завышенные. И те кто нам по этим критериям не подошёл — просто шикарны для продуктовых процессов.


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

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

А нет, не с другой стороны, всё с той же. 😂

Презентация CMO Яндекс.Такси Даши Золотухиной

Одна из проблем, с которой борется команда маркетинга Я.Такси — перераспределение трафика между брендами и каналами (каннибализация). Суть — у бизнеса есть 2 сильных бренда (Я.Такси и Убер). Нужно научиться правильно распределять трафик между ними. Кроме того, есть десятки каналов привлечения трафика и нужно понять какие из этих каналов приводят новых пользователей, а не просто "воруют" органический трафик.

Предложенные решения:

  • разное позиционирование для брендов. Например, Uber для более молодых. Запуск и продвижение тарифа Uber Night привел к росту(+55%) ночных поездок и увеличил (+32%) узнаваемость среди ЦА.
  • сделать списки ремаркетинга отвалившихся клиентов одного бренда и предложить им второй бренд,
  • плановое (в несколько этапов или несколько партнеров) отключение рекламной закупки для снижения каннибализации в платном трафике

Интересная информация:

  • более 50% пользователей мультиаппят (используют несколько приложений для вызова такси),
  • конверсия в первую поездку Uber через канал Тик-Ток - 41%,
  • дождь приносит до +22% рост органики в Я.Такси.

Как писать сообщения об ошибках

Как писать сообщения об ошибках

Есть простой шаблон:
В заголовок — что призошло
Основным текстом — причина и что делать дальше
Кнопкой — действия
Код ошибки, если необходим

Заголовок должен быть понятным и человечным. Задача — сразу сообщить, что ключевое действие не было выполнено. Люди читают заголовок первым и он сразу должен объяснить что произошло.

Если пользователь отправлял письмо, а оно не отправилось, то так и пишем: Письмо не отправлено

Хорошо:
✅ Не удалось загрузить сообщения
✅ Фотографии не отправлены
✅ Платёж не прошел

Плохо:
❌ Что-то пошло не так
❌ Ошибка!
❌ Память не может быть read

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

✅Хорошо для простого человека:
Не удалось сохранить документ. Документ слишком большой. Уменьшите размер документа до 800 символов или разбейте на части.
Разбить на 3 части
Закрыть

✅Хорошо для профессионала.
Не удалось сохранить документ. Размера файла подкачки не хватает для сохранения. Увеличьте размер файла подкачки до 1 ГБ или уменьшите размер вашего документа до 800 символов.
Увеличить файл подкачки
Разбить на 3 части
Закрыть

❌ Плохо:
Не писать причину
Писать профессиональным языком для непрофессионалов

Если причина неизвестна, то можно так и писать: Ошибка произошла по неизвестной причине. Помогите нам разобраться, отправьте отчёт.

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

✅Хорошо
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Позвонить в службу поддержки
Написать в службу поддержки
Закрыть

❌Плохо:
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Закрыть

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

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

Брюс Стерлинг о пользе написания дизайн-фантастики

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

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