Задачка: вахтёр
По моим наблюдениям, разработчики (и дизайнеры, в меньшей степени) очень любят запрещать. Я это называю «синдром айти-вахтёра».
Например, есть известная коллективная блог-площадка. Там можно голосовать за статьи, и если случайно ткнуть на голосовалку дважды, получаешь суровое:
> Повторное голосование запрещено
А если нажать много раз — будет чудесная картина, которая изображена на скриншоте. Присмотритесь, у каждого сообщения есть собственный прогресс-бар обратного отсчёта. Инженерный дизайн ツ
Как бы вы поступили с этим сообщением?
По моим наблюдениям, разработчики (и дизайнеры, в меньшей степени) очень любят запрещать. Я это называю «синдром айти-вахтёра».
Например, есть известная коллективная блог-площадка. Там можно голосовать за статьи, и если случайно ткнуть на голосовалку дважды, получаешь суровое:
> Повторное голосование запрещено
А если нажать много раз — будет чудесная картина, которая изображена на скриншоте. Присмотритесь, у каждого сообщения есть собственный прогресс-бар обратного отсчёта. Инженерный дизайн ツ
Как бы вы поступили с этим сообщением?
Что сделаете с «повторное голосование запрещено»?
Final Results
2%
Всё нормально, оставлю так
6%
Оставлю, но только одно
15%
Переформулирую в позитив
9%
Уберу текст, покажу визуально
68%
Задизейблю кнопку, если уже есть голос
Разбор: вахтёр
Приятно видеть такое единодушие ツ Разберём все же варианты:
Всё нормально, оставлю так
Понимаю, жаль отказываться от такой красоты. Там целая система! Мало того, что у каждого сообщения собственный обратный отсчёт. Так ещё если сообщений больше 5, то дополнительные становятся в очередь и выскакивают только после того, как закрылись предыдущие. Кто-то явно потрудился над этим ツ
Но всё же для пользователя сообщение бесполезно.
Переформулирую в позитив
Формулировать сообщение об ошибке в позитиве («вы уже проголосовали» вместо «повторное голосование запрещено») — хорошая мысль, если сообщение действительно нужно. Здесь оно ничем не помогает, так что смысла нет.
Уберу текст, покажу визуально
Подходящий способ для валидации обязательного поля на форме, например. Здесь же нет пользовательской ошибки, повторное голосование никому не мешает, так что сигнализировать о нём не стоит.
Задизейблю кнопку, если уже есть голос
Простой и рабочий вариант. Если человек уже проголосовал «в плюс», то дальнейшие тыки на кнопку можно спокойно игнорировать. Нет ошибки, нет проблемы, все счастливы.
При этом визуально кнопка не должна дизейблиться (становиться серой) — чтобы не смущать человека. Достаточно деактивировать её, то есть игнорировать повторные нажатия.
Снимать голос при повторном тыке
Этот вариант предложили в личке. Мне он не очень нравится. Если бы действие было одно (как лайк в фейсбуке) — да, логично, при повторном нажатии отменять его (снимать лайк).
Но тут в интерфейсе два раздельных действия (плюс и минус). И снимать плюс при повторном нажатии на плюс — нелогично.
Приятно видеть такое единодушие ツ Разберём все же варианты:
Всё нормально, оставлю так
Понимаю, жаль отказываться от такой красоты. Там целая система! Мало того, что у каждого сообщения собственный обратный отсчёт. Так ещё если сообщений больше 5, то дополнительные становятся в очередь и выскакивают только после того, как закрылись предыдущие. Кто-то явно потрудился над этим ツ
Но всё же для пользователя сообщение бесполезно.
Переформулирую в позитив
Формулировать сообщение об ошибке в позитиве («вы уже проголосовали» вместо «повторное голосование запрещено») — хорошая мысль, если сообщение действительно нужно. Здесь оно ничем не помогает, так что смысла нет.
Уберу текст, покажу визуально
Подходящий способ для валидации обязательного поля на форме, например. Здесь же нет пользовательской ошибки, повторное голосование никому не мешает, так что сигнализировать о нём не стоит.
Задизейблю кнопку, если уже есть голос
Простой и рабочий вариант. Если человек уже проголосовал «в плюс», то дальнейшие тыки на кнопку можно спокойно игнорировать. Нет ошибки, нет проблемы, все счастливы.
При этом визуально кнопка не должна дизейблиться (становиться серой) — чтобы не смущать человека. Достаточно деактивировать её, то есть игнорировать повторные нажатия.
Снимать голос при повторном тыке
Этот вариант предложили в личке. Мне он не очень нравится. Если бы действие было одно (как лайк в фейсбуке) — да, логично, при повторном нажатии отменять его (снимать лайк).
Но тут в интерфейсе два раздельных действия (плюс и минус). И снимать плюс при повторном нажатии на плюс — нелогично.
Юлия → Iuliia. Всё о транслитерации
Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.
В интерфейсах транслитерацию обычно реализуют как придётся. Взял программист первую попавшуюся в гугле библиотеку (или ещё хуже — сделал свою) и вперёд.
Я недавно окунулся в эту тему, а в Википедии она раскрыта слабо. Поэтому расскажу, что к чему (спойлер — если вы думаете, что с транслитерацией всё плохо, то на самом деле всё ещё хуже).
Как обстоят дела и что с этим делать:
https://antonz.ru/iuliia/
Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.
В интерфейсах транслитерацию обычно реализуют как придётся. Взял программист первую попавшуюся в гугле библиотеку (или ещё хуже — сделал свою) и вперёд.
Я недавно окунулся в эту тему, а в Википедии она раскрыта слабо. Поэтому расскажу, что к чему (спойлер — если вы думаете, что с транслитерацией всё плохо, то на самом деле всё ещё хуже).
Как обстоят дела и что с этим делать:
https://antonz.ru/iuliia/
Простой интерфейс
Ещё до того, как пользователь в первый раз запустил программу, у него в голове уже сложилось представление, как она работает.
Если обмануть ожидания — человек будет воспринимать интерфейс как сложный, что вы с ним ни делайте. Не поможет ни онбординг, ни обучающие ролики, ни красочные картинки и игривый текст.
А вот как не обмануть:
https://antonz.ru/simple-ui/
Ещё до того, как пользователь в первый раз запустил программу, у него в голове уже сложилось представление, как она работает.
Если обмануть ожидания — человек будет воспринимать интерфейс как сложный, что вы с ним ни делайте. Не поможет ни онбординг, ни обучающие ролики, ни красочные картинки и игривый текст.
А вот как не обмануть:
https://antonz.ru/simple-ui/
Как человек решает задачи в интерфейсе
Человек взаимодействует с интерфейсом не для того, чтобы насладиться творчеством дизайнеров и программистов. Он решает конкретную задачу. Происходит это в три шага:
1. Сформулировать задачу. Я подписан на один канал в Телеграме. Он хороший, но надоел оповещениями. Хочу их отключить.
2. Выполнить действие. Полагаю, это делается где-то в самом канале. Захожу в ленту, тыкаю на канал. Вижу внизу большую кнопку Mute. Ага, это наверняка она. Нажимаю.
3. Оценить результат. Кнопка изменилась: Mute → Unmute. Рядом с названием канала появилась иконка с перечёркнутым динамиком. Полагаю, оповещения выключены.
На каждом шаге интерфейс может помогать, а может вставлять палки в колёса. Вот как это бывает:
https://antonz.ru/user-actions/
Человек взаимодействует с интерфейсом не для того, чтобы насладиться творчеством дизайнеров и программистов. Он решает конкретную задачу. Происходит это в три шага:
1. Сформулировать задачу. Я подписан на один канал в Телеграме. Он хороший, но надоел оповещениями. Хочу их отключить.
2. Выполнить действие. Полагаю, это делается где-то в самом канале. Захожу в ленту, тыкаю на канал. Вижу внизу большую кнопку Mute. Ага, это наверняка она. Нажимаю.
3. Оценить результат. Кнопка изменилась: Mute → Unmute. Рядом с названием канала появилась иконка с перечёркнутым динамиком. Полагаю, оповещения выключены.
На каждом шаге интерфейс может помогать, а может вставлять палки в колёса. Вот как это бывает:
https://antonz.ru/user-actions/
Аптайм на статус-странице
Есть такая штука у облачных сервисов — «статус-страница». Это отдельный, независимый от основного сайт, на котором написано, работает основной сервис или нет.
Статус-страница полезна, когда основной сервис свалился под ддос-атакой или от веселого пятничного обновления. Так пользователям есть куда пойти, чтобы понять масштаб проблемы и ход решения.
У большинства сервисов статус-страница сделана по такому шаблону:
1. Общий статус (работает / нет)
2. Статус отдельных сервисов (сайт, мобильное приложение, API, ...)
3. Список инцидентов.
Неплохая структура, отвечает на важный вопрос — «что-то сломалось?» Но не отвечает на второй важный вопрос — «насколько вы вообще надежные?».
Удивительно, но сервисы редко раскрывают общие показатели доступности. Хорошо, если покажут за 90 дней, за год — почти никогда.
Я думаю, нормальный подход — показывать доступность за день, неделю, месяц и год.
В любом случае, даже плохая статус-страница лучше, чем никакой. Тем более, что подключить ее несложно — есть куча готовых инструментов. Даже бесплатные, вроде UptimeRobot или Upptime
Рекомендую!
Есть такая штука у облачных сервисов — «статус-страница». Это отдельный, независимый от основного сайт, на котором написано, работает основной сервис или нет.
Статус-страница полезна, когда основной сервис свалился под ддос-атакой или от веселого пятничного обновления. Так пользователям есть куда пойти, чтобы понять масштаб проблемы и ход решения.
У большинства сервисов статус-страница сделана по такому шаблону:
1. Общий статус (работает / нет)
2. Статус отдельных сервисов (сайт, мобильное приложение, API, ...)
3. Список инцидентов.
Неплохая структура, отвечает на важный вопрос — «что-то сломалось?» Но не отвечает на второй важный вопрос — «насколько вы вообще надежные?».
Удивительно, но сервисы редко раскрывают общие показатели доступности. Хорошо, если покажут за 90 дней, за год — почти никогда.
Я думаю, нормальный подход — показывать доступность за день, неделю, месяц и год.
В любом случае, даже плохая статус-страница лучше, чем никакой. Тем более, что подключить ее несложно — есть куча готовых инструментов. Даже бесплатные, вроде UptimeRobot или Upptime
Рекомендую!
Сила комментария
Комментарий в интерфейсе — это необязательное текстовое поле. В комментарии человек указывает любую дополнительную информацию, которая кажется ему важной:
— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге
Комментарии в интерфейсах недооценены. Аналитики, дизайнеры, программисты — все мы любим и умеем систематизировать информацию. Поэтому любой объект в интерфейсе представляем как набор полей с конкретным назначением: наименование, почтовый индекс, стоимость.
Но жизнь всегда богаче моделек. И когда люди используют софт, часто получается, что важная информация есть, а записать ее некуда. Тут и приходит на помощь комментарий.
Например, на работе мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?
Проблема в том, что непонятно, кто заблокировал IP и почему. В большинстве случаев это и неважно, но иногда пригодилось бы для разбора. Решить проблему элементарно — добавить поле «комментарий».
Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:
— точно ли нужны именно эти поля?
— действительно ли они нужны?
Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.
Комментарий — элемент хаоса. Но с ним система устойчивее.
Комментарий в интерфейсе — это необязательное текстовое поле. В комментарии человек указывает любую дополнительную информацию, которая кажется ему важной:
— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге
Комментарии в интерфейсах недооценены. Аналитики, дизайнеры, программисты — все мы любим и умеем систематизировать информацию. Поэтому любой объект в интерфейсе представляем как набор полей с конкретным назначением: наименование, почтовый индекс, стоимость.
Но жизнь всегда богаче моделек. И когда люди используют софт, часто получается, что важная информация есть, а записать ее некуда. Тут и приходит на помощь комментарий.
Например, на работе мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?
Проблема в том, что непонятно, кто заблокировал IP и почему. В большинстве случаев это и неважно, но иногда пригодилось бы для разбора. Решить проблему элементарно — добавить поле «комментарий».
Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:
— точно ли нужны именно эти поля?
— действительно ли они нужны?
Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.
Комментарий — элемент хаоса. Но с ним система устойчивее.
Более быстрая лошадь
Продуктоводы любят цитировать Генри Форда:
Если бы я спросил у людей, чего они хотят, они бы попросили более быструю лошадь [а не автомобиль]
Вывод делается такой, что пользователи, мол, сами не знают, чего им надо.
Кажется, в этой байке очень мало хорошего:
1. «Если бы спросил, они бы попросили». Да откуда ты знаешь? Спроси сначала — мало ли, вдруг ответы тебя удивят.
2. Допустим, реально ответили, что нужна «более быстрая лошадь». Это весьма полезная информация, только надо сфокусироваться на «быстрая», а не «лошадь». Почему важна именно быстрота, а не выносливость, комфорт или там стоимость владения? Что смогут они такого делать, чего раньше не могли? Сразу возникают вопросы, которые помогут увидеть правильное направление.
3. Некоторые пользователи не то что про лошадь не станут рассказать, они сразу затребуют гоночный болид или вообще космический корабль для межзвездных путешествий. Это тоже ценная информация, особенно если за странными желаниями вскроется реальная потребность.
4. Средний продуктовод — далеко не Генри Форд (сорян). Не грех и спросить, корона не свалится.
В общем, я за другую цитату Форда:
Мой секрет успеха заключается в умении понять точку зрения другого человека и смотреть на вещи и с его, и со своей точек зрения.
Продуктоводы любят цитировать Генри Форда:
Если бы я спросил у людей, чего они хотят, они бы попросили более быструю лошадь [а не автомобиль]
Вывод делается такой, что пользователи, мол, сами не знают, чего им надо.
Кажется, в этой байке очень мало хорошего:
1. «Если бы спросил, они бы попросили». Да откуда ты знаешь? Спроси сначала — мало ли, вдруг ответы тебя удивят.
2. Допустим, реально ответили, что нужна «более быстрая лошадь». Это весьма полезная информация, только надо сфокусироваться на «быстрая», а не «лошадь». Почему важна именно быстрота, а не выносливость, комфорт или там стоимость владения? Что смогут они такого делать, чего раньше не могли? Сразу возникают вопросы, которые помогут увидеть правильное направление.
3. Некоторые пользователи не то что про лошадь не станут рассказать, они сразу затребуют гоночный болид или вообще космический корабль для межзвездных путешествий. Это тоже ценная информация, особенно если за странными желаниями вскроется реальная потребность.
4. Средний продуктовод — далеко не Генри Форд (сорян). Не грех и спросить, корона не свалится.
В общем, я за другую цитату Форда:
Мой секрет успеха заключается в умении понять точку зрения другого человека и смотреть на вещи и с его, и со своей точек зрения.
Начни с примера
Главное правило для всех, кто пишет обучающие статьи, курсы и вообще что угодно для начинающих:
>>> Начинайте с примеров, черт возьми <<<
Например, вы решили учить людей SQL. И первым делом подсовываете им такую замечательную схему SQL-запроса, как на картинке к посту. Не, ну а чо. Пусть сразу системному подходу учатся, правда?
Нет.
Начните с простых примерчиков. Расскажите про большую эксельку, которую можно фильтровать и сортировать. Покажите примитивные запросы на табличке из 10 записей. Нарисуйте элементарные картинки или сделайте гифку.
Не нужен начинающим «системный подход». Потом сами к нему придут.
Интересно, что на примере с базовым SQL почти все это понимают. Но стоит взять чуть более сложную тему — и привет. Начинают с многотомной классификации, зубодробительных схем внутреннего устройства и прочей жести. А примеры типа на потом оставим, когда «целостная картина» будет.
Не будет у людей целостной картины. Никакой картины не будет. Пока вы не начнете объяснять на примерах.
Главное правило для всех, кто пишет обучающие статьи, курсы и вообще что угодно для начинающих:
>>> Начинайте с примеров, черт возьми <<<
Например, вы решили учить людей SQL. И первым делом подсовываете им такую замечательную схему SQL-запроса, как на картинке к посту. Не, ну а чо. Пусть сразу системному подходу учатся, правда?
Нет.
Начните с простых примерчиков. Расскажите про большую эксельку, которую можно фильтровать и сортировать. Покажите примитивные запросы на табличке из 10 записей. Нарисуйте элементарные картинки или сделайте гифку.
Не нужен начинающим «системный подход». Потом сами к нему придут.
Интересно, что на примере с базовым SQL почти все это понимают. Но стоит взять чуть более сложную тему — и привет. Начинают с многотомной классификации, зубодробительных схем внутреннего устройства и прочей жести. А примеры типа на потом оставим, когда «целостная картина» будет.
Не будет у людей целостной картины. Никакой картины не будет. Пока вы не начнете объяснять на примерах.
Руководство по визуализации данных
Ребята из Германии сделали классное руководство по визуализации данных и открыли его под лицензией Creative Commons.
А чтобы никто не догадался и не оценил их труд — назвали максимально непонятно и спрятали на сайте в слабочитаемом виде.
Но я все равно нашел!
Поэтому теперь у вас есть бесплатная книга по визуальному представлению данных для отчетов и дашбордов. Подробная (150 страниц) и практическая (197 иллюстраций). В вебе, epub и pdf:
https://antonz.ru/dataviz-guide/
Ребята из Германии сделали классное руководство по визуализации данных и открыли его под лицензией Creative Commons.
А чтобы никто не догадался и не оценил их труд — назвали максимально непонятно и спрятали на сайте в слабочитаемом виде.
Но я все равно нашел!
Поэтому теперь у вас есть бесплатная книга по визуальному представлению данных для отчетов и дашбордов. Подробная (150 страниц) и практическая (197 иллюстраций). В вебе, epub и pdf:
https://antonz.ru/dataviz-guide/
Видение, эмпатия, смелость
Одиннадцать лет назад, весной 2010 года, Adobe Flash был на пике популярности. Adobe построил вокруг этого поделия аж целую платформу, с прицелом на мобильные устройства и встраиваемое ПО.
Флеш был так успешен, что Microsoft еще в 2007 году выкатила конкурента — аналогичную хреновину под названием Silverlight. Борьба намечалась нешуточная.
Apple, владея стремительно набирающей популярность iOS, не могла остаться в стороне. И анонсировала собственную альтернативу флешу — iSlate. Аналогичный шаг сделал и Google. В следующие 10 лет развернулась кровавая битва флешеподобных плагинов, а обычный веб (HTML и JS) остались совсем не у дел.
А, нет. Вычеркните последний абзац. Ничего этого не было, и вот почему.
29 апреля 2010 года Стив Джобс опубликовал открытое письмо под названием «Thoughts on Flash», в котором разгромил флеш и поддержал HTML5. В течение двух следующих лет Adobe Flash и Microsoft Silverlight были уничтожены. Технически они продолжали существовать еще довольно долго, но и разработчики, и сами производители признали, что это тупик.
HTML5, CSS и JS получили такой мощный пинок, что до сих пор не могут остановиться (вот кому мы обязаны мириадами глючных фич веба и армией js-фреймворков). При всех недостатках, веб действительно оказался лучшим выбором, потому что не принадлежал одному монополисту.
Заботился ли Джобс о процветании Apple, когда писал свое письмо? Конечно. Он честно сказал, что благодаря отмиранию флеша Apple продаст больше устройств. Но он также думал и о разработчиках, и о пользователях. Джобс понимал, что ждет нас всех, если индустрия пойдет по пути конкурирующих плагинов вместо развития общей платформы — веба.
Джобс не был ангелом, это уж точно. Но у него было видение, и эмпатия, и смелость. Не будь этого письма в 2010 году — не было бы веба, каким мы его знаем сегодня.
В 2020 году Apple тихо удалила открытое письмо Джобса с сайта компании. Конечно, зачем эти слова про открытый веб — у нынешнего Apple совсем другие приоритеты. Да и у других техногигантов тоже. Очень жаль.
Thoughts on Flash
Одиннадцать лет назад, весной 2010 года, Adobe Flash был на пике популярности. Adobe построил вокруг этого поделия аж целую платформу, с прицелом на мобильные устройства и встраиваемое ПО.
Флеш был так успешен, что Microsoft еще в 2007 году выкатила конкурента — аналогичную хреновину под названием Silverlight. Борьба намечалась нешуточная.
Apple, владея стремительно набирающей популярность iOS, не могла остаться в стороне. И анонсировала собственную альтернативу флешу — iSlate. Аналогичный шаг сделал и Google. В следующие 10 лет развернулась кровавая битва флешеподобных плагинов, а обычный веб (HTML и JS) остались совсем не у дел.
А, нет. Вычеркните последний абзац. Ничего этого не было, и вот почему.
29 апреля 2010 года Стив Джобс опубликовал открытое письмо под названием «Thoughts on Flash», в котором разгромил флеш и поддержал HTML5. В течение двух следующих лет Adobe Flash и Microsoft Silverlight были уничтожены. Технически они продолжали существовать еще довольно долго, но и разработчики, и сами производители признали, что это тупик.
HTML5, CSS и JS получили такой мощный пинок, что до сих пор не могут остановиться (вот кому мы обязаны мириадами глючных фич веба и армией js-фреймворков). При всех недостатках, веб действительно оказался лучшим выбором, потому что не принадлежал одному монополисту.
Заботился ли Джобс о процветании Apple, когда писал свое письмо? Конечно. Он честно сказал, что благодаря отмиранию флеша Apple продаст больше устройств. Но он также думал и о разработчиках, и о пользователях. Джобс понимал, что ждет нас всех, если индустрия пойдет по пути конкурирующих плагинов вместо развития общей платформы — веба.
Джобс не был ангелом, это уж точно. Но у него было видение, и эмпатия, и смелость. Не будь этого письма в 2010 году — не было бы веба, каким мы его знаем сегодня.
В 2020 году Apple тихо удалила открытое письмо Джобса с сайта компании. Конечно, зачем эти слова про открытый веб — у нынешнего Apple совсем другие приоритеты. Да и у других техногигантов тоже. Очень жаль.
Thoughts on Flash
О продуктоводстве
С начала года я окончательно перестал притворяться продакт-менеджером и занимаюсь исключительно техническими штуками. Кажется, это хороший момент, чтобы описать мой опыт создания и развития облачного B2B-сервиса в России.
О чем пишу:
— продукт и фичи
— B2B и кровавый энтерпрайз
— API и документация
— техподдержка
— разработка
— интерфейс
— люди
О чем не пишу:
— маркетинг
— метрики
— касдев
— гроус-хакинг
— эджайл
— что там еще модно у продактов в этом сезоне
https://antonz.ru/productology/
С начала года я окончательно перестал притворяться продакт-менеджером и занимаюсь исключительно техническими штуками. Кажется, это хороший момент, чтобы описать мой опыт создания и развития облачного B2B-сервиса в России.
О чем пишу:
— продукт и фичи
— B2B и кровавый энтерпрайз
— API и документация
— техподдержка
— разработка
— интерфейс
— люди
О чем не пишу:
— маркетинг
— метрики
— касдев
— гроус-хакинг
— эджайл
— что там еще модно у продактов в этом сезоне
https://antonz.ru/productology/
Как собрать данные из API без программирования
А я вам показывал, как парсить открытые API без программирования? Аккаунт на гитхабе + текстовый редактор + самая малость SQL = автоматически обновляемый датасет.
https://antonz.ru/github-actions-scraping/
А я вам показывал, как парсить открытые API без программирования? Аккаунт на гитхабе + текстовый редактор + самая малость SQL = автоматически обновляемый датасет.
https://antonz.ru/github-actions-scraping/
Что должно быть в письме о заказе
Если продаете товары с доставкой курьером — наверняка отправляете клиентам емейл или смс после того, как заказ оформлен. Все так делают.
Но не у всех это письмо полезно клиенту.
Плохо
Например, «Деликатеска» присылает жуткую простыню (см. картинку к посту).
Тут и правила всего на свете, и мое имя и телефон (спасибо, а то вечно забываю), и бесконечный список заказанных товаров (на скриншоте я его обрезал), и даже призыв защитить природу в финале. Все, кроме самого главного — когда я получу заказ. Формально дата и время в письме есть, но так затейливо спрятаны, что заметить их малореально.
У «Озона» нет простыни, но и даты доставки тоже нет. У «Яндекса» лучше, хотя акцент странный (см. скриншоты в полной версии заметки).
Лучше
Если письмо бестолковое — человеку все равно придется идти в личный кабинет и искать информацию там. Не делайте так. Если хотите, чтобы письмо пригодилось, напишите вот что:
Приняли заказ №12345, стоимость 5623 ₽, доставим в пятницу 16 июля с 10 до 14.
Если ваши айти-системы в состоянии идентифицировать товар без номера (по телефону, например) — можно номер не писать, станет еще лучше. Правда, может возникнуть путаница, если у человека несколько заказов одним днем.
Приняли заказ на 5623 ₽, доставим в пятницу 16 июля с 10 до 14.
Добавьте телефон, чтобы человек не искал, как с вами связаться:
Приняли заказ на 5623 ₽, доставим в пятницу 16 июля с 10 до 14. 8 800 223-23-23
Если есть ограничения по оплате, тоже напишите:
Оплата только наличными, у курьера нет сдачи.
Заказ оплачен, вот чек.
Такой формат одинаково подходит для емейла и смс. В смс достаточно этим и ограничиться. В емейле можно дальше дать больше подробностей:
— список товаров;
— как изменить время или отменить заказ;
— особенности (курьер звонит за час, доставка до двери и тому подобное).
Адрес доставки имеет смысл указывать, если у человека их несколько. ФИО и адрес эл. почты — если заказ для другого человека.
Итого
— номер (если без него никак);
— стоимость,
— дата и время,
— контактный телефон,
— важные ограничения.
Приняли заказ № 12345, стоимость 5623 ₽, доставим в пятницу 16 июля с 10 до 14. Оплата только наличными. 8 800 223-23-23
Такое сообщение действительно пригодится.
Если продаете товары с доставкой курьером — наверняка отправляете клиентам емейл или смс после того, как заказ оформлен. Все так делают.
Но не у всех это письмо полезно клиенту.
Плохо
Например, «Деликатеска» присылает жуткую простыню (см. картинку к посту).
Тут и правила всего на свете, и мое имя и телефон (спасибо, а то вечно забываю), и бесконечный список заказанных товаров (на скриншоте я его обрезал), и даже призыв защитить природу в финале. Все, кроме самого главного — когда я получу заказ. Формально дата и время в письме есть, но так затейливо спрятаны, что заметить их малореально.
У «Озона» нет простыни, но и даты доставки тоже нет. У «Яндекса» лучше, хотя акцент странный (см. скриншоты в полной версии заметки).
Лучше
Если письмо бестолковое — человеку все равно придется идти в личный кабинет и искать информацию там. Не делайте так. Если хотите, чтобы письмо пригодилось, напишите вот что:
Приняли заказ №12345, стоимость 5623 ₽, доставим в пятницу 16 июля с 10 до 14.
Если ваши айти-системы в состоянии идентифицировать товар без номера (по телефону, например) — можно номер не писать, станет еще лучше. Правда, может возникнуть путаница, если у человека несколько заказов одним днем.
Приняли заказ на 5623 ₽, доставим в пятницу 16 июля с 10 до 14.
Добавьте телефон, чтобы человек не искал, как с вами связаться:
Приняли заказ на 5623 ₽, доставим в пятницу 16 июля с 10 до 14. 8 800 223-23-23
Если есть ограничения по оплате, тоже напишите:
Оплата только наличными, у курьера нет сдачи.
Заказ оплачен, вот чек.
Такой формат одинаково подходит для емейла и смс. В смс достаточно этим и ограничиться. В емейле можно дальше дать больше подробностей:
— список товаров;
— как изменить время или отменить заказ;
— особенности (курьер звонит за час, доставка до двери и тому подобное).
Адрес доставки имеет смысл указывать, если у человека их несколько. ФИО и адрес эл. почты — если заказ для другого человека.
Итого
— номер (если без него никак);
— стоимость,
— дата и время,
— контактный телефон,
— важные ограничения.
Приняли заказ № 12345, стоимость 5623 ₽, доставим в пятницу 16 июля с 10 до 14. Оплата только наличными. 8 800 223-23-23
Такое сообщение действительно пригодится.
Задачка: письма о заказе
Представьте ситуацию. Вы работаете в крупном маркетплейсе. Люди делают на маркетплейсе заказы, он доставляет. А по факту доставки одного заказа присылает шесть писем (см. скриншот):
— Заказ доставлен
— Электронный чек по 1-й части заказа
— Электронный чек по 2-й части заказа
— Электронный чек по 3-й части заказа
— Электронный чек по 4-й части заказа
— Вы довольны доставкой?
При этом маркетплейс сам разбивает заказ на части, покупатель никак этим не управляет. В примере выше все части доставлены в один день, в одно время, одним курьером.
Некоторые покупатели почему-то недовольны таким количеством писем и жалуются в саппорт.
Ваши коллеги разводят руками — в заказе было 4 части, значит должно быть четыре чека. Потом, надо же уведомить о доставке, а то вдруг человек не в курсе. И уточнить, всем ли покупатель доволен (мы же клиентоориентированная компания). Вот и получается шесть писем. Ничего не поделаешь.
А вы что думаете? Опрос следует.
Представьте ситуацию. Вы работаете в крупном маркетплейсе. Люди делают на маркетплейсе заказы, он доставляет. А по факту доставки одного заказа присылает шесть писем (см. скриншот):
— Заказ доставлен
— Электронный чек по 1-й части заказа
— Электронный чек по 2-й части заказа
— Электронный чек по 3-й части заказа
— Электронный чек по 4-й части заказа
— Вы довольны доставкой?
При этом маркетплейс сам разбивает заказ на части, покупатель никак этим не управляет. В примере выше все части доставлены в один день, в одно время, одним курьером.
Некоторые покупатели почему-то недовольны таким количеством писем и жалуются в саппорт.
Ваши коллеги разводят руками — в заказе было 4 части, значит должно быть четыре чека. Потом, надо же уведомить о доставке, а то вдруг человек не в курсе. И уточнить, всем ли покупатель доволен (мы же клиентоориентированная компания). Вот и получается шесть писем. Ничего не поделаешь.
А вы что думаете? Опрос следует.
Что делать с письмами по заказу?
Final Results
7%
Все отлично, оставить как есть
49%
Прислать 4 чека одним письмом
42%
Объединить все письма в одно
2%
Свой вариант в комментариях
Признать проблему
Начнем с вчерашней задачки о письмах. Конечно, нормальное решение — присылать по факту доставки одно письмо, включив в него и чеки, и опрос, и все что еще важно. Никаким законам это не противоречит и технически реализуемо.
Маркетплейс не присылает четырех разных курьеров, чтобы доставить несчастный заказ — он понимает, что заказ один, и отправляет одного курьера. Аналогично можно объединить четыре письма с чеками в одно, а попотев еще немного — и оставшиеся два письма тоже свести в одно общее.
Но я хочу обратить внимание вот на что.
Самое плохое, что может сделать инженер (продакт, дизайнер, разработчик), столкнувшись с проблемой — отказаться ее признавать. Начать доказывать себе и другим, что все работает правильно и ничего менять нельзя.
Отказываясь признавать проблему, вы бесите потребителей, ослабляете продукт и становитесь хуже как специалист.
Всегда стоит руководствоваться здравым смыслом. Нет, это не нормально — присылать шесть писем об одном чертовом заказе! Это проблема. И важно это признать, хотя бы перед самим собой.
Признав проблему, можно оценить ее влияние, варианты решения и их стоимость. И потом уже думать — будете исправлять или нет.
Признав проблему, вы не обязаны ее решать! Кажется, не все это понимают. Возможно, затраты на решение не окупят выгоды. Возможно, есть более критичные проблемы, на которых стоит сосредоточиться. Возможно, вы выберете дешевый обходной путь. Возможно, вообще не найдете решение. Всё это бывает, и в каждом продукте найдутся десятки проблем, которые сознательно не будут исправлены.
Но важно честно сказать себе, что да, это действительно проблема. А не закрывать глаза и убеждать всех вокруг, что ее не существует.
Начнем с вчерашней задачки о письмах. Конечно, нормальное решение — присылать по факту доставки одно письмо, включив в него и чеки, и опрос, и все что еще важно. Никаким законам это не противоречит и технически реализуемо.
Маркетплейс не присылает четырех разных курьеров, чтобы доставить несчастный заказ — он понимает, что заказ один, и отправляет одного курьера. Аналогично можно объединить четыре письма с чеками в одно, а попотев еще немного — и оставшиеся два письма тоже свести в одно общее.
Но я хочу обратить внимание вот на что.
Самое плохое, что может сделать инженер (продакт, дизайнер, разработчик), столкнувшись с проблемой — отказаться ее признавать. Начать доказывать себе и другим, что все работает правильно и ничего менять нельзя.
Отказываясь признавать проблему, вы бесите потребителей, ослабляете продукт и становитесь хуже как специалист.
Всегда стоит руководствоваться здравым смыслом. Нет, это не нормально — присылать шесть писем об одном чертовом заказе! Это проблема. И важно это признать, хотя бы перед самим собой.
Признав проблему, можно оценить ее влияние, варианты решения и их стоимость. И потом уже думать — будете исправлять или нет.
Признав проблему, вы не обязаны ее решать! Кажется, не все это понимают. Возможно, затраты на решение не окупят выгоды. Возможно, есть более критичные проблемы, на которых стоит сосредоточиться. Возможно, вы выберете дешевый обходной путь. Возможно, вообще не найдете решение. Всё это бывает, и в каждом продукте найдутся десятки проблем, которые сознательно не будут исправлены.
Но важно честно сказать себе, что да, это действительно проблема. А не закрывать глаза и убеждать всех вокруг, что ее не существует.
Вы являетесь дизайнеру в страшном сне
Интернет-банк Тинькова при входе встречает многозначительной надписью:
Вы являетесь держателем продуктов Тинькофф Банка. При входе по номеру телефона, в целях безопасности, введите пароль.
Я, конечно, не UX-писатель, но это жуть какая кривая формулировка. Давайте попробуем улучшить.
1. Формулируем по-человечески
Меняем суконный язык банковских безопасников на нормальную речь.
Вы являетесь держателем продуктов Тинькофф Банка. При входе по номеру телефона, в целях безопасности, введите пароль.
↓
Вы — клиент Тинькофф Банка. Введите пароль, чтобы войти.
2. Убираем лишнее
Зачем писать человеку, что он клиент? Я и так это знаю, потому и пытаюсь войти в интернет-банк. Убираем.
Вы — клиент Тинькофф Банка. Введите пароль, чтобы войти.
↓
Введите пароль, чтобы войти.
3. Убираем очевидное
На этой же форме огроменное поле ПАРОЛЬ и кнопка ВОЙТИ. Спорим, человек догадается, чего от него хотят?
Введите пароль, чтобы войти.
↓
Ø
Что осталось — в следующем сообщении.
P.S. Если дизайнеру ну совсем никак без подзаголовка, я бы написал Осталось ввести пароль.
Интернет-банк Тинькова при входе встречает многозначительной надписью:
Вы являетесь держателем продуктов Тинькофф Банка. При входе по номеру телефона, в целях безопасности, введите пароль.
Я, конечно, не UX-писатель, но это жуть какая кривая формулировка. Давайте попробуем улучшить.
1. Формулируем по-человечески
Меняем суконный язык банковских безопасников на нормальную речь.
Вы являетесь держателем продуктов Тинькофф Банка. При входе по номеру телефона, в целях безопасности, введите пароль.
↓
Вы — клиент Тинькофф Банка. Введите пароль, чтобы войти.
2. Убираем лишнее
Зачем писать человеку, что он клиент? Я и так это знаю, потому и пытаюсь войти в интернет-банк. Убираем.
Вы — клиент Тинькофф Банка. Введите пароль, чтобы войти.
↓
Введите пароль, чтобы войти.
3. Убираем очевидное
На этой же форме огроменное поле ПАРОЛЬ и кнопка ВОЙТИ. Спорим, человек догадается, чего от него хотят?
Введите пароль, чтобы войти.
↓
Ø
Что осталось — в следующем сообщении.
P.S. Если дизайнеру ну совсем никак без подзаголовка, я бы написал Осталось ввести пароль.