Насмотренность —> Напользованность
Если хочешь делать продукты с хорошим пользовательским опытом — развивай свой личный пользовательский опыт.
Очень часто пиарят важность насмотренности: ходи на Бехансы и смотри, что крутые рисуют.
Это, конечно, лучше чем не ходить, но в бою с хреновым UX пригодится слабо.
Смотреть как штангу тягают или самому потягать — разные ощущения и опыт.
В бою с хреновым UX пригодится твоя напользованность: чем с большим количеством разных продуктов ты поработал, тем шире у тебя пользовательский кругозор.
Когда ты сам пользуешься продуктом, то видишь не только продукт в виде интерфейса. Тебя вовлекают в продукт, дожимают до покупки, с тобой общаются — это всё складывается в пользовательский опыт. Со временем накапливается больше личного опыта и удачных практик, которые ты будешь транслировать в свою работу.
В общем, хватит только смотреть — больше пользуйся.
#UX #совет
Если хочешь делать продукты с хорошим пользовательским опытом — развивай свой личный пользовательский опыт.
Очень часто пиарят важность насмотренности: ходи на Бехансы и смотри, что крутые рисуют.
Это, конечно, лучше чем не ходить, но в бою с хреновым UX пригодится слабо.
Смотреть как штангу тягают или самому потягать — разные ощущения и опыт.
В бою с хреновым UX пригодится твоя напользованность: чем с большим количеством разных продуктов ты поработал, тем шире у тебя пользовательский кругозор.
Когда ты сам пользуешься продуктом, то видишь не только продукт в виде интерфейса. Тебя вовлекают в продукт, дожимают до покупки, с тобой общаются — это всё складывается в пользовательский опыт. Со временем накапливается больше личного опыта и удачных практик, которые ты будешь транслировать в свою работу.
В общем, хватит только смотреть — больше пользуйся.
#UX #совет
Один на один
Самое полезное для меня открытие последнего времени — проведение общения с коллегами в формате один на один.
Прежде всего, формат один на один полезен при общении Старший/Младший, Куратор/Курируемый, Менеджер/Участник и т.д..
У нас в продуктовой команде Велвики один на один работает так:
👉 Общение длится 1 час, а общаемся один раз в месяц.
👉 С новыми участниками команды общение происходит чаще — раз в неделю.
👉 Запросить встречу один на один может кто угодно и с кем угодно (пользуются редко).
В чём польза такого общения:
✅ Доверительная беседа в течение часа позволяет обсудить не только рабочие, но и личные темы — помогает понять место работы в жизни коллеги.
✅ Прекрасная возможность предоставлять и получать регулярную обратную связь и фиксировать прогресс - обратная связь становится неотъемлемой частью.
✅ Когда установлено доверие, то легче и раньше поднимаются финансовые и коммуникационные вопросы — проблема гасится до того, как она становится проблемой.
Что важно для один на один:
1️⃣ Надо готовиться и фиксировать итоги. Каждое новое общение это продолжение прошлого.
2️⃣ Не отвлекаться. Оба участника должны быть сосредоточены на общении, а не на постороннем.
3️⃣ Не ждать многого с первого раза. Первый раз получается скомканным — тот, кто раньше не участвовал в таких форматах, не сразу готов к доверительной беседе.
Кстати, подойти к коллеге и спросить у него: "Ну как дела? Всё хорошо?" или неформально пообщаться в кафе — это не один на один. Это как на улице спросить у знакомого: "Как дела?", на что он ответит: "Нормально! Сам как?". Вот и поговорили.
Самое полезное для меня открытие последнего времени — проведение общения с коллегами в формате один на один.
Прежде всего, формат один на один полезен при общении Старший/Младший, Куратор/Курируемый, Менеджер/Участник и т.д..
У нас в продуктовой команде Велвики один на один работает так:
👉 Общение длится 1 час, а общаемся один раз в месяц.
👉 С новыми участниками команды общение происходит чаще — раз в неделю.
👉 Запросить встречу один на один может кто угодно и с кем угодно (пользуются редко).
В чём польза такого общения:
✅ Доверительная беседа в течение часа позволяет обсудить не только рабочие, но и личные темы — помогает понять место работы в жизни коллеги.
✅ Прекрасная возможность предоставлять и получать регулярную обратную связь и фиксировать прогресс - обратная связь становится неотъемлемой частью.
✅ Когда установлено доверие, то легче и раньше поднимаются финансовые и коммуникационные вопросы — проблема гасится до того, как она становится проблемой.
Что важно для один на один:
1️⃣ Надо готовиться и фиксировать итоги. Каждое новое общение это продолжение прошлого.
2️⃣ Не отвлекаться. Оба участника должны быть сосредоточены на общении, а не на постороннем.
3️⃣ Не ждать многого с первого раза. Первый раз получается скомканным — тот, кто раньше не участвовал в таких форматах, не сразу готов к доверительной беседе.
Кстати, подойти к коллеге и спросить у него: "Ну как дела? Всё хорошо?" или неформально пообщаться в кафе — это не один на один. Это как на улице спросить у знакомого: "Как дела?", на что он ответит: "Нормально! Сам как?". Вот и поговорили.
Мой ТОП UX-мракобесия
Бесит, когда:
🤬 Ты нажимаешь на кнопку, а она не реагирует. Ты жмёшь ещё пару раз. А потом оказывается, что с первого раза всё пошло и твои последующие нажатия применились к другим записям.
🤬 Не говорят, что функции платные. Ты что-то сделал в приложении, пытаешься завершить, а тебе — плати.
🤬 Нельзя войти через соцсети. Нужна сильная мотивация, чтобы пользоваться чем-то, куда нельзя входить через гугл, яндекс или facebook.
🤬 Нельзя отписаться от рассылки, не входя в личный кабинет.
🤬 Что-то само всплывает. Разрешите уведомления, Подпишитесь на рассылку, Я Ваш консультант, Акция-распродажа — мракобесы.
🤬 Тупой юмор в серьёзных приложениях. "Ой, кажется, что-то пошло не так. Дышите глубже" — это не смешно, когда ты деньги переводишь.
🤬 Отсутствие реакции на обратную связь. Напишешь в обратную связь, а тебе в ответ никакого подтверждения: получили или нет, когда ответите?
🤬 Когда только зарегался или поставит приложение, а тебя просят отзыв. Я могу только двойку сходу поставить. Дайте понять, куда попал.
🤬 Интерфейсные тексты написаны с ошибками. Что же там внутри тогда, если копнуть. Персональные и платёжные данные доверять не хочется.
#UX
Бесит, когда:
🤬 Ты нажимаешь на кнопку, а она не реагирует. Ты жмёшь ещё пару раз. А потом оказывается, что с первого раза всё пошло и твои последующие нажатия применились к другим записям.
🤬 Не говорят, что функции платные. Ты что-то сделал в приложении, пытаешься завершить, а тебе — плати.
🤬 Нельзя войти через соцсети. Нужна сильная мотивация, чтобы пользоваться чем-то, куда нельзя входить через гугл, яндекс или facebook.
🤬 Нельзя отписаться от рассылки, не входя в личный кабинет.
🤬 Что-то само всплывает. Разрешите уведомления, Подпишитесь на рассылку, Я Ваш консультант, Акция-распродажа — мракобесы.
🤬 Тупой юмор в серьёзных приложениях. "Ой, кажется, что-то пошло не так. Дышите глубже" — это не смешно, когда ты деньги переводишь.
🤬 Отсутствие реакции на обратную связь. Напишешь в обратную связь, а тебе в ответ никакого подтверждения: получили или нет, когда ответите?
🤬 Когда только зарегался или поставит приложение, а тебя просят отзыв. Я могу только двойку сходу поставить. Дайте понять, куда попал.
🤬 Интерфейсные тексты написаны с ошибками. Что же там внутри тогда, если копнуть. Персональные и платёжные данные доверять не хочется.
#UX
Гигиена здорового коллектива
Если хочешь, чтобы сотрудники любили компанию и вкладывали себя в её развитие, то только рыночная зарплата и "у нас печеньки и чай" не поможет.
Необходимы процедуры, которые будут поддерживать здоровье коллектива:
🎓 Обучение сотрудников — либо знания поступают извне, либо постепенно происходит застой и работают так, как другие уже не работают.
🤹♂️ Внутренние митапы — сотрудники распространяют знания между собой, растут все.
🎤 Внешние конференции — нетворкинг с коллегами по цеху здорово прокачивает, а если ещё и самим выступать — вообще, огонь.
💻 Личные проекты сотрудников — надо поощрять, потому что сотрудник через личный проект, который его драйвит, может привнести что-то новое и уже испытанное им в работу компании.
☀️ Культура нетоксичного общения — у каждого должна быть возможность проявить себя и не быть при этом обосранным звёздами. Заткнутый с не самой удачной идеей сотрудник уже не принесёт новую идею, которая может оказаться классной.
В общем, самые классные продукты рождаются и развиваются в здоровых коллективах. Сотрудник должен профессионально расти в компании, а не за её пределами — иначе, зачем ему компания.
#кактотак
Если хочешь, чтобы сотрудники любили компанию и вкладывали себя в её развитие, то только рыночная зарплата и "у нас печеньки и чай" не поможет.
Необходимы процедуры, которые будут поддерживать здоровье коллектива:
🎓 Обучение сотрудников — либо знания поступают извне, либо постепенно происходит застой и работают так, как другие уже не работают.
🤹♂️ Внутренние митапы — сотрудники распространяют знания между собой, растут все.
🎤 Внешние конференции — нетворкинг с коллегами по цеху здорово прокачивает, а если ещё и самим выступать — вообще, огонь.
💻 Личные проекты сотрудников — надо поощрять, потому что сотрудник через личный проект, который его драйвит, может привнести что-то новое и уже испытанное им в работу компании.
☀️ Культура нетоксичного общения — у каждого должна быть возможность проявить себя и не быть при этом обосранным звёздами. Заткнутый с не самой удачной идеей сотрудник уже не принесёт новую идею, которая может оказаться классной.
В общем, самые классные продукты рождаются и развиваются в здоровых коллективах. Сотрудник должен профессионально расти в компании, а не за её пределами — иначе, зачем ему компания.
#кактотак
Материалы выходного дня #13
1️⃣ Очень классная статья про то, как дизайнеры из Всесоюзного научно-исследовательского института технической эстетики впервые опробовали систему сортировки и раздельного сбора мусора. Это было 35 лет назад. Здесь и про сценарный дизайн, и про дизайн-систему вокруг процесса раздельного сбора мусора, и про CJM (так это не называли, но смысл тот же).
2️⃣ Просто ссылка на огромный календарь IT-событий с фильтрами по городам. Поищите — может быть, у вас в городе что-то мощное вот-вот состоится, а вы и не знали. https://tagline.ru/events/
3️⃣ Увлекательная статья про худший отдел Microsoft с миллиардами убытков, который стал прибыльным: что помогло возродиться поисковику Bing.
"В ДНК Microsoft был принцип медленного выпуска более стабильных продуктов. Сарин же рекомендовал публиковать новые сборки и обновления как можно чаще — от их количества и скорости зависело продвижение по службе и влияние, которое человек мог оказать на развитие проекта (поиска Microsoft)."
4️⃣ Выгорание. Тренд или эволюция.
Видео про выгорание. Про то самое, которое в этом году ВОЗ признали болезнью.
Рассказывает Вера Маневич, Head of HR, zarplata.ru
Запись доклада была сделана на ProductSense'19 Minsk ProductSense
☀️ Отдыхайте и не выгорайте!
1️⃣ Очень классная статья про то, как дизайнеры из Всесоюзного научно-исследовательского института технической эстетики впервые опробовали систему сортировки и раздельного сбора мусора. Это было 35 лет назад. Здесь и про сценарный дизайн, и про дизайн-систему вокруг процесса раздельного сбора мусора, и про CJM (так это не называли, но смысл тот же).
2️⃣ Просто ссылка на огромный календарь IT-событий с фильтрами по городам. Поищите — может быть, у вас в городе что-то мощное вот-вот состоится, а вы и не знали. https://tagline.ru/events/
3️⃣ Увлекательная статья про худший отдел Microsoft с миллиардами убытков, который стал прибыльным: что помогло возродиться поисковику Bing.
"В ДНК Microsoft был принцип медленного выпуска более стабильных продуктов. Сарин же рекомендовал публиковать новые сборки и обновления как можно чаще — от их количества и скорости зависело продвижение по службе и влияние, которое человек мог оказать на развитие проекта (поиска Microsoft)."
4️⃣ Выгорание. Тренд или эволюция.
Видео про выгорание. Про то самое, которое в этом году ВОЗ признали болезнью.
Рассказывает Вера Маневич, Head of HR, zarplata.ru
Запись доклада была сделана на ProductSense'19 Minsk ProductSense
☀️ Отдыхайте и не выгорайте!
Лишние люди на совещаниях
— Что сейчас обсуждать будем?
— Не знаю точно, вроде, какую-то новую систему с разработчиками.
— А, понятно — новые технологии!
— Да, когда только работать успевать!?
Такой диалог я слышал много раз перед обсуждением проекта или дизайна с заказчиком. У многих больших компаний, а особенно у госов в ДНК заложено: позвать как можно больше людей на совещание. И вот сидит целая толпа и обсуждает то, о чём ещё 5 минут назад многие даже не знали.
Эффективность такого совещания очень сомнительна: активничает 10% участников, а остальные ждут, когда закончится и думают: лишь бы слово не дали. Если молчуну дадут слово, то в лучшем случае, он скажет, что добавить нечего. В худшем — начнет на серьёзных щах фантазировать и предлагать ерунду или суперфункции.
Хуже всего, когда лишних людей позвали обсуждать дизайн 🤦♂️ — случайные люди не всегда молчат. Включается синдром актёра — позвали критиковать, значит надо критиковать. А это же дизайн — в нём все "сильные критики".
Если в вашей команде бывают совещания, на которых не все участники активны — возможно, вы попусту тратите ресурс. Небольшое количество вовлечённых в процесс людей будут гораздо эффективнее толпы.
Чтобы совещание удалось:
1️⃣ Нужна повестка — все могли заранее подготовиться и прийти с обратной связью или мнением. Надо избегать совещаний без контектста.
2️⃣ Не нужны молчуны — все, кого позвали были активны. Кто отмалчивался — не надо больше звать в эту тему.
3️⃣ Нужны зафиксированные итоги — с ними можно ознакомить остальных, да и в целом полезно зафиксировать. О навыке резюмировать итоги обсуждений есть отдельная заметка.
В общем, обсуждать должны те, кого тема драйвит и мотивирует. Случайные участники совещаний только случайно могут быть полезны, а чаще они бесполезны или вредны.
— Что сейчас обсуждать будем?
— Не знаю точно, вроде, какую-то новую систему с разработчиками.
— А, понятно — новые технологии!
— Да, когда только работать успевать!?
Такой диалог я слышал много раз перед обсуждением проекта или дизайна с заказчиком. У многих больших компаний, а особенно у госов в ДНК заложено: позвать как можно больше людей на совещание. И вот сидит целая толпа и обсуждает то, о чём ещё 5 минут назад многие даже не знали.
Эффективность такого совещания очень сомнительна: активничает 10% участников, а остальные ждут, когда закончится и думают: лишь бы слово не дали. Если молчуну дадут слово, то в лучшем случае, он скажет, что добавить нечего. В худшем — начнет на серьёзных щах фантазировать и предлагать ерунду или суперфункции.
Хуже всего, когда лишних людей позвали обсуждать дизайн 🤦♂️ — случайные люди не всегда молчат. Включается синдром актёра — позвали критиковать, значит надо критиковать. А это же дизайн — в нём все "сильные критики".
Если в вашей команде бывают совещания, на которых не все участники активны — возможно, вы попусту тратите ресурс. Небольшое количество вовлечённых в процесс людей будут гораздо эффективнее толпы.
Чтобы совещание удалось:
1️⃣ Нужна повестка — все могли заранее подготовиться и прийти с обратной связью или мнением. Надо избегать совещаний без контектста.
2️⃣ Не нужны молчуны — все, кого позвали были активны. Кто отмалчивался — не надо больше звать в эту тему.
3️⃣ Нужны зафиксированные итоги — с ними можно ознакомить остальных, да и в целом полезно зафиксировать. О навыке резюмировать итоги обсуждений есть отдельная заметка.
В общем, обсуждать должны те, кого тема драйвит и мотивирует. Случайные участники совещаний только случайно могут быть полезны, а чаще они бесполезны или вредны.
Менторский тон интерфейсного текста
Текст в интерфейсе сделал большой шаг вперёд. Если раньше даже в топовых продуктах было много текстовых проблем, то сейчас чаще всего чистенько, понятно и аккуратно.
Но текст шагает дальше и порой не в ту сторону — вместо общения с пользователем на равных, продукты начинают общаться в менторском тоне (высокомерно-поучительно).
Прям подбешивают порой рубленые поучительные фразы. Понятно, что "Пиши, сокращай" и всё такое, но продукт не должен общаться с пользователем в режиме робота — их, итак, слишком много. Капелька чувст в текст не повредит.
Например,
Запрос получен, ответим через 7 дней. Проверяйте почту [email protected]
Всё ок, ничего лишнего. Но так "говорят" бесчувственные роботы.
Мне как пользователю приятнее, когда текст человечный, а не рубленый до минимума. Например, так:
Мы получили ваш запрос и точно ответим на него в течение 7 дней. Ответ придёт на почту [email protected].
В общем, продукты с душевным и понятным текстом приятнее использовать, чем продукты с рублеными фразами в менторском тоне.
#UX #совет
Текст в интерфейсе сделал большой шаг вперёд. Если раньше даже в топовых продуктах было много текстовых проблем, то сейчас чаще всего чистенько, понятно и аккуратно.
Но текст шагает дальше и порой не в ту сторону — вместо общения с пользователем на равных, продукты начинают общаться в менторском тоне (высокомерно-поучительно).
Прям подбешивают порой рубленые поучительные фразы. Понятно, что "Пиши, сокращай" и всё такое, но продукт не должен общаться с пользователем в режиме робота — их, итак, слишком много. Капелька чувст в текст не повредит.
Например,
Запрос получен, ответим через 7 дней. Проверяйте почту [email protected]
Всё ок, ничего лишнего. Но так "говорят" бесчувственные роботы.
Мне как пользователю приятнее, когда текст человечный, а не рубленый до минимума. Например, так:
Мы получили ваш запрос и точно ответим на него в течение 7 дней. Ответ придёт на почту [email protected].
В общем, продукты с душевным и понятным текстом приятнее использовать, чем продукты с рублеными фразами в менторском тоне.
#UX #совет
Выводы сделаны, виновники наказаны
Самый лучший способ испортить команду — наказывать виновников факапов.
Очень глубоко в нас сидит желание найти конкретного виновника, показать на него пальцем и наказать, премии лишить.
Но всегда наказана вся команда. Любой провал — это проблема команды, за которой, конечно, стоят конкретные персоны.
Команда должна поддерживать, а не наказывать.
Иными словами: вот знаем мы, что из-за неосмотрительности Феди случился факап. Значит, надо помочь Феде: подсказать, помочь быть осмотрительным, поддержать словом и делом.
Если из-за неосмотрительности Феди снова провал — ещё раз помочь.
А если в третий раз — значит Федя не для нашей команды, с ним надо расстаться.
В общем, надо либо развивать и помогать, либо расставаться. Наказывать виновников каждого факапа — делать склочную и боящуюся инноваций команду.
Самый лучший способ испортить команду — наказывать виновников факапов.
Очень глубоко в нас сидит желание найти конкретного виновника, показать на него пальцем и наказать, премии лишить.
Но всегда наказана вся команда. Любой провал — это проблема команды, за которой, конечно, стоят конкретные персоны.
Команда должна поддерживать, а не наказывать.
Иными словами: вот знаем мы, что из-за неосмотрительности Феди случился факап. Значит, надо помочь Феде: подсказать, помочь быть осмотрительным, поддержать словом и делом.
Если из-за неосмотрительности Феди снова провал — ещё раз помочь.
А если в третий раз — значит Федя не для нашей команды, с ним надо расстаться.
В общем, надо либо развивать и помогать, либо расставаться. Наказывать виновников каждого факапа — делать склочную и боящуюся инноваций команду.
MVP, а если по отечественному, то МЖП — это минимальный жизнеспособный продукт.
МЖП делают быстро для тестирования гипотезы востребованности.
Так вот "быстро" не значит, что всё должно быть из говна и палок.
Если хочется проверить гипотезу востребованности, то дизайн и эргономика должны привлекать.
Внутри могут быть заплатки на заплатках и говнокод, но внешне должно быть привлекательно.
Ходить к пользователям с хреновым дизайном и UX - тратить и их, и своё время.
Только в учебных целях можно делать прототипы из картона или серых блоков, чтобы мышление прокачать на тему, что можно делать не всё сразу.
Я, как пользователь, уважаю приятные и удобные продукты.
Продукт должен быть ооочень уникальным, чтобы ему можно было простить убогость.
В общем, второго шанса произвести первое впечатление не будет.
#UX
МЖП делают быстро для тестирования гипотезы востребованности.
Так вот "быстро" не значит, что всё должно быть из говна и палок.
Если хочется проверить гипотезу востребованности, то дизайн и эргономика должны привлекать.
Внутри могут быть заплатки на заплатках и говнокод, но внешне должно быть привлекательно.
Ходить к пользователям с хреновым дизайном и UX - тратить и их, и своё время.
Только в учебных целях можно делать прототипы из картона или серых блоков, чтобы мышление прокачать на тему, что можно делать не всё сразу.
Я, как пользователь, уважаю приятные и удобные продукты.
Продукт должен быть ооочень уникальным, чтобы ему можно было простить убогость.
В общем, второго шанса произвести первое впечатление не будет.
#UX
Адекватность вертикали
Где создаются классные продукты и делаются крутые проекты? Там, где комфортно работать, где мысль летает, где поддерживают друг друга, где команда, как кулак. Я в последнее время много рассказывал про важность плотной командной работы и климата. Сегодня тоже расскажу.
Значит, знавал я одного менеджера — пусть его будут звать Костя. Так вот, Костя любил орать на командных собраниях.
Команда отстаёт от срока — Костя орёт.
Случился фэйл — Костя орёт.
Хрен знает, что ещё — Костя орёт.
Но постепенно на встречах команды Кости начинали орать все.
Если из-за двери переговорки было слышно крики, значит там команда Кости заседает.
Любая команда под управлением Кости начинала орать и становилась "дёрганой".
Костю почти можно понять — ему же предстояло отчитываться о достижениях команды перед заказчиком и он не хотел получать "втык". Но дёрганая команда, в которой принято орать, не достигает результата. Такая команда лепит отмазки, ищет причины, а не способы, и в итоге постепенно разваливается.
Костя воспринимал команду, как что-то стороннее и это стороннее надо погонять.
Но проблема "менеджера и команды" в том, что не должно быть "менеджера и команды". Может быть только команда, внутри которой менеджер.
В общем, для команды важна адекватная вертикаль — импульсивный менеджер/лидер способен очень быстро расшатать даже крепкую команду. Как говорится: рыба гниёт с головы.
#кактотак
Где создаются классные продукты и делаются крутые проекты? Там, где комфортно работать, где мысль летает, где поддерживают друг друга, где команда, как кулак. Я в последнее время много рассказывал про важность плотной командной работы и климата. Сегодня тоже расскажу.
Значит, знавал я одного менеджера — пусть его будут звать Костя. Так вот, Костя любил орать на командных собраниях.
Команда отстаёт от срока — Костя орёт.
Случился фэйл — Костя орёт.
Хрен знает, что ещё — Костя орёт.
Но постепенно на встречах команды Кости начинали орать все.
Если из-за двери переговорки было слышно крики, значит там команда Кости заседает.
Любая команда под управлением Кости начинала орать и становилась "дёрганой".
Костю почти можно понять — ему же предстояло отчитываться о достижениях команды перед заказчиком и он не хотел получать "втык". Но дёрганая команда, в которой принято орать, не достигает результата. Такая команда лепит отмазки, ищет причины, а не способы, и в итоге постепенно разваливается.
Костя воспринимал команду, как что-то стороннее и это стороннее надо погонять.
Но проблема "менеджера и команды" в том, что не должно быть "менеджера и команды". Может быть только команда, внутри которой менеджер.
В общем, для команды важна адекватная вертикаль — импульсивный менеджер/лидер способен очень быстро расшатать даже крепкую команду. Как говорится: рыба гниёт с головы.
#кактотак
Забыть про наведение
Есть в UI один приём, который должен был умереть после распространения тач-экранов (пальцем тыкать), но его постоянно пытаются воскрешать.
Я про показывание чего-либо при наведении курсором.
Наведение даже и без тач-экрана всегда было какой-то дизайн слабостью.
🤦♂️ Не могу придумать, как нормально показать подсказку к полю — О! Покажу при наведении.
🤦♂️ Не могу сделать приличные подписи к иконкам — О! Покажу названия иконок при наведении.
🤦♂️ Скрываю названия полей после ввода в них значений — О! Выведу названия у заполненных полей при наведении.
🤦♂️ Обрезаю текст в ячейках таблицы — О! Полный текст выведу при наведении.
При распространении тач-экранов скрытие информации за наведение стало не просто слабостью, а дизайн-отсталостью.
Это всё равно что делать два слоя интерфейса, но при этом до второго слоя не всем легко добраться.
Тач-экраном, кстати, может быть не только мобильник или планшет.
Надо просто забыть про наведение, как единственный способ показать какую-либо информацию.
UI должен работать без наведения — это хорошо для всех устройств.
В общем, у тех кто предлагает показывать что-то при наведении, карма падает.
#UX
Есть в UI один приём, который должен был умереть после распространения тач-экранов (пальцем тыкать), но его постоянно пытаются воскрешать.
Я про показывание чего-либо при наведении курсором.
Наведение даже и без тач-экрана всегда было какой-то дизайн слабостью.
🤦♂️ Не могу придумать, как нормально показать подсказку к полю — О! Покажу при наведении.
🤦♂️ Не могу сделать приличные подписи к иконкам — О! Покажу названия иконок при наведении.
🤦♂️ Скрываю названия полей после ввода в них значений — О! Выведу названия у заполненных полей при наведении.
🤦♂️ Обрезаю текст в ячейках таблицы — О! Полный текст выведу при наведении.
При распространении тач-экранов скрытие информации за наведение стало не просто слабостью, а дизайн-отсталостью.
Это всё равно что делать два слоя интерфейса, но при этом до второго слоя не всем легко добраться.
Тач-экраном, кстати, может быть не только мобильник или планшет.
Надо просто забыть про наведение, как единственный способ показать какую-либо информацию.
UI должен работать без наведения — это хорошо для всех устройств.
В общем, у тех кто предлагает показывать что-то при наведении, карма падает.
#UX
35
Мне только-только исполнилось 22 года, когда я начал свой путь в ИТ. Был январь 2007 года.
В те времена очень распространена была байка, что после 30 лет человек превращается в бревно и не может обучаться новому.
Вроде бы, даже Цукерберг в те годы нанимал в Facebook только молодых, потому что они шустрее и воспринимают легче новое.
Мы с ребятами-коллегами, им тоже было по 21-23 года, иногда обсуждали, что же будет после тридцати 🙂
Как всё оказалось на самом деле.
Я встречал очень много умных молодых ребят, которые дальше собственного носа не видели: отработал день, посмотрел сериальчик и всё хорошо. Через 5 лет их знания устаревали, а к новым вызовам они были не готовы.
Я встречал много мужчин и женщин за 30, да и за 40, которые тянулись к новым знаниям, осваивали их и успешно применяли в работе.
До тридцати — это очень быстрый этап. После 30 лет ещё 35 лет, как минимум, надо работать.
Чтобы эти 35 лет не быть бревном — тянуться к знаниям и новому опыту надо ежедневно.
Кстати, те ребята (из 2007 года) повзрослели и прекрасно себя чувствуют, им уже за тридцать.
Никто не стал бревном.
В общем, мне сегодня исполнилось 35 лет и я хочу работать, учиться и познавать новое.
Мечтать о сладкой жизни, в которой не надо работать — самое скучное, о чём можно мечтать.
Мне только-только исполнилось 22 года, когда я начал свой путь в ИТ. Был январь 2007 года.
В те времена очень распространена была байка, что после 30 лет человек превращается в бревно и не может обучаться новому.
Вроде бы, даже Цукерберг в те годы нанимал в Facebook только молодых, потому что они шустрее и воспринимают легче новое.
Мы с ребятами-коллегами, им тоже было по 21-23 года, иногда обсуждали, что же будет после тридцати 🙂
Как всё оказалось на самом деле.
Я встречал очень много умных молодых ребят, которые дальше собственного носа не видели: отработал день, посмотрел сериальчик и всё хорошо. Через 5 лет их знания устаревали, а к новым вызовам они были не готовы.
Я встречал много мужчин и женщин за 30, да и за 40, которые тянулись к новым знаниям, осваивали их и успешно применяли в работе.
До тридцати — это очень быстрый этап. После 30 лет ещё 35 лет, как минимум, надо работать.
Чтобы эти 35 лет не быть бревном — тянуться к знаниям и новому опыту надо ежедневно.
Кстати, те ребята (из 2007 года) повзрослели и прекрасно себя чувствуют, им уже за тридцать.
Никто не стал бревном.
В общем, мне сегодня исполнилось 35 лет и я хочу работать, учиться и познавать новое.
Мечтать о сладкой жизни, в которой не надо работать — самое скучное, о чём можно мечтать.
Уровень
Любую задачу надо доводить до состояния: "Если бы я работал один, то запустил бы этот итог в продакшн".
Дизайнер не должен рассчитывать, что кто-то будет смотреть его работу прежде чем показать заказчику.
Программист не должен рассчитывать, что есть QA, который всё найдёт.
Редактор не должен рассчитывать, что есть корректор и главред, которые поправят и дадут обратную связь.
Если каждое звено работает как последний рубеж, тогда общий качественный итог получается гораздо быстрее.
Каждый уровень должен не разбирать грязь от предыдущего уровня, а улучшать итог своей профессиональной компетенцией.
В общем, если выключить у себя уверенность, что кто-то обязательно перепроверит твои итоги, то можно существенно поднять уровень этих самых итогов.
Любую задачу надо доводить до состояния: "Если бы я работал один, то запустил бы этот итог в продакшн".
Дизайнер не должен рассчитывать, что кто-то будет смотреть его работу прежде чем показать заказчику.
Программист не должен рассчитывать, что есть QA, который всё найдёт.
Редактор не должен рассчитывать, что есть корректор и главред, которые поправят и дадут обратную связь.
Если каждое звено работает как последний рубеж, тогда общий качественный итог получается гораздо быстрее.
Каждый уровень должен не разбирать грязь от предыдущего уровня, а улучшать итог своей профессиональной компетенцией.
В общем, если выключить у себя уверенность, что кто-то обязательно перепроверит твои итоги, то можно существенно поднять уровень этих самых итогов.
Материалы выходного дня #14
Сегодня вот такая подборочка:
1️⃣ Профи.ру выложили Дао лидера
Рассказывают как стать крутым пипл-менеджером. Пипл-менеджер помогает коллегам расти и показывать крутой результат.
2️⃣ «Нужно оставаться безответственным и одержимым, чтобы совершить что-то выдающееся»: Пол Грэм о теории автобусных билетов
Предприниматель и основатель Y Combinator объясняет, кому и почему удается совершать выдающиеся открытия.
3️⃣ Ребята из UX Feedback рассказали в своём блоге, что такое Voice of the Customer и как Голос Потребителя улучшит продукт.
4️⃣ Дмитрий Капаев рассказывает про Jobs To Be Done исследование. В статье есть ещё пачка ссылок на тему JTBD.
Сегодня вот такая подборочка:
1️⃣ Профи.ру выложили Дао лидера
Рассказывают как стать крутым пипл-менеджером. Пипл-менеджер помогает коллегам расти и показывать крутой результат.
2️⃣ «Нужно оставаться безответственным и одержимым, чтобы совершить что-то выдающееся»: Пол Грэм о теории автобусных билетов
Предприниматель и основатель Y Combinator объясняет, кому и почему удается совершать выдающиеся открытия.
3️⃣ Ребята из UX Feedback рассказали в своём блоге, что такое Voice of the Customer и как Голос Потребителя улучшит продукт.
4️⃣ Дмитрий Капаев рассказывает про Jobs To Be Done исследование. В статье есть ещё пачка ссылок на тему JTBD.
Дао лидера от Профи
Дао лидера от Профи | Readymag
Гид по лидерству Профи, который поможет тебе стать хорошим пипл-менеджером и управлять не управляя.
Кто отвечает за UX?
Кто должен отвечать за то, чтобы пользователь пришёл в продукт и получил положительный пользовательский опыт?
Если команда думает, что наняв UX-дизайнера всё станет хорошо, то это ошибочно.
В поведении продукта, в его работе с пользователем, да и в самой стабильности работы очень многое зависит не от дизайнера.
На острие UX-атаки находятся фронтэнд программисты, QA (тестировщики), а также все остальные: кто-то больше, кто-то меньше.
Задача дизайн-команды (или дизайнера, или того, кто за него) — доносить знания о UX до коллег: рассказывать о важности заботы о пользователях, собирать и транслировать лучшие практики, можно даже тесты проводить на знание основ UX.
В общем, чтобы команда делала крутые решения — команду надо качать. Организовывать внутренние митапы, рассказывать про удобство, не замыкать UX на ком-то конкретном. Каждый должен думать о пользователях и их потребностях.
Для убедительности — несколько примеров UX-ляпов, которые от дизайнера почти не зависят:
🤦♂️ Когда ссылка написана внутри блока (похожа на кнопку), но чтобы перейти надо кликнуть именно по тексту, а не по всему блоку.
🤦♂️ Когда надо попасть именно в квадратик, чтобы чекнуть чек-бокс, а по названию нажать нельзя.
🤦♂️ Когда код страны уже вписан в поле с телефонным номером и убрать его нельзя. Из-за этого просто скопировать/вставить номер нельзя — обрезается последняя цифра.
🤦♂️ Когда твой город даже не пытаются определить, а сразу предлагают выбрать из длинного списка.
🤦♂️ Когда на форме входа при неверном вводе стирают и логин, и пароль.
#UX
Кто должен отвечать за то, чтобы пользователь пришёл в продукт и получил положительный пользовательский опыт?
Если команда думает, что наняв UX-дизайнера всё станет хорошо, то это ошибочно.
В поведении продукта, в его работе с пользователем, да и в самой стабильности работы очень многое зависит не от дизайнера.
На острие UX-атаки находятся фронтэнд программисты, QA (тестировщики), а также все остальные: кто-то больше, кто-то меньше.
Задача дизайн-команды (или дизайнера, или того, кто за него) — доносить знания о UX до коллег: рассказывать о важности заботы о пользователях, собирать и транслировать лучшие практики, можно даже тесты проводить на знание основ UX.
В общем, чтобы команда делала крутые решения — команду надо качать. Организовывать внутренние митапы, рассказывать про удобство, не замыкать UX на ком-то конкретном. Каждый должен думать о пользователях и их потребностях.
Для убедительности — несколько примеров UX-ляпов, которые от дизайнера почти не зависят:
🤦♂️ Когда ссылка написана внутри блока (похожа на кнопку), но чтобы перейти надо кликнуть именно по тексту, а не по всему блоку.
🤦♂️ Когда надо попасть именно в квадратик, чтобы чекнуть чек-бокс, а по названию нажать нельзя.
🤦♂️ Когда код страны уже вписан в поле с телефонным номером и убрать его нельзя. Из-за этого просто скопировать/вставить номер нельзя — обрезается последняя цифра.
🤦♂️ Когда твой город даже не пытаются определить, а сразу предлагают выбрать из длинного списка.
🤦♂️ Когда на форме входа при неверном вводе стирают и логин, и пароль.
#UX
Самое время планировать
Новый год всё-таки классная отсечка, чтобы поставить дерзкие планы 🙂
Хочется каждый год становиться лучше, а без плана лучше становиться тяжко.
В 2020 году из нового для меня планирую:
🤘 Провести вебинар или несколько.
Пока в проработке такие темы: UX сложных систем, Softskills для продуктовой работы, Особенности b2b-продуктов.
🎤 Заняться менторством.
🥳 Запустить Про удобство в Instagram.
🚀 Запустить свой продукт.
Продолжу писать статьи, заметки и наблюдения о разработке удобных продуктов, продуктоводстве, работе в команде и с командой.
Кстати, не забывайте в 2020 году говорить спасибо тем, кто сделал вас лучше.
Спасибо вам! Вы самые классные подписчики, о которых только можно мечтать!
#кактотак
Новый год всё-таки классная отсечка, чтобы поставить дерзкие планы 🙂
Хочется каждый год становиться лучше, а без плана лучше становиться тяжко.
В 2020 году из нового для меня планирую:
🤘 Провести вебинар или несколько.
Пока в проработке такие темы: UX сложных систем, Softskills для продуктовой работы, Особенности b2b-продуктов.
🎤 Заняться менторством.
🥳 Запустить Про удобство в Instagram.
🚀 Запустить свой продукт.
Продолжу писать статьи, заметки и наблюдения о разработке удобных продуктов, продуктоводстве, работе в команде и с командой.
Кстати, не забывайте в 2020 году говорить спасибо тем, кто сделал вас лучше.
Спасибо вам! Вы самые классные подписчики, о которых только можно мечтать!
#кактотак
Боязнь простых решений
Я часто замечал, что люди недоверчиво относятся к простым решениям.
Например, приносишь дизайн заказчику, а он: "Слишком просто, давайте добавим чего-нибудь этакого!"
Добавляют. Проект стартует, а ухаживать за "чем-нибудь этаким" довольно сложно.
Бояться надо сложных решений.
Любое решение, в котором есть куча "если" — бомба замедленного действия.
"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."
Чем больше "если", тем больше проблем в поддержке, в развитии, в понимании.
В итоге, в какой-то момент на отдельные логические ветки начинают забивать или забывать: что-то развивается, а что-то начинает устаревать.
Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".
В общем, надо стремиться к упрощению.
#совет
Я часто замечал, что люди недоверчиво относятся к простым решениям.
Например, приносишь дизайн заказчику, а он: "Слишком просто, давайте добавим чего-нибудь этакого!"
Добавляют. Проект стартует, а ухаживать за "чем-нибудь этаким" довольно сложно.
Бояться надо сложных решений.
Любое решение, в котором есть куча "если" — бомба замедленного действия.
"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."
Чем больше "если", тем больше проблем в поддержке, в развитии, в понимании.
В итоге, в какой-то момент на отдельные логические ветки начинают забивать или забывать: что-то развивается, а что-то начинает устаревать.
Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".
В общем, надо стремиться к упрощению.
#совет
Главное правило прокачки скиллов
В начале года многие планируют прокачать скиллы. Дам непрошеный совет по прокачке, который сэкономит время и деньги.
Хардскиллы – это владение конкретными инструментами и навыками.
Так вот, хардскиллы есть смысл прокачивать только тогда, когда вы сможете закреплять знания постоянной практикой, или когда есть конкретная цель применения скиллов.
Например, нет смысла учиться работать в Фигме, если на практике вам это не требуется. Нет смысла учиться строить CJM, если вот прям сейчас вам их не надо строить. Не обязательно учить английский только потому, что все его учат.
Когда нет потребности и практики – хардскилл усваивается хреново и забывается быстро.
Как только будет потребность, тогда и выучится быстро и закрепится практикой.
Софтскиллы – мягкие навыки или личные качества.
Так вот, софтскиллы прокачивать можно всегда, так как практиковать их можно регулярно и дома, и на работе.
В общем, не тратьте время на глубокое погружение в то, что не требуется на практике.
#совет #softskills
В начале года многие планируют прокачать скиллы. Дам непрошеный совет по прокачке, который сэкономит время и деньги.
Хардскиллы – это владение конкретными инструментами и навыками.
Так вот, хардскиллы есть смысл прокачивать только тогда, когда вы сможете закреплять знания постоянной практикой, или когда есть конкретная цель применения скиллов.
Например, нет смысла учиться работать в Фигме, если на практике вам это не требуется. Нет смысла учиться строить CJM, если вот прям сейчас вам их не надо строить. Не обязательно учить английский только потому, что все его учат.
Когда нет потребности и практики – хардскилл усваивается хреново и забывается быстро.
Как только будет потребность, тогда и выучится быстро и закрепится практикой.
Софтскиллы – мягкие навыки или личные качества.
Так вот, софтскиллы прокачивать можно всегда, так как практиковать их можно регулярно и дома, и на работе.
В общем, не тратьте время на глубокое погружение в то, что не требуется на практике.
#совет #softskills
Привет!
Наконец-то дошли руки до перевода статьи "UX форм, с которыми работают" в формат чек-листа.
Отдельно делать не стал — добавил лист про формы к уже существующему чек-листу про таблицы.
Доступно для всех: можно сохранить к себе и дополнить/сократить под свой проект.
Формат чек-листа: Гугл-Таблицы (Эксель от Гугл).
В чек-листе 65 требований по таблицам и 47 требований по формам, а также ссылки на теоретическую базу.
Требования касаются как дизайна-проектирования, так и разработки/тестирования.
🔥 Ссылка на чек-лист
Ссылки на статьи, которые легли в основу чек-листа:
👉 #1. UX таблиц, с которыми работают. ч1 — Просмотр данных
👉 #2. UX таблиц, с которыми работают. ч2 — Добавление и поиск данных
👉 #3. UX таблиц, с которыми работают. Ч3: управление данными и экспорт
👉 UX форм, с которыми работают
В общем, пользуйтесь на здоровье!
#UX
Наконец-то дошли руки до перевода статьи "UX форм, с которыми работают" в формат чек-листа.
Отдельно делать не стал — добавил лист про формы к уже существующему чек-листу про таблицы.
Доступно для всех: можно сохранить к себе и дополнить/сократить под свой проект.
Формат чек-листа: Гугл-Таблицы (Эксель от Гугл).
В чек-листе 65 требований по таблицам и 47 требований по формам, а также ссылки на теоретическую базу.
Требования касаются как дизайна-проектирования, так и разработки/тестирования.
🔥 Ссылка на чек-лист
Ссылки на статьи, которые легли в основу чек-листа:
👉 #1. UX таблиц, с которыми работают. ч1 — Просмотр данных
👉 #2. UX таблиц, с которыми работают. ч2 — Добавление и поиск данных
👉 #3. UX таблиц, с которыми работают. Ч3: управление данными и экспорт
👉 UX форм, с которыми работают
В общем, пользуйтесь на здоровье!
#UX
Google Docs
Чек-лист создания таблиц и форм, с которыми работают
Что это
Опубликован:,29.04.2019,Последние изменения:,11.01.2020
Автор:,Михаил Греков, Product manager Velvica — cloud commerce platform
Телеграм-канал:,<a href="https://telegram.im/proudobstvo">Про удобство</a>,(@proudobstvo),Medium:,<a href="https://m…
Опубликован:,29.04.2019,Последние изменения:,11.01.2020
Автор:,Михаил Греков, Product manager Velvica — cloud commerce platform
Телеграм-канал:,<a href="https://telegram.im/proudobstvo">Про удобство</a>,(@proudobstvo),Medium:,<a href="https://m…
UX-тренды 2020
Все поТРЕНДели, а я ещё нет. Вот пачка UX трендов на год идущий.
Корпоративные сайты
☝️ Пользователям по-прежнему будет пофигу на дизайн, если контент говно.
☝️ Если дизайн дополняет контент — пользователи оценят.
☝️ SEO-шум и маркетологическое словоблудие продолжат бесить. Люди ждут конкретику, не размазанную по "оптимизированным" текстам.
Интернет-магазины и прочий е-комерс
☝️ Если доставка или поддержка будут лажать, то всё клёвое на сайте будет перечёркнуто.
☝️ Если купленный товар окажется плох, то пользователь получит негативный опыт от магазина в целом (говно продают говнюки).
☝️ Пользователи не хотят получать кучу спама от красивого и модного магазина.
☝️ Любой магазин сравнивается по удобству с хитами (Озон, Вайлдберриз и т.п.) — надо быть на уровне.
Массовые продукты
☝️ Пользователи также легко откажутся от продукта, как и повелись на него, если увидят что-то получше/комплекснее (прыготня из Trello в Notion).
☝️ Если сразу не осилил, то тяжело вернуться к продукту. Онбординг и простота старта — залог успеха.
☝️ Сарафанное радио лучший способ создать первое впечатление — бережное отношение к отзывам и грамотная обратная связь в помощь.
☝️ Безопасность рулит. Если в сарафан пройдёт информация о проблемах с безопасностью — отмыться будет сложно.
Интерпрайс и продукты для работы
☝️ Пользователи продолжат плевать на скевоморфизм, материал или чтотамещё лежит в основе дизайна — они не знают ничего про это.
☝️ Пользователям будет всё равно на изысканность шрифтовых гарнитур.
☝️ Пользователи будут рады, если продукт не мешает работе, а ускоряет её.
☝️ Пользователи будут рады видеть в интерпрайс продуктах UX-паттерны из массовых продуктов — не надо отставать.
В общем, ничего нового: ценность первична, а оболочка вторична. Создавайте ценность и усиливайте её оболочкой — всем будет хорошо.
Все поТРЕНДели, а я ещё нет. Вот пачка UX трендов на год идущий.
Корпоративные сайты
☝️ Пользователям по-прежнему будет пофигу на дизайн, если контент говно.
☝️ Если дизайн дополняет контент — пользователи оценят.
☝️ SEO-шум и маркетологическое словоблудие продолжат бесить. Люди ждут конкретику, не размазанную по "оптимизированным" текстам.
Интернет-магазины и прочий е-комерс
☝️ Если доставка или поддержка будут лажать, то всё клёвое на сайте будет перечёркнуто.
☝️ Если купленный товар окажется плох, то пользователь получит негативный опыт от магазина в целом (говно продают говнюки).
☝️ Пользователи не хотят получать кучу спама от красивого и модного магазина.
☝️ Любой магазин сравнивается по удобству с хитами (Озон, Вайлдберриз и т.п.) — надо быть на уровне.
Массовые продукты
☝️ Пользователи также легко откажутся от продукта, как и повелись на него, если увидят что-то получше/комплекснее (прыготня из Trello в Notion).
☝️ Если сразу не осилил, то тяжело вернуться к продукту. Онбординг и простота старта — залог успеха.
☝️ Сарафанное радио лучший способ создать первое впечатление — бережное отношение к отзывам и грамотная обратная связь в помощь.
☝️ Безопасность рулит. Если в сарафан пройдёт информация о проблемах с безопасностью — отмыться будет сложно.
Интерпрайс и продукты для работы
☝️ Пользователи продолжат плевать на скевоморфизм, материал или чтотамещё лежит в основе дизайна — они не знают ничего про это.
☝️ Пользователям будет всё равно на изысканность шрифтовых гарнитур.
☝️ Пользователи будут рады, если продукт не мешает работе, а ускоряет её.
☝️ Пользователи будут рады видеть в интерпрайс продуктах UX-паттерны из массовых продуктов — не надо отставать.
В общем, ничего нового: ценность первична, а оболочка вторична. Создавайте ценность и усиливайте её оболочкой — всем будет хорошо.