Лишние люди на совещаниях
— Что сейчас обсуждать будем?
— Не знаю точно, вроде, какую-то новую систему с разработчиками.
— А, понятно — новые технологии!
— Да, когда только работать успевать!?
Такой диалог я слышал много раз перед обсуждением проекта или дизайна с заказчиком. У многих больших компаний, а особенно у госов в ДНК заложено: позвать как можно больше людей на совещание. И вот сидит целая толпа и обсуждает то, о чём ещё 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-паттерны из массовых продуктов — не надо отставать.
В общем, ничего нового: ценность первична, а оболочка вторична. Создавайте ценность и усиливайте её оболочкой — всем будет хорошо.
Навыки коммуникации
ProductPlan (сервис для построения роадмапов) сделал большое исследование продактов и выложил в открытый доступ. Участие приняли 2500 продактов. Ссылка на pdf с кучей графиков и выводов — 43 страницы.
Интересная статистика в ответе на вопрос: какой навык самый важный в повседневной работе?
Половина ответили, что навык коммуникации. Далее идут: объективная расстановка приоритетов, управление людьми, организационные навыки, технические навыки.
Что же такое навыки коммуникации?
Если продакт или кто-то уверяет, что у него бОльшая часть дня проходит в коммуникациях, то это хорошо?
Может и хорошо, но а что если суперкоммуникатор имеет кучу коммуникаций потому что:
😳 не умеет фиксировать договорённости и из-за этого вынужден постоянно проговаривать одно и тоже?
😳 не умеет слушать и запоминать главное и из-за этого мучает всех постоянными вопросами?
😳 не умеет ёмко представлять информацию и вместо одного слайда делает и рассказывает 17?
😳 не умеет выбирать способ коммуникации и вместо 10 минут устного обсуждения полдня переписывается?
😳 не умеет писать в чат и вместо одного сообщения с парой предложений кидает 15 сообщений в виде словосочетаний?
😳 не умеет сказать нет и ходит по всем планёркам, даже на которых справятся без него?
😳 не умеет организовывать и искать информацию и всех дёргает вопросами, где то найти, где это?
😳 не умеет находить людей для решения вопроса и по цепочке добирается до нужного, пройдя через кучу коллег?
В общем, бОльшая часть дня в коммуникациях — это нифига не хорошо! Всё должно работать, даже если менеджер внезапно заболеет или уедет на Бали.
Навык коммуникации — это слушать и слышать, запоминать и фиксировать, выбирать правильный канал коммуникации, быть ёмким, а не расплывчатым.
Хорош тот, у кого коммуникации выстроены так, что бOльшая часть времени остаётся для другой работы.
Посты в канале по теме:
Запоминать и резюмировать
Навык резюмировать
Культура e-mail переписки (в картинках)
#softskills
ProductPlan (сервис для построения роадмапов) сделал большое исследование продактов и выложил в открытый доступ. Участие приняли 2500 продактов. Ссылка на pdf с кучей графиков и выводов — 43 страницы.
Интересная статистика в ответе на вопрос: какой навык самый важный в повседневной работе?
Половина ответили, что навык коммуникации. Далее идут: объективная расстановка приоритетов, управление людьми, организационные навыки, технические навыки.
Что же такое навыки коммуникации?
Если продакт или кто-то уверяет, что у него бОльшая часть дня проходит в коммуникациях, то это хорошо?
Может и хорошо, но а что если суперкоммуникатор имеет кучу коммуникаций потому что:
😳 не умеет фиксировать договорённости и из-за этого вынужден постоянно проговаривать одно и тоже?
😳 не умеет слушать и запоминать главное и из-за этого мучает всех постоянными вопросами?
😳 не умеет ёмко представлять информацию и вместо одного слайда делает и рассказывает 17?
😳 не умеет выбирать способ коммуникации и вместо 10 минут устного обсуждения полдня переписывается?
😳 не умеет писать в чат и вместо одного сообщения с парой предложений кидает 15 сообщений в виде словосочетаний?
😳 не умеет сказать нет и ходит по всем планёркам, даже на которых справятся без него?
😳 не умеет организовывать и искать информацию и всех дёргает вопросами, где то найти, где это?
😳 не умеет находить людей для решения вопроса и по цепочке добирается до нужного, пройдя через кучу коллег?
В общем, бОльшая часть дня в коммуникациях — это нифига не хорошо! Всё должно работать, даже если менеджер внезапно заболеет или уедет на Бали.
Навык коммуникации — это слушать и слышать, запоминать и фиксировать, выбирать правильный канал коммуникации, быть ёмким, а не расплывчатым.
Хорош тот, у кого коммуникации выстроены так, что бOльшая часть времени остаётся для другой работы.
Посты в канале по теме:
Запоминать и резюмировать
Навык резюмировать
Культура e-mail переписки (в картинках)
#softskills
Друзья, расскажу вам про зимние мероприятия Русской Школы Сервисного Дизайна (группа на FB), основатель — Роман Черных.
Я пообщался с Романом, чтобы узнать детальнее про обучение: чему именно учат, какой формат, кому пригодится и т.п.
🔥 Для подписчиков есть скидка на курсы и на мастер-классы по промокоду.
Что:
Зимний Интенсив-курс «Сервисный UX-дизайн». Обучаться можно онлайн.
Когда:
С 5 по 14 февраля 2020 г.
Для кого:
Специалисты и менеджеры мира дизайн-проектирования и исследований UI/UX/CX, управления проектами/продуктами, фаундеры и другие, кто в теме.
Цель занятий:
Научить мыслить критически в вопросах решения бизнес-задач средствами человекоориентированного сервис-дизайна. Анонсируют много материала, который станет откровением даже для «прокачанных» и опытных профессионалов. Разберут канвас работы «DDx3» (тройной алмаз) и Решайн-мышление (методология РШСД).
Формат:
Основное обучение состоит из двух ступеней (можно купить обе ступени, а можно по одной):
1️⃣ 5,6,7 февраля: блок «Семинары-1». В формате дневных интенсивных семинаров будет рассказано о методологии проектирования продуктов и сервисов на базе ценностей клиентоориентированности. Проходит очно или онлайн.
Тематическая программа-1
Стоимость и регистрация
🔥 Если при регистрации указать код (в поле заявки) UD2000F20RS, то будет скидка 2000 рублей.
2️⃣ 12,13,14 февраля: блок «Семинары-2». Продолжение методического курса в формате дискуссионного клуба. Проходит онлайн.
Тематическая программа-2
Стоимость и регистрация
🔥 Если при регистрации указать код (в поле заявки) UD2000F20RS, то будет скидка 2000 рублей.
Отдельно от курса можно сходить (онлайн) на мастер-классы:
👉 7 февраля: Мастер-класс «Постановка задачи на проектирование» (встроенная часть блока «Семинары-1»).
Мастер-класс рассказывает о фундаментальных приёмах формирования постановки задачи на сервисное проектирование. В формате бизнес-игры участники учатся определять разные виды требований и ограничений для конкретного выбранного сервиса, а затем согласовывать их между собой, создавая «строительную площадку» с четкими границами под будущее здание сервисного дизайна. На занятии студенты в формате блиц-проектирования создают эскизы экранов пользовательского интерфейса государственного сервиса.
Регистрация
🔥 Промокод «Udobstvo-RSDS», чтобы получить скидку 500 рублей.
👉 14 февраля: Мастер-класс «Customer Journey Mapping&Construction» (встроенная часть блока «Семинары-2»).
Мастер-класс рассказывает о приёмах:
- картирования сценариев деятельности пользователей (Customer Journey Mapping) на базе проведения behavior based исследований особенностей использования сервисов реальными потребителями.
- анализа получившихся схем и эффектов с использованием оригинального подхода выявления и соотнесения барьеров/драйверов взаимодействия, причин эффектов и решений.
- генерации идей последующего усовершенствования сценария применения сервиса (Customer Journey Construction) с точки зрения многослойной системы дизайна — деятельности, функций, интерфейса.
Регистрация
🔥 Промо-код «Udobstvo-RSDS», чтобы получить скидку 500 рублей.
Фишка:
Это именно курс, а не набор презентаций.
Следующее занятие продолжает предыдущее, донося таким образом полную картину.
Отзывы:
На сайте РШСД, в группе FB
Я пообщался с Романом, чтобы узнать детальнее про обучение: чему именно учат, какой формат, кому пригодится и т.п.
🔥 Для подписчиков есть скидка на курсы и на мастер-классы по промокоду.
Что:
Зимний Интенсив-курс «Сервисный UX-дизайн». Обучаться можно онлайн.
Когда:
С 5 по 14 февраля 2020 г.
Для кого:
Специалисты и менеджеры мира дизайн-проектирования и исследований UI/UX/CX, управления проектами/продуктами, фаундеры и другие, кто в теме.
Цель занятий:
Научить мыслить критически в вопросах решения бизнес-задач средствами человекоориентированного сервис-дизайна. Анонсируют много материала, который станет откровением даже для «прокачанных» и опытных профессионалов. Разберут канвас работы «DDx3» (тройной алмаз) и Решайн-мышление (методология РШСД).
Формат:
Основное обучение состоит из двух ступеней (можно купить обе ступени, а можно по одной):
1️⃣ 5,6,7 февраля: блок «Семинары-1». В формате дневных интенсивных семинаров будет рассказано о методологии проектирования продуктов и сервисов на базе ценностей клиентоориентированности. Проходит очно или онлайн.
Тематическая программа-1
Стоимость и регистрация
🔥 Если при регистрации указать код (в поле заявки) UD2000F20RS, то будет скидка 2000 рублей.
2️⃣ 12,13,14 февраля: блок «Семинары-2». Продолжение методического курса в формате дискуссионного клуба. Проходит онлайн.
Тематическая программа-2
Стоимость и регистрация
🔥 Если при регистрации указать код (в поле заявки) UD2000F20RS, то будет скидка 2000 рублей.
Отдельно от курса можно сходить (онлайн) на мастер-классы:
👉 7 февраля: Мастер-класс «Постановка задачи на проектирование» (встроенная часть блока «Семинары-1»).
Мастер-класс рассказывает о фундаментальных приёмах формирования постановки задачи на сервисное проектирование. В формате бизнес-игры участники учатся определять разные виды требований и ограничений для конкретного выбранного сервиса, а затем согласовывать их между собой, создавая «строительную площадку» с четкими границами под будущее здание сервисного дизайна. На занятии студенты в формате блиц-проектирования создают эскизы экранов пользовательского интерфейса государственного сервиса.
Регистрация
🔥 Промокод «Udobstvo-RSDS», чтобы получить скидку 500 рублей.
👉 14 февраля: Мастер-класс «Customer Journey Mapping&Construction» (встроенная часть блока «Семинары-2»).
Мастер-класс рассказывает о приёмах:
- картирования сценариев деятельности пользователей (Customer Journey Mapping) на базе проведения behavior based исследований особенностей использования сервисов реальными потребителями.
- анализа получившихся схем и эффектов с использованием оригинального подхода выявления и соотнесения барьеров/драйверов взаимодействия, причин эффектов и решений.
- генерации идей последующего усовершенствования сценария применения сервиса (Customer Journey Construction) с точки зрения многослойной системы дизайна — деятельности, функций, интерфейса.
Регистрация
🔥 Промо-код «Udobstvo-RSDS», чтобы получить скидку 500 рублей.
Фишка:
Это именно курс, а не набор презентаций.
Следующее занятие продолжает предыдущее, донося таким образом полную картину.
Отзывы:
На сайте РШСД, в группе FB
Вдохновляющая обратная связь
11 лет я проработал в заказной разработке. Это конвейер: взял проект — сдал проект, взял — сдал, взял — сдал ... Конечно, между взял и сдал куча всего происходит, включая провалы и грабли в лоб, но после сдачи обычно отсутствует обратная связь с миром пользователей. Максимум, клиент закажет поддержку решения и этой поддержкой займутся другие люди.
В итоге, у команды теряется важная связь: я сделал → этим пользуются. Самая плачевная ситуация на госпроектах, заказанных из-за приказа сверху — такие проекты могут делаться для галочки и мир пользователей там вообще отсутствует.
Вся соль в том, что обратная связь с миром пользователей очень важна для командного духа и сплочения. Именно истории реальных пользователей влияют на эмпатию и на огонь в глазах.
Я люблю продукты, люблю проекты с внедрением именно за возможность общаться с конечными пользователями.
Видеть, как мои решения помогают людям — именно в этом кайф и вдохновение.
Госпроект с хорошим бюджетом принесёт в разы меньше кайфа, чем создание любого продукта, которым будут пользоваться реальные люди.
Связь с миром пользователей — это командный клей. Не только UX-исследователи и менеджеры должны сталкиваться с этим миром — обратная связь должна доходить до каждого участника команды.
Транслировать обратную связь внутрь команды можно и нужно разными способами:
👉 рассылать отзывы,
👉 публиковать метрики: мы вчера сделали фичу, а уже сегодня её используют 4К человек.
👉 рассказывать интересные кейсы использования продукта, пользовательские истории.
Наличие обратной связи позволит каждому ощутить причастность к общему полезному делу.
Обратной связью и живыми историями люди будут гордиться, вдохновляться и рассказывать близким "на кухне".
Даже негативная обратная связь полезна и её не надо скрывать от команды.
Я уже писал про душевные письма, которые вкладываются в упаковки зубной пасты Splat.
Так вот, все эти письма написаны гендиректором Splat и заканчиваются фразой:
"Спасибо вам за живые и теплые письма, вопросы и благодарности. По понедельникам я собираю ваши письма и рассылаю всем в компании, чтобы каждый человек помнил, для каких прекрасных людей мы трудимся каждый день!"
Это очень круто — так и надо делать продукты для людей!
В общем, если ещё не все в команде знают, для каких прекрасных людей они трудятся, то самое время им об этом рассказать.
#совет #продакту
11 лет я проработал в заказной разработке. Это конвейер: взял проект — сдал проект, взял — сдал, взял — сдал ... Конечно, между взял и сдал куча всего происходит, включая провалы и грабли в лоб, но после сдачи обычно отсутствует обратная связь с миром пользователей. Максимум, клиент закажет поддержку решения и этой поддержкой займутся другие люди.
В итоге, у команды теряется важная связь: я сделал → этим пользуются. Самая плачевная ситуация на госпроектах, заказанных из-за приказа сверху — такие проекты могут делаться для галочки и мир пользователей там вообще отсутствует.
Вся соль в том, что обратная связь с миром пользователей очень важна для командного духа и сплочения. Именно истории реальных пользователей влияют на эмпатию и на огонь в глазах.
Я люблю продукты, люблю проекты с внедрением именно за возможность общаться с конечными пользователями.
Видеть, как мои решения помогают людям — именно в этом кайф и вдохновение.
Госпроект с хорошим бюджетом принесёт в разы меньше кайфа, чем создание любого продукта, которым будут пользоваться реальные люди.
Связь с миром пользователей — это командный клей. Не только UX-исследователи и менеджеры должны сталкиваться с этим миром — обратная связь должна доходить до каждого участника команды.
Транслировать обратную связь внутрь команды можно и нужно разными способами:
👉 рассылать отзывы,
👉 публиковать метрики: мы вчера сделали фичу, а уже сегодня её используют 4К человек.
👉 рассказывать интересные кейсы использования продукта, пользовательские истории.
Наличие обратной связи позволит каждому ощутить причастность к общему полезному делу.
Обратной связью и живыми историями люди будут гордиться, вдохновляться и рассказывать близким "на кухне".
Даже негативная обратная связь полезна и её не надо скрывать от команды.
Я уже писал про душевные письма, которые вкладываются в упаковки зубной пасты Splat.
Так вот, все эти письма написаны гендиректором Splat и заканчиваются фразой:
"Спасибо вам за живые и теплые письма, вопросы и благодарности. По понедельникам я собираю ваши письма и рассылаю всем в компании, чтобы каждый человек помнил, для каких прекрасных людей мы трудимся каждый день!"
Это очень круто — так и надо делать продукты для людей!
В общем, если ещё не все в команде знают, для каких прекрасных людей они трудятся, то самое время им об этом рассказать.
#совет #продакту
Искусственный интеллект и UX
Если вы не заметили, то разработка удобных продуктов от модели "какой UI сделать, чтобы получить классный UX" движется к модели "какой AI/ML применить, чтобы получить уникальный UX".
Всё больше продуктов используют элементы ИИ и отгородиться от этого скоро не получится никому.
В общем, кругозор по теме ИИ лучше прокачивать. Понимание, где и как можно применить ИИ пригодится и продактам, и аналитикам, и дизайнерам.
А пророс росток искусственного интеллекта уже давно, просто не было для него долгое время благодатной почвы в виде интернета и облачных вычислений.
В прошлом веке по теме ИИ было много достойных событий:
👉 1950 — 70 лет назад
Грей Уолтер (William Grey Walter), английский нейрофизиолог, ставит свои знаменитые кибернетические эксперименты с "черепашками". "Черепашки" представляют собой самодвижущиеся электромеханические тележки, способные ползти на свет или от него, обходить препятствия, заходить в “кормушку” для подзарядки разрядившихся аккумуляторов.
👉 1956 — 64 года назад
Невелл, Шау и Саймон (Carnegie Mellon University) создают Логического Теоретика (Logic Theorist), который использует рекурсивные методы исследования, чтобы решать математические задачи. Логического теоретика называют первой "экспертной системой" с элементами AI.
👉 1965 — 55 лет назад
В Стэнфордском университете начат проект DENDRAL, возглавляемый Брюсом Бучананом (Bruce Buchanan), Эдвардом Фейгенбаумом (Edward Feigenbaum) и нобелевским лауреатом Джошуа Ледербергом (Joshua Lederberg). Первая экспертная система, DENDRAL, воплощает базу знаний относительно анализа молекулярных структур. Последующая работа, выполненная в начале 70-ых, приведет к созданию Meta-DENDRAL - самообучающейся программы, которая автоматически изобретает новые правила для DENDRAL.
👉 1972 — 48 лет назад
В Институте Кибернетики под руководством академика Николая Михайловича Амосова создан автономный транспортный робот "ТАИР". Робот представляет собой трехколесную самоходную тележку, снабженную системой датчиков (дальномер и тактильные датчики), и управляется аппаратно реализованной нейронной сетью (узлы сети - специальные электронные схемы, собранные на транзисторах). Робот демонстрирует целенаправленное движение в естественной среде и обход препятствий в виде людей, деревьев, скамеек. Цель движения робота задается координатами точки на местности.
👉 1974 — 46 лет назад
Проводится первый чемпионат мира по шахматам среди компьютеров. Советская программа «Каисса» завоевывает титул первого компьютерного чемпиона мира по шахматам.
В этот же год. Разрабатываются четыре больших медицинских экспертных системы: MYCIN, PIP, CASNET и Internist. MYCIN, основанная на мощной системе правил, служит для обнаружения ошибок в медицинских заключениях и назначении антибиотиков. Пятью годами позже журнал Американской Медицинской Ассоциации опубликует исследование MYCIN на десяти испытательных случаях. MYCIN сделает такие же заключения, как и медицинские эксперты.
👉 1976 — 44 года назад
Дуглас Ленат (Douglas Lenat) демонстрирует систему искусственного интеллекта Автоматизированный Математик (Automated Mathematician - AM) как часть своей докторской диссертации в Стэнфорде. Интеллект AM позволяет производить свободно-управляемый поиск интересных предположений и делать "открытия" в теории чисел и абстрактной математике.
В тот же год. Texas Instruments осуществляет синтезирование человеческого голоса. Первоначально технология используется в учебном продукте для детей "Говори и записывай по буквам" ("Speak And Spell").
В тот же год. Компания Kurzweil представляет Kurzweil Reading Machine, которая читает любой печатный текст. Базирующаяся на системе распознавания символов, KRM предназначена быть средством помощи слепым людям.
Вот такие дела.
#UX #AI
Если вы не заметили, то разработка удобных продуктов от модели "какой UI сделать, чтобы получить классный UX" движется к модели "какой AI/ML применить, чтобы получить уникальный UX".
Всё больше продуктов используют элементы ИИ и отгородиться от этого скоро не получится никому.
В общем, кругозор по теме ИИ лучше прокачивать. Понимание, где и как можно применить ИИ пригодится и продактам, и аналитикам, и дизайнерам.
А пророс росток искусственного интеллекта уже давно, просто не было для него долгое время благодатной почвы в виде интернета и облачных вычислений.
В прошлом веке по теме ИИ было много достойных событий:
👉 1950 — 70 лет назад
Грей Уолтер (William Grey Walter), английский нейрофизиолог, ставит свои знаменитые кибернетические эксперименты с "черепашками". "Черепашки" представляют собой самодвижущиеся электромеханические тележки, способные ползти на свет или от него, обходить препятствия, заходить в “кормушку” для подзарядки разрядившихся аккумуляторов.
👉 1956 — 64 года назад
Невелл, Шау и Саймон (Carnegie Mellon University) создают Логического Теоретика (Logic Theorist), который использует рекурсивные методы исследования, чтобы решать математические задачи. Логического теоретика называют первой "экспертной системой" с элементами AI.
👉 1965 — 55 лет назад
В Стэнфордском университете начат проект DENDRAL, возглавляемый Брюсом Бучананом (Bruce Buchanan), Эдвардом Фейгенбаумом (Edward Feigenbaum) и нобелевским лауреатом Джошуа Ледербергом (Joshua Lederberg). Первая экспертная система, DENDRAL, воплощает базу знаний относительно анализа молекулярных структур. Последующая работа, выполненная в начале 70-ых, приведет к созданию Meta-DENDRAL - самообучающейся программы, которая автоматически изобретает новые правила для DENDRAL.
👉 1972 — 48 лет назад
В Институте Кибернетики под руководством академика Николая Михайловича Амосова создан автономный транспортный робот "ТАИР". Робот представляет собой трехколесную самоходную тележку, снабженную системой датчиков (дальномер и тактильные датчики), и управляется аппаратно реализованной нейронной сетью (узлы сети - специальные электронные схемы, собранные на транзисторах). Робот демонстрирует целенаправленное движение в естественной среде и обход препятствий в виде людей, деревьев, скамеек. Цель движения робота задается координатами точки на местности.
👉 1974 — 46 лет назад
Проводится первый чемпионат мира по шахматам среди компьютеров. Советская программа «Каисса» завоевывает титул первого компьютерного чемпиона мира по шахматам.
В этот же год. Разрабатываются четыре больших медицинских экспертных системы: MYCIN, PIP, CASNET и Internist. MYCIN, основанная на мощной системе правил, служит для обнаружения ошибок в медицинских заключениях и назначении антибиотиков. Пятью годами позже журнал Американской Медицинской Ассоциации опубликует исследование MYCIN на десяти испытательных случаях. MYCIN сделает такие же заключения, как и медицинские эксперты.
👉 1976 — 44 года назад
Дуглас Ленат (Douglas Lenat) демонстрирует систему искусственного интеллекта Автоматизированный Математик (Automated Mathematician - AM) как часть своей докторской диссертации в Стэнфорде. Интеллект AM позволяет производить свободно-управляемый поиск интересных предположений и делать "открытия" в теории чисел и абстрактной математике.
В тот же год. Texas Instruments осуществляет синтезирование человеческого голоса. Первоначально технология используется в учебном продукте для детей "Говори и записывай по буквам" ("Speak And Spell").
В тот же год. Компания Kurzweil представляет Kurzweil Reading Machine, которая читает любой печатный текст. Базирующаяся на системе распознавания символов, KRM предназначена быть средством помощи слепым людям.
Вот такие дела.
#UX #AI
Наши полезные собеседования
Все любят реальные кейсы и истории из реальной практики. И я такие люблю.
Сегодня решил рассказать про то, как мы в Velvica проводим собеседования.
Вам хотелось бы просто так потратить 2-3 часа своего времени? Скорее всего, нет.
Тем не менее, если ходить по скучным собеседованиям, то легко потратить довольно много времени, не получив ничего взамен.
Мы в Velvica построили процесс проведения собеседований так, чтобы в итоге остались довольны даже те, кому мы откажем.
Каким должно быть хорошее собеседование, если посмотреть на него глазами соискателя?
❤️ Комфортным
❤️ Интересным
❤️ Дающим новый полезный опыт
❤️ С обратной связью
Именно такие собеседования мы стараемся проводить. У нас две ступени собеседований — знакомство и техническое интервью.
Знакомство — мы задаём вопросы, нам задают вопросы, присматриваемся.
Техническое интервью — вторая ступень, доступная прошедшим первую.
На техническом интервью мы решаем условную задачу — например, если собеседуем аналитика или продакта, то проектируем новый продукт.
Соискатель шарит экран и в miro или draw.io начинает накидывать структуру продукта и его взаимосвязей с внешним миром.
Для задачи мы выбираем продукт, который концептуально похож на наш — это важно.
Например, это может быть биржа для покупки ценных бумаг или золота.
При таком подходе 1-1.5 часа собеседования пролетают мгновенно. Мы погружаемся в способ мышления соискателя и в его кругозор, а соискатель погружается в задачу и довольно увлечённо рисует схемки и отвечает на наши вопросы.
Если соискатель пока не дотягивает, то мы говорим, где именно были промахи. Можем даже посоветовать литературу или иные источники конкретных знаний.
Если соискатель хорош, то мы понимаем, в какие места продукта его надо погружать сильнее при онбординге, так как на собеседовании он "плавал" в знаниях по этой теме.
Мгновенная прикладная польза.
В итоге, обратная связь и полезный опыт гарантированно получают даже те, кому мы отказываем.
Собеседуем всегда дистанционно — не надо тратить время на дорогу и прочие ожидания.
В общем, если собеседование не интересное и работодатель не думает о комфорте и пользе для соискателя, то и работа такая же будет. Это повод задуматься.
И да, у нас открыта вакансия на позицию системного аналитика — шлите в личку резюме @GrekovM, будет незабываемо. Работать можно дистанционно.
#кактотак
Все любят реальные кейсы и истории из реальной практики. И я такие люблю.
Сегодня решил рассказать про то, как мы в Velvica проводим собеседования.
Вам хотелось бы просто так потратить 2-3 часа своего времени? Скорее всего, нет.
Тем не менее, если ходить по скучным собеседованиям, то легко потратить довольно много времени, не получив ничего взамен.
Мы в Velvica построили процесс проведения собеседований так, чтобы в итоге остались довольны даже те, кому мы откажем.
Каким должно быть хорошее собеседование, если посмотреть на него глазами соискателя?
❤️ Комфортным
❤️ Интересным
❤️ Дающим новый полезный опыт
❤️ С обратной связью
Именно такие собеседования мы стараемся проводить. У нас две ступени собеседований — знакомство и техническое интервью.
Знакомство — мы задаём вопросы, нам задают вопросы, присматриваемся.
Техническое интервью — вторая ступень, доступная прошедшим первую.
На техническом интервью мы решаем условную задачу — например, если собеседуем аналитика или продакта, то проектируем новый продукт.
Соискатель шарит экран и в miro или draw.io начинает накидывать структуру продукта и его взаимосвязей с внешним миром.
Для задачи мы выбираем продукт, который концептуально похож на наш — это важно.
Например, это может быть биржа для покупки ценных бумаг или золота.
При таком подходе 1-1.5 часа собеседования пролетают мгновенно. Мы погружаемся в способ мышления соискателя и в его кругозор, а соискатель погружается в задачу и довольно увлечённо рисует схемки и отвечает на наши вопросы.
Если соискатель пока не дотягивает, то мы говорим, где именно были промахи. Можем даже посоветовать литературу или иные источники конкретных знаний.
Если соискатель хорош, то мы понимаем, в какие места продукта его надо погружать сильнее при онбординге, так как на собеседовании он "плавал" в знаниях по этой теме.
Мгновенная прикладная польза.
В итоге, обратная связь и полезный опыт гарантированно получают даже те, кому мы отказываем.
Собеседуем всегда дистанционно — не надо тратить время на дорогу и прочие ожидания.
В общем, если собеседование не интересное и работодатель не думает о комфорте и пользе для соискателя, то и работа такая же будет. Это повод задуматься.
И да, у нас открыта вакансия на позицию системного аналитика — шлите в личку резюме @GrekovM, будет незабываемо. Работать можно дистанционно.
#кактотак
UX-Марафон #18
30 января (четверг) буду смотреть UX-Марафон #18 на тему "Дизайн-менеджмент".
Курирует Марафон Юрий Ветров — Дизайн-директор, Райффайзенбанк, ранее Mailru Group. Он же автор Дайджеста продуктового дизайна.
Мне, честно сказать, этот Марафон интересен не с точки зрения работы с дизайн-командами — у нас нет дизайн-команды.
А с точки зрения работы с продуктовыми командами.
Особый интерес вызывают:
🔥 Тематика проведения встреч в формате один на один. Её раскроет Сергей Кондауров, Арт-директор в Яндекс. Его тема: «500 встреч с дизайнерами «один на один» в год»
🔥 Работа с распределёнными командами — именно такая команда у нас. Эту тему раскрывают: Егор Коробейников из Miro, а также Лена Куликова из Райффайзенбанк.
Остальные темы и спикеры тоже весьма хороши: руководители дизайн-подразделений Яндекс, Райффайзенбанк, Альфа-банк, Miro, Badoo.
Билет стоит 2100-2800 рублей (зависит от наличия записей и доступа к презентациям).
Для канала сделали скидку 15%. При заказе билета надо указать код: ProUX15%
👉 Полная программа и регистрация по ссылке: https://bit.ly/36fvV5G
👉 Канал UX-Марафона в ТГ: https://tttttt.me/uxmarafon — там есть видео-анонсы предстоящих выступлений.
👉 С прошлого Марафона про психологию в дизайне у меня остались заметки на Medium — хороший Марафон был.
Кстати, а в вашей команде насыщенные встречи один на один проводятся?
30 января (четверг) буду смотреть UX-Марафон #18 на тему "Дизайн-менеджмент".
Курирует Марафон Юрий Ветров — Дизайн-директор, Райффайзенбанк, ранее Mailru Group. Он же автор Дайджеста продуктового дизайна.
Мне, честно сказать, этот Марафон интересен не с точки зрения работы с дизайн-командами — у нас нет дизайн-команды.
А с точки зрения работы с продуктовыми командами.
Особый интерес вызывают:
🔥 Тематика проведения встреч в формате один на один. Её раскроет Сергей Кондауров, Арт-директор в Яндекс. Его тема: «500 встреч с дизайнерами «один на один» в год»
🔥 Работа с распределёнными командами — именно такая команда у нас. Эту тему раскрывают: Егор Коробейников из Miro, а также Лена Куликова из Райффайзенбанк.
Остальные темы и спикеры тоже весьма хороши: руководители дизайн-подразделений Яндекс, Райффайзенбанк, Альфа-банк, Miro, Badoo.
Билет стоит 2100-2800 рублей (зависит от наличия записей и доступа к презентациям).
Для канала сделали скидку 15%. При заказе билета надо указать код: ProUX15%
👉 Полная программа и регистрация по ссылке: https://bit.ly/36fvV5G
👉 Канал UX-Марафона в ТГ: https://tttttt.me/uxmarafon — там есть видео-анонсы предстоящих выступлений.
👉 С прошлого Марафона про психологию в дизайне у меня остались заметки на Medium — хороший Марафон был.
Кстати, а в вашей команде насыщенные встречи один на один проводятся?