Франция, любовь моя.
На иллюстрациях выше - два варианта заголовка одного и того же окна браузера, открывающегося в Телеге при нажатии на ссылку. Разница - исключительно в установленном языке (на надписи про билайн над окном не смотрите, это я очень криво сделал скриншот). О, какова же разница!
Первый - английский. В нем пользователь, точно суровый шахтёр времён Индустриальной революции, вылезает из интернет-шахты, перемазанный с ног до головы незнамо чем, с силой выдыхает: "Done", - и закрывает окно. Лицо его черно, профиль суров, глаза светятся белизной берегов Альбиона.
Второй - французский. В нем пользователь, пресыщенный парижский повеса, сидит в кафе на Монмартре. Слева дымится чашечка неплохого (по меркам Монмартра, конечно) кофе, справа дожидается своего часа недоеденный круассан (вы же помните, что круассаны рвут на кусочки?), во рту небрежно догорает своё сигарета. Вечереет. "OK" - лениво думает повеса и медленно закрывает окно. Глаза его покрывает сытая поволока, его губы жирны и гедонистичны, а руки - холёны и розовы как поросячья кожа, ведь они никогда не знали физического труда.
На иллюстрациях выше - два варианта заголовка одного и того же окна браузера, открывающегося в Телеге при нажатии на ссылку. Разница - исключительно в установленном языке (на надписи про билайн над окном не смотрите, это я очень криво сделал скриншот). О, какова же разница!
Первый - английский. В нем пользователь, точно суровый шахтёр времён Индустриальной революции, вылезает из интернет-шахты, перемазанный с ног до головы незнамо чем, с силой выдыхает: "Done", - и закрывает окно. Лицо его черно, профиль суров, глаза светятся белизной берегов Альбиона.
Второй - французский. В нем пользователь, пресыщенный парижский повеса, сидит в кафе на Монмартре. Слева дымится чашечка неплохого (по меркам Монмартра, конечно) кофе, справа дожидается своего часа недоеденный круассан (вы же помните, что круассаны рвут на кусочки?), во рту небрежно догорает своё сигарета. Вечереет. "OK" - лениво думает повеса и медленно закрывает окно. Глаза его покрывает сытая поволока, его губы жирны и гедонистичны, а руки - холёны и розовы как поросячья кожа, ведь они никогда не знали физического труда.
Раз уж у нас суббота, расскажу еще одну историю. Я ее очень часто рассказываю на своих выступлениях, так что если вы меня и так неплохо знаете, подкидываю годную идею: промотать этот пост и вместо этого пойти пить березовый сок, есть чашушули, смотреть на Фудзияму, пожирать сладкий картофель батат, сажать саженцы на даче, плясать гопак, ну или что вы там обычно делаете по субботам.
А история в следующем. Жила-была одна страховая компания, которая решила сделать себе личный кабинет пользователя: всякое там оформление страховок, просмотр полисов, туда-сюда. Нет, так-то у них личный кабинет уже был, но он был таким, что, честно говоря, лучше бы его никакого не было.
И вот решила эта страховая компания сделать все по уму в наш век Человекоориентированного Дизайна, Юикса-Сиикса и прочего Хуикса, и отправилась она с заказом в Специализированную Юзабилистическую Контору. Специальная Юзабилистическая контора была клевая: она носила какой-то красивый термин в названии (типа, НИИ ЮИКС или, там, АРТ ОФ ИНТЕРФЭЙС), штат ее сплошняком состоял из специально обученных психологических людей, издали похожих на хипстеров, а в клиентах числился весь белый свет вплоть до ФГУП «ГУСЬ-ХРУСТАЛЬНЫЙ АЛМАЗВНЕШТОРГЭКСПОРТОБЪЕДИНЕНИЕ».
Эти серьезные ребята сходу включились в работу, подняли на крыло целый безумный аэроплан UX-процессов, исследований, групповых фасилитаций, кастдев-оргий и всего такого - и уже через два месяца с лишним принесли заказчику результат: нарисованные интерфейсы лучшего в мире ЛК. Интерфейсы были и правда клевые: от картинок веяло эстетической мощью, за каждой кнопкой скрывалась какая-нибудь UX-премудрость, а на любой вопрос «А почему здесь так?» творцы подпускали нервическую дрожащую ноту в голос и заявляли «ВЫ БЫ ВИДЕЛИ КАКОЙ ТАМ СИДЖЭЭМ» - после чего от них сразу отставали.
Заказчик остался доволен, взял интерфейс и понес его в другую контору - разрабатывать. В другой конторе - крепком, нормальном таком веб-разработчике - интерфейсы взяли с радостью, но под одним условием: давайте, дескать, мы напишем еще небольшой документ, который будет описывать техническую сторону дела, чтобы разработчикам было понятнее, как интерфейс работает. Быстренько напишем, согласуем - и дальше уже будем разрабатывать, чтобы не только уж по картинкам что-то лабать.
Заказчик был не против, все ударили по рукам, и работа над ТЗ закипела. Впрочем, «закипела» - это громко сказано, потому что она по факту и закипеть не успела: практически сразу же, с главного же экрана ЛК, стало ясно, что в интерфейсе творится что-то поганое.
Нет, поймите меня правильно: интерфейсы сами по себе и правда были клевые, но при попытке описать их логику и привязать ее к существующим системам заказчика оказалось, что интерфейс нарисован как будто в параллельной реальности: например, в интерфейс было заложено редактирование детальной информации по полисам (чего система категорически не позволяла), но при этом не было никаких намеков на заказ нового полиса (как раз эта штука была в системе и без нареканий работала в предыдущей версии ЛК). Интерфейсом предполагалось, что какие-то данные будут подтягиваться в реальном времени - тогда как в реальности они получаются очень долго и раз в сутки. В реальности заявка на определенную справку составляла, по законодательству, 20 полей - а тут их было 3. Ну и тому подобная порнография.
Разработчик изрядно удивился, поднял брови и пошел к заказчику - выяснять, а с хера ли такая радуга в небе возникла. Заказчик, справедливости ради сказать, быстро въехал в тему, быстро забеспокоился и пригласил к себе ребят-юзабилистов - разобраться, как так-то.
И вот тут настает мой любимый момент. Юзабилистические ребята, представшие перед судом Ее Величества Логики, и глазом не моргнули и заявили следующее: «МЫ НЕ ИНЖЕНЕРЫ МЫ КОНСАЛТЕРЫ И ПСИХОЛОГИ И СДЕЛАЛИ УДОБНО А РАЗРАБОТКА ПУСТЬ ПОДТЯГИВАЕТСЯ ОНА ВСЕГДА ВОЗЬМЕТ СВОЕ ПУСТЬ РАЗРАБОТЧИКИ ПОСИДЯТ ПОДУМАЮТ И СДЕЛАЮТ ЭТО УЖЕ ИХ ЗОНА ОТВЕТСТВЕННОСТИ».
А история в следующем. Жила-была одна страховая компания, которая решила сделать себе личный кабинет пользователя: всякое там оформление страховок, просмотр полисов, туда-сюда. Нет, так-то у них личный кабинет уже был, но он был таким, что, честно говоря, лучше бы его никакого не было.
И вот решила эта страховая компания сделать все по уму в наш век Человекоориентированного Дизайна, Юикса-Сиикса и прочего Хуикса, и отправилась она с заказом в Специализированную Юзабилистическую Контору. Специальная Юзабилистическая контора была клевая: она носила какой-то красивый термин в названии (типа, НИИ ЮИКС или, там, АРТ ОФ ИНТЕРФЭЙС), штат ее сплошняком состоял из специально обученных психологических людей, издали похожих на хипстеров, а в клиентах числился весь белый свет вплоть до ФГУП «ГУСЬ-ХРУСТАЛЬНЫЙ АЛМАЗВНЕШТОРГЭКСПОРТОБЪЕДИНЕНИЕ».
Эти серьезные ребята сходу включились в работу, подняли на крыло целый безумный аэроплан UX-процессов, исследований, групповых фасилитаций, кастдев-оргий и всего такого - и уже через два месяца с лишним принесли заказчику результат: нарисованные интерфейсы лучшего в мире ЛК. Интерфейсы были и правда клевые: от картинок веяло эстетической мощью, за каждой кнопкой скрывалась какая-нибудь UX-премудрость, а на любой вопрос «А почему здесь так?» творцы подпускали нервическую дрожащую ноту в голос и заявляли «ВЫ БЫ ВИДЕЛИ КАКОЙ ТАМ СИДЖЭЭМ» - после чего от них сразу отставали.
Заказчик остался доволен, взял интерфейс и понес его в другую контору - разрабатывать. В другой конторе - крепком, нормальном таком веб-разработчике - интерфейсы взяли с радостью, но под одним условием: давайте, дескать, мы напишем еще небольшой документ, который будет описывать техническую сторону дела, чтобы разработчикам было понятнее, как интерфейс работает. Быстренько напишем, согласуем - и дальше уже будем разрабатывать, чтобы не только уж по картинкам что-то лабать.
Заказчик был не против, все ударили по рукам, и работа над ТЗ закипела. Впрочем, «закипела» - это громко сказано, потому что она по факту и закипеть не успела: практически сразу же, с главного же экрана ЛК, стало ясно, что в интерфейсе творится что-то поганое.
Нет, поймите меня правильно: интерфейсы сами по себе и правда были клевые, но при попытке описать их логику и привязать ее к существующим системам заказчика оказалось, что интерфейс нарисован как будто в параллельной реальности: например, в интерфейс было заложено редактирование детальной информации по полисам (чего система категорически не позволяла), но при этом не было никаких намеков на заказ нового полиса (как раз эта штука была в системе и без нареканий работала в предыдущей версии ЛК). Интерфейсом предполагалось, что какие-то данные будут подтягиваться в реальном времени - тогда как в реальности они получаются очень долго и раз в сутки. В реальности заявка на определенную справку составляла, по законодательству, 20 полей - а тут их было 3. Ну и тому подобная порнография.
Разработчик изрядно удивился, поднял брови и пошел к заказчику - выяснять, а с хера ли такая радуга в небе возникла. Заказчик, справедливости ради сказать, быстро въехал в тему, быстро забеспокоился и пригласил к себе ребят-юзабилистов - разобраться, как так-то.
И вот тут настает мой любимый момент. Юзабилистические ребята, представшие перед судом Ее Величества Логики, и глазом не моргнули и заявили следующее: «МЫ НЕ ИНЖЕНЕРЫ МЫ КОНСАЛТЕРЫ И ПСИХОЛОГИ И СДЕЛАЛИ УДОБНО А РАЗРАБОТКА ПУСТЬ ПОДТЯГИВАЕТСЯ ОНА ВСЕГДА ВОЗЬМЕТ СВОЕ ПУСТЬ РАЗРАБОТЧИКИ ПОСИДЯТ ПОДУМАЮТ И СДЕЛАЮТ ЭТО УЖЕ ИХ ЗОНА ОТВЕТСТВЕННОСТИ».
В общем, улавливаете, да? Ребята, которые занимаются интерфейсами, вертеть хотели какие-то там технические ограничения и сработали как настоящие Творцы в Сфере Чистого Разума, сделав Хорошо и Удобно. А уж что какие-то черти-разработчики не могут это сделать - это уже их проблемы, пусть учатся.
И вот тут, котаны, на белый свет выползла невообразимая херня: этим хуикс-гуру было невдомек, что доработки по их психологическим капризам потребуют столько денег и отнимут столько времени, что проще будет разогнать страховую компанию и организовать какую-нибудь новую. Под удар был поставлен весь продукт, потому что 3 месяца работы были потрачены впустую, деньги были съедены зря, и руководство страховой было готово махнуть рукой и сказать «ДАВАЙТЕ ЖИТЬ СО СТАРОЙ СИСТЕМОЙ А ЭТИХ UX ПИДАРАСОВ БОЛЬШЕ НЕ БУДЕМ ЗВАТЬ ОТ НИХ ВРЕД ОДИН» - и, что характерно, они были бы не так уж неправы.
В итоге все кончилось хорошо и интерфейс перерисовали под корень (и уже вместе с разработчиками), но вот эту фразу «МЫ НЕ ИНЖЕНЕРЫ МЫ ПСИХОЛОГИ», к сожалению, я и сам слышал миллион раз, чтобы понимать - эта ебалайка будет играть вновь и вновь, пока все не поймут, что психология и инженерия - не космически разные явления, а стороны одной монеты под названием UX.
Впрочем, про это мы с вами еще поговорим - и не раз.
И вот тут, котаны, на белый свет выползла невообразимая херня: этим хуикс-гуру было невдомек, что доработки по их психологическим капризам потребуют столько денег и отнимут столько времени, что проще будет разогнать страховую компанию и организовать какую-нибудь новую. Под удар был поставлен весь продукт, потому что 3 месяца работы были потрачены впустую, деньги были съедены зря, и руководство страховой было готово махнуть рукой и сказать «ДАВАЙТЕ ЖИТЬ СО СТАРОЙ СИСТЕМОЙ А ЭТИХ UX ПИДАРАСОВ БОЛЬШЕ НЕ БУДЕМ ЗВАТЬ ОТ НИХ ВРЕД ОДИН» - и, что характерно, они были бы не так уж неправы.
В итоге все кончилось хорошо и интерфейс перерисовали под корень (и уже вместе с разработчиками), но вот эту фразу «МЫ НЕ ИНЖЕНЕРЫ МЫ ПСИХОЛОГИ», к сожалению, я и сам слышал миллион раз, чтобы понимать - эта ебалайка будет играть вновь и вновь, пока все не поймут, что психология и инженерия - не космически разные явления, а стороны одной монеты под названием UX.
Впрочем, про это мы с вами еще поговорим - и не раз.
🥰1
«ЛЁХ А ЛЁХ А ЧЕГО ПОЧИТАТЬ МОЖНО ПРО ВОТ ЭТОТ ТВОЙ ДИЗАЙН ШМИЗАЙН ПРОЕКТИРОВАНИЕ ШМОЕКТИРОВАНИЕ?» - задают мне иногда вопрос продвинутые товарищи.
Что ж, извольте мои рекомендации. Я считаю, что начинающему проектировщику/дизайнеру/UX-кому-угодно нужно прочесть для начала две с половиной книги. Все эти книги классные, но объединяет их одно: увидев их на полке магазина, вы бы их никогда сами не купили бы.
Первая книга - Алан Купер, «Психбольница в руках пациентов». Это обалденная книга хорошим языком рассказывает о том, как подступаться к UX: от самых азов типа важности UX до, допустим, принципов проведения исследований. Купер много пишет про психологическую составляющую, но постоянно делает реверансы в сторону технологий и инженерного дела, что постоянно греет мою душу. Настоятельно рекомендую.
В английском варианте название, кстати, более задорное - The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.
Вторая книга - Карл Вигерс, «Разработка требований к программному обеспечению». За зубодробительно отвратительным названием (на английском оно звучит полегче, но не особо - Software Requirements) скрывается очень умная, тонкая и многомерная книга, в которой Вигерс раскрывает основы проектирования структуры продукта - от бизнес-требований до работы с техническими ограничениями, - отдавая должное психологии, работе с пользовательским опытом и всему такому.
Что забавно, Вигерс и Купер в огромной мере дополняют друг друга - Вигерс пишет больше про потоки данных, бизнес-требования, функциональность и прочую системную аналитику, а Купер - про психологию, интерфейсы и прочее-психологическое, но при этом они оба подчеркивают важность и психологии, и инженерии в нашем деле.
И есть еще вторая-с-половиной книга, которая меркнет по своим масштабам в сравнении с Купером и Вигерсом, но которая содержит много отличных практических советов и идей по части визуального дизайна и интерфейсов - это «Ководство» Артемия Татьяновича Лебедева, которое доступно на сайте Студии и в расширенном бумажном виде. Эта книга когда-то сильно на меня повлияла, и я ее рекомендую к ознакомлению хотя бы в цифровом формате: все-таки Лебедев не зря свой хлеб ел.
И вот как эти книги в вас раскроются:
1. Вы поймете, что проектирование и дизайн суть сложный, многоярусный процесс с кучей интересных деталей и нюансов.
2. Вы не будете падать в обморок при словах «моделирование бизнес-процессов» и «проведение качественного интервью», а будете знать, какие инструменты существуют и в каких случаях их надо применять.
3. Вы отполируете полученные знания советами от Лебедева, которые порой очень интересные и глубокие.
4. И самое главное: после прочтения двух первых книг вы поймете, куда вам двигаться дальше в своем развитии. Если у вас ёкнет сердце при чтении Купера - вам верная дорога в UX-аналитику, проектирование взаимодействия с пользователем, вот это всё; ёкнет при чтении Вигерса - то вам верная дорога в системный анализ, работу с бизнесом и так далее. Ёкнет и там, и там - что ж, поздравляю, вы продуктовый дизайнер, и будете заниматься продуктом целиком.
Вы спросите - «ЛЁХА ПОГОДЬ А ЧЕМ ПРОДУКТОВЫЙ ДИЗАЙНЕР ОТЛИЧАЕТСЯ ОТ ПРОСТО ДИЗАЙНЕРА» - но я вежливо зевну и пойду лежать пьяный под мангалом. Вон погода какая хорошая. Да и шашлык стынет-с.
#книги
Что ж, извольте мои рекомендации. Я считаю, что начинающему проектировщику/дизайнеру/UX-кому-угодно нужно прочесть для начала две с половиной книги. Все эти книги классные, но объединяет их одно: увидев их на полке магазина, вы бы их никогда сами не купили бы.
Первая книга - Алан Купер, «Психбольница в руках пациентов». Это обалденная книга хорошим языком рассказывает о том, как подступаться к UX: от самых азов типа важности UX до, допустим, принципов проведения исследований. Купер много пишет про психологическую составляющую, но постоянно делает реверансы в сторону технологий и инженерного дела, что постоянно греет мою душу. Настоятельно рекомендую.
В английском варианте название, кстати, более задорное - The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.
Вторая книга - Карл Вигерс, «Разработка требований к программному обеспечению». За зубодробительно отвратительным названием (на английском оно звучит полегче, но не особо - Software Requirements) скрывается очень умная, тонкая и многомерная книга, в которой Вигерс раскрывает основы проектирования структуры продукта - от бизнес-требований до работы с техническими ограничениями, - отдавая должное психологии, работе с пользовательским опытом и всему такому.
Что забавно, Вигерс и Купер в огромной мере дополняют друг друга - Вигерс пишет больше про потоки данных, бизнес-требования, функциональность и прочую системную аналитику, а Купер - про психологию, интерфейсы и прочее-психологическое, но при этом они оба подчеркивают важность и психологии, и инженерии в нашем деле.
И есть еще вторая-с-половиной книга, которая меркнет по своим масштабам в сравнении с Купером и Вигерсом, но которая содержит много отличных практических советов и идей по части визуального дизайна и интерфейсов - это «Ководство» Артемия Татьяновича Лебедева, которое доступно на сайте Студии и в расширенном бумажном виде. Эта книга когда-то сильно на меня повлияла, и я ее рекомендую к ознакомлению хотя бы в цифровом формате: все-таки Лебедев не зря свой хлеб ел.
И вот как эти книги в вас раскроются:
1. Вы поймете, что проектирование и дизайн суть сложный, многоярусный процесс с кучей интересных деталей и нюансов.
2. Вы не будете падать в обморок при словах «моделирование бизнес-процессов» и «проведение качественного интервью», а будете знать, какие инструменты существуют и в каких случаях их надо применять.
3. Вы отполируете полученные знания советами от Лебедева, которые порой очень интересные и глубокие.
4. И самое главное: после прочтения двух первых книг вы поймете, куда вам двигаться дальше в своем развитии. Если у вас ёкнет сердце при чтении Купера - вам верная дорога в UX-аналитику, проектирование взаимодействия с пользователем, вот это всё; ёкнет при чтении Вигерса - то вам верная дорога в системный анализ, работу с бизнесом и так далее. Ёкнет и там, и там - что ж, поздравляю, вы продуктовый дизайнер, и будете заниматься продуктом целиком.
Вы спросите - «ЛЁХА ПОГОДЬ А ЧЕМ ПРОДУКТОВЫЙ ДИЗАЙНЕР ОТЛИЧАЕТСЯ ОТ ПРОСТО ДИЗАЙНЕРА» - но я вежливо зевну и пойду лежать пьяный под мангалом. Вон погода какая хорошая. Да и шашлык стынет-с.
#книги
👍3
Ладно. Мы поговорили с вами про ограничения, окружающие продукт (бизнес-, пользовательские, технологические), теперь пришла пора поговорить и про сам цифровой продукт.
На поверхности все просто и непросто одновременно. Если лезть в задротские определения, то продукт можно охарактиризовать так: «Товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности потребителе». В применении к тому, о чем я вам талдычил всю прошлую неделю напролет, это значит следующее: «Продукт - это такая штука, которая предназначена для решения задач пользователей, которая выгодна своему заказчику и которую реально разработать». То есть, иными словами, продукт - это некий механизм, который увязывает пользователей и бизнес в единое целое посредством конкретных технологий.
Определение вроде норм, но за одним изъяном - непонятно, что с ним делать дальше кроме как повесить на стену любоваться. В этом, конечно, крест и боль нашей отрасли - она переполнена мишурой сложных слов, за которыми на серьезных щах можно замаскировать что угодно. Так, к примеру, у меня на столе лежит книга от одного уважаемого UX-мыслителя, в которой дальше третьего предложения прочесть невозможно - ты уже забываешь не то что канву повествования, но и свое собственное имя (именно поэтому я, когда читал эту книгу, выписывал свое имя себе на руку). Зато того, кто прорвался, в середине книги ждет прекрасная награда - разбор анекдотов про дальнобойщиков с выделением факторов юмора (буквально). Заканчивается все чудовищными графиками, которые меня впечатлили настолько, что я даже не вспомню, о чем они были. Вот такой мощный фолиант.
Стоит ли добавлять, что этой книгой я люблю пугать непуганых UX-девиц, имеющих неосторожность заглянуть ко мне в гости?
Но мы отвлеклись. В общем, что я хочу сказать: играться с термином «продукт» можно хоть до морковкина заговенья, но нам-то с вами важен практический смысл, а не блестки научных определений, так?
Именно поэтому продукт удобнее определять не одним термином, а рассматривать его с нескольких позиций - точно как слепцы в той старой басне, помните, где они еще ощупывали слона, один сказал, пощупав хобот, «ЭТО ЗМЕЯ», второй сказал, пощупав бок, «ЭТО СТЕНА», а третий сказал откуда-то сзади «НЕТ ЭТО ВСЕ ТАКИ ЗМЕЯ»*
Вот и мы попробуем взглянуть на продукт с нескольких точек зрения, понять, что мы видим - и как это все можно применять на практике.
И точек этих у нас, для начала, будет три - информационная архитектура (то есть то, что составляет информационную суть нашего продукта; не путать с навигационной структурой страниц или экранов), функциональность (то есть то, что продукт делает) и интерфейсы (то есть то, как продукт выглядит в той части, которая обращена к пользователю).
После этого многие вещи начнут вставать на свои понятные места.
#продукт
* Третий слепец нащупал слоновий хвост, господа перверты.
На поверхности все просто и непросто одновременно. Если лезть в задротские определения, то продукт можно охарактиризовать так: «Товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности потребителе». В применении к тому, о чем я вам талдычил всю прошлую неделю напролет, это значит следующее: «Продукт - это такая штука, которая предназначена для решения задач пользователей, которая выгодна своему заказчику и которую реально разработать». То есть, иными словами, продукт - это некий механизм, который увязывает пользователей и бизнес в единое целое посредством конкретных технологий.
Определение вроде норм, но за одним изъяном - непонятно, что с ним делать дальше кроме как повесить на стену любоваться. В этом, конечно, крест и боль нашей отрасли - она переполнена мишурой сложных слов, за которыми на серьезных щах можно замаскировать что угодно. Так, к примеру, у меня на столе лежит книга от одного уважаемого UX-мыслителя, в которой дальше третьего предложения прочесть невозможно - ты уже забываешь не то что канву повествования, но и свое собственное имя (именно поэтому я, когда читал эту книгу, выписывал свое имя себе на руку). Зато того, кто прорвался, в середине книги ждет прекрасная награда - разбор анекдотов про дальнобойщиков с выделением факторов юмора (буквально). Заканчивается все чудовищными графиками, которые меня впечатлили настолько, что я даже не вспомню, о чем они были. Вот такой мощный фолиант.
Стоит ли добавлять, что этой книгой я люблю пугать непуганых UX-девиц, имеющих неосторожность заглянуть ко мне в гости?
Но мы отвлеклись. В общем, что я хочу сказать: играться с термином «продукт» можно хоть до морковкина заговенья, но нам-то с вами важен практический смысл, а не блестки научных определений, так?
Именно поэтому продукт удобнее определять не одним термином, а рассматривать его с нескольких позиций - точно как слепцы в той старой басне, помните, где они еще ощупывали слона, один сказал, пощупав хобот, «ЭТО ЗМЕЯ», второй сказал, пощупав бок, «ЭТО СТЕНА», а третий сказал откуда-то сзади «НЕТ ЭТО ВСЕ ТАКИ ЗМЕЯ»*
Вот и мы попробуем взглянуть на продукт с нескольких точек зрения, понять, что мы видим - и как это все можно применять на практике.
И точек этих у нас, для начала, будет три - информационная архитектура (то есть то, что составляет информационную суть нашего продукта; не путать с навигационной структурой страниц или экранов), функциональность (то есть то, что продукт делает) и интерфейсы (то есть то, как продукт выглядит в той части, которая обращена к пользователю).
После этого многие вещи начнут вставать на свои понятные места.
#продукт
* Третий слепец нащупал слоновий хвост, господа перверты.
❤1👍1
Поелику я болею второй день подряд, то могу позволить себе запахнуться в халат c кистями, покачаться туда-сюда в кресле-качалке и великосветски порассуждать про продукт.
Предупреждаю, сегодняшний выпуск у нас будет ультрахардкорным и всего лишь с одним словом «жопа» - но дальше мы без этого никуда не уедем. Так что запасайтесь жбаном водки - и вперед, в увлекательное путешествие в мир задротских построений!
Итак, информационная архитектура, функциональность и интерфейсы - вот три точки зрения, с которых можно исчерпывающе (ну, почти) описать любой продукт.
«ЗАЧЕМ ОНО НАХЕР НАДО?» - грубо, но по существу спросите вы. А надо оно для двух задач: во-первых, составить представление о логике уже существующего продукта (например, если вы вознамерились его перепиливать), а во-вторых - продумать и объяснить логику еще не существующего продукта так, чтобы его можно было впоследствии разработать (это, кажется то, что в лучших домах Европы зовется проектированием, n’est-ce pas?).
Вот возьмите пример с моей горе-историей про карту банкоматов: по факту, я вам рассказал, какой ад и израиль творился там со всех точек зрения сразу - и с данными там был капец (вернее, с источником для этих данных), и с функциональностью кранты (то есть с получением и агрегацией данных), и с интерфейсами жопа (то есть с отображением данных в картинках). И подобного «тройственного» взгляда на продукт более чем достаточно (ну, почти), чтобы понять, что в продукте с логикой обстоит так или не так.
А теперь поговорим поподробнее про каждую точку зрения.
Информационно-архитектурная точка зрения описывает, какими данными - т.е. какой информацией - пользуется наш продукт в своей нелегкой продуктовой жизни. Для интернет-магазинов это будет информация по товарам и их принадлежности к товарным категориям, информация по пользователям и совершаемым ими заказам. Для приложения типа Инстаграма это будут фотографии с подписями, пользователи, а также сообщения, которыми пользователи в Инстаграме обмениваются. Для моей горе-карты банкоматов это будут отображаемые точки банкоматов вместе с кучей другой информации. Информационная архитектура, выражаясь высоким языком задротства, описывает объектную модель нашего продукта - какие сущности в нем есть, какие у них атрибуты, как они между собой связаны. Не торопитесь падать в обморок: в свое время я много буду про это рассказывать, пока запомните так.
Все эти данные в продукте лежат не просто так, но чтобы с ними что-то происходило - например, данные могут импортироваться (то есть загружаться) в наш продукт, как это происходило в случае с картой банкоматов, а могут и экспортироваться (то есть выгружаться), как это происходит в том случае, когда пользователь сделал заказ в интернет-магазине и в базу товаров 1С полетела информация - вот, Борис Петрович заказал себе чай для похудания, извольте. Информация может трансформироваться (например, цена на товар вдруг изменилась), а может и удаляться (например, пользователь в сердцах плюнул, не найдя любимого камамбера, взял и удалил свою учетную запись).
В каждом из этих случаев с информацией будет что-то происходить - и за описание того, что, как и когда происходит с информацией внутри продукта (как делается заказ, как в систему подгружаются товары из 1С-ки, как обновляется информация по банкоматам) и отвечает функциональная точка зрения на продукт. И она тесно связана с информационной архитектурой - любая функция чаще всего вовлекает в работу какие-то данные.
Теперь нам осталось поговорить еще про самое интересное - про интерфейсы, после чего о продукте по верхам будет сказано все (ну, почти).
«ЛЁХА ТЫ ЗАДРАЛ С ЭТИМ СВОИМ ‘НУ ПОЧТИ’ ЧТО ТАМ ЕЩЕ В ПРОДУКТЕ ЕСТЬ ПРИЗНАВАЙСЯ?» - взбеленитесь внимательные вы. Терпение, Ватсон, терпение. Все расскажу в следующем выпуске.
Предупреждаю, сегодняшний выпуск у нас будет ультрахардкорным и всего лишь с одним словом «жопа» - но дальше мы без этого никуда не уедем. Так что запасайтесь жбаном водки - и вперед, в увлекательное путешествие в мир задротских построений!
Итак, информационная архитектура, функциональность и интерфейсы - вот три точки зрения, с которых можно исчерпывающе (ну, почти) описать любой продукт.
«ЗАЧЕМ ОНО НАХЕР НАДО?» - грубо, но по существу спросите вы. А надо оно для двух задач: во-первых, составить представление о логике уже существующего продукта (например, если вы вознамерились его перепиливать), а во-вторых - продумать и объяснить логику еще не существующего продукта так, чтобы его можно было впоследствии разработать (это, кажется то, что в лучших домах Европы зовется проектированием, n’est-ce pas?).
Вот возьмите пример с моей горе-историей про карту банкоматов: по факту, я вам рассказал, какой ад и израиль творился там со всех точек зрения сразу - и с данными там был капец (вернее, с источником для этих данных), и с функциональностью кранты (то есть с получением и агрегацией данных), и с интерфейсами жопа (то есть с отображением данных в картинках). И подобного «тройственного» взгляда на продукт более чем достаточно (ну, почти), чтобы понять, что в продукте с логикой обстоит так или не так.
А теперь поговорим поподробнее про каждую точку зрения.
Информационно-архитектурная точка зрения описывает, какими данными - т.е. какой информацией - пользуется наш продукт в своей нелегкой продуктовой жизни. Для интернет-магазинов это будет информация по товарам и их принадлежности к товарным категориям, информация по пользователям и совершаемым ими заказам. Для приложения типа Инстаграма это будут фотографии с подписями, пользователи, а также сообщения, которыми пользователи в Инстаграме обмениваются. Для моей горе-карты банкоматов это будут отображаемые точки банкоматов вместе с кучей другой информации. Информационная архитектура, выражаясь высоким языком задротства, описывает объектную модель нашего продукта - какие сущности в нем есть, какие у них атрибуты, как они между собой связаны. Не торопитесь падать в обморок: в свое время я много буду про это рассказывать, пока запомните так.
Все эти данные в продукте лежат не просто так, но чтобы с ними что-то происходило - например, данные могут импортироваться (то есть загружаться) в наш продукт, как это происходило в случае с картой банкоматов, а могут и экспортироваться (то есть выгружаться), как это происходит в том случае, когда пользователь сделал заказ в интернет-магазине и в базу товаров 1С полетела информация - вот, Борис Петрович заказал себе чай для похудания, извольте. Информация может трансформироваться (например, цена на товар вдруг изменилась), а может и удаляться (например, пользователь в сердцах плюнул, не найдя любимого камамбера, взял и удалил свою учетную запись).
В каждом из этих случаев с информацией будет что-то происходить - и за описание того, что, как и когда происходит с информацией внутри продукта (как делается заказ, как в систему подгружаются товары из 1С-ки, как обновляется информация по банкоматам) и отвечает функциональная точка зрения на продукт. И она тесно связана с информационной архитектурой - любая функция чаще всего вовлекает в работу какие-то данные.
Теперь нам осталось поговорить еще про самое интересное - про интерфейсы, после чего о продукте по верхам будет сказано все (ну, почти).
«ЛЁХА ТЫ ЗАДРАЛ С ЭТИМ СВОИМ ‘НУ ПОЧТИ’ ЧТО ТАМ ЕЩЕ В ПРОДУКТЕ ЕСТЬ ПРИЗНАВАЙСЯ?» - взбеленитесь внимательные вы. Терпение, Ватсон, терпение. Все расскажу в следующем выпуске.
P.S. А, и еще. Я чувствую, что ряд читателей уже точит вилы и разжигает факелы по следующему поводу: «ЛЁХА НО НАС УЧИЛИ ЧТО ИНФОРМАЦИОННАЯ АРХИТЕКТУРА ЭТО СТРАНИЦЫ СОЕДИНЕННЫЕ СТРЕЛОЧКАМИ А ТЫ ГОВОРИШЬ КАКУЮ ТО ЧУХНЮ ИЗ ВЫСШЕЙ МАТЕМАТИКИ».
Что ж, все дело в том, что термин «информационная архитектура» у нас в UX-сфере понимается на дикость однобоко и тупо: если на Западе под ИА подразумевают и способ запаковки страниц относительно друг друга (то, что зовется еще навигационной структурой), и вот эту объектную штуку, про которую я рассказывал выше, и много чего еще, то у нас под этим чаще всего разумеют только страницы и пункты меню - и ничего больше. Вкладывать много смыслов в термин не страшно, но страшно путать их между собой: если навигационная структура относится к интерфейсам и к внутренней структуре продукта имеет отношение крайне отдаленное, то объектная модель данных относится к самому что ни на есть логическому ядру продукта и может выручить в адских и сложных случаях, которые в наших краях случаются чуть более часто чем всегда - и про которые я вам еще натравлюсь баек на три года вперед.
И еще одна странность: эта тема обычно разжевывается до мелочей разработчикам, а проектировщикам продуктов нет, тогда как она им тоже нужна как воздух. Мы же этот пробел восполним - со временем, конечно.
#продукт #хэштегкоторыйяникогдабольшенебудуиспользоватьнопустьбудет
Что ж, все дело в том, что термин «информационная архитектура» у нас в UX-сфере понимается на дикость однобоко и тупо: если на Западе под ИА подразумевают и способ запаковки страниц относительно друг друга (то, что зовется еще навигационной структурой), и вот эту объектную штуку, про которую я рассказывал выше, и много чего еще, то у нас под этим чаще всего разумеют только страницы и пункты меню - и ничего больше. Вкладывать много смыслов в термин не страшно, но страшно путать их между собой: если навигационная структура относится к интерфейсам и к внутренней структуре продукта имеет отношение крайне отдаленное, то объектная модель данных относится к самому что ни на есть логическому ядру продукта и может выручить в адских и сложных случаях, которые в наших краях случаются чуть более часто чем всегда - и про которые я вам еще натравлюсь баек на три года вперед.
И еще одна странность: эта тема обычно разжевывается до мелочей разработчикам, а проектировщикам продуктов нет, тогда как она им тоже нужна как воздух. Мы же этот пробел восполним - со временем, конечно.
#продукт #хэштегкоторыйяникогдабольшенебудуиспользоватьнопустьбудет
Давайте отметим сегодняшнее утро очередной порцией хуикс-безумия и нашей любимой рубрикой БИСКВИТНЫЙ ДВОР.
Вот такой занятный хуикс-кейс (см. выше) прислал наш дорогой читатель Станислав Голодов - с пылу-с жару, из братской Беларуси, с сайта dominos.by.
Итак, милые дети, что мы видим на картинке? Видим мы следующее:
- Произошла «Ошибка!»
- Регистрация не завершена;
- Ошибка явно какая-то роковая, раз все так ярко расцвечено, а интерфейс затемнен и перекрыт.
Что по факту: эта ошибка выводится в том элементарном случае, если мы пытаемся зарегистрировать пользователя на тот же email, на который он уже зарегистрирован. И данная реализация голимая, потому что попирает сразу несколько важных постулатов:
1. Если произошла какая-то ошибка, на которую повлиял или может повлиять пользователь - он вправе об этом знать: во-первых, чтобы лучше чувствовать логику продукта, а во-вторых - чтобы иметь возможность эту ошибку исправить или не допускать в дальнейшем (типа, «Ага, у меня уже тут есть аккаунт!» или «Ага, это не форма логина, а форма регистрации!»).
В данном же случае у нас бессмысленная импотентская отмазка «Ошибка! Регистрация не завершена» - чо, правда чтоль, хоть ту картинку с Николасом Кейджем вставляй;
2. Если все пошло по какому-то нештатному сценарию, интерфейс должен подсказывать пользователю пути разрешения этой нештатной ситуации. Например, в данном случае можно, помимо прочего, предложить пользователю перейти на страницу логина (или вообще авторизовать его через форму авторизации, если он ввел правильный пароль - но это уже верх интерфейсной эквилибристики).
Тут же интерфейс показывает ровным счетом нихера.
3. Если пользователь вбил в поле что-то не то - это не повод устраивать истерику по Виктюку, орать страшными голосами, показывать дополнительное окно и КРАСНЫЙ КРЕСТ, как сейчас. Реально, будто вся жизнь закончилась.
Самое смешное, что под окошком с ошибкой напротив поля ввода емейла они таки пишут, что такой пользователь уже существует (хвост этой надписи даже на скриншоте видно), но для этого пользователь должен закрыть окно с КРАСНЫМ КРЕСТОМ, пережить недюжинный эмоциональный стресс и жить с посттравматическим синдромом дальше. Что печально, пользователь может это поле вообще не увидеть, закрыв со словами «НУ НАХЕР» весь сайт, потому что ОШИБКА же.
Так что не нагнетайте драму, объясняйте все пользователю доступным языком и показывайте пути решения проблемы - и будет вам счастье.
#бисквитныйдвор
P.S. Хэштеги я начал использовать недавно, так что за предыдущими экспонатами БИСКВИТНОГО ДВОРА (включая сам кейс с бисквитным двором) приглашаю мотать ленту постов самостоятельно - как аудиокассету карандашом в 90-е.
Не забудьте потом обратно только перемотать.
Вот такой занятный хуикс-кейс (см. выше) прислал наш дорогой читатель Станислав Голодов - с пылу-с жару, из братской Беларуси, с сайта dominos.by.
Итак, милые дети, что мы видим на картинке? Видим мы следующее:
- Произошла «Ошибка!»
- Регистрация не завершена;
- Ошибка явно какая-то роковая, раз все так ярко расцвечено, а интерфейс затемнен и перекрыт.
Что по факту: эта ошибка выводится в том элементарном случае, если мы пытаемся зарегистрировать пользователя на тот же email, на который он уже зарегистрирован. И данная реализация голимая, потому что попирает сразу несколько важных постулатов:
1. Если произошла какая-то ошибка, на которую повлиял или может повлиять пользователь - он вправе об этом знать: во-первых, чтобы лучше чувствовать логику продукта, а во-вторых - чтобы иметь возможность эту ошибку исправить или не допускать в дальнейшем (типа, «Ага, у меня уже тут есть аккаунт!» или «Ага, это не форма логина, а форма регистрации!»).
В данном же случае у нас бессмысленная импотентская отмазка «Ошибка! Регистрация не завершена» - чо, правда чтоль, хоть ту картинку с Николасом Кейджем вставляй;
2. Если все пошло по какому-то нештатному сценарию, интерфейс должен подсказывать пользователю пути разрешения этой нештатной ситуации. Например, в данном случае можно, помимо прочего, предложить пользователю перейти на страницу логина (или вообще авторизовать его через форму авторизации, если он ввел правильный пароль - но это уже верх интерфейсной эквилибристики).
Тут же интерфейс показывает ровным счетом нихера.
3. Если пользователь вбил в поле что-то не то - это не повод устраивать истерику по Виктюку, орать страшными голосами, показывать дополнительное окно и КРАСНЫЙ КРЕСТ, как сейчас. Реально, будто вся жизнь закончилась.
Самое смешное, что под окошком с ошибкой напротив поля ввода емейла они таки пишут, что такой пользователь уже существует (хвост этой надписи даже на скриншоте видно), но для этого пользователь должен закрыть окно с КРАСНЫМ КРЕСТОМ, пережить недюжинный эмоциональный стресс и жить с посттравматическим синдромом дальше. Что печально, пользователь может это поле вообще не увидеть, закрыв со словами «НУ НАХЕР» весь сайт, потому что ОШИБКА же.
Так что не нагнетайте драму, объясняйте все пользователю доступным языком и показывайте пути решения проблемы - и будет вам счастье.
#бисквитныйдвор
P.S. Хэштеги я начал использовать недавно, так что за предыдущими экспонатами БИСКВИТНОГО ДВОРА (включая сам кейс с бисквитным двором) приглашаю мотать ленту постов самостоятельно - как аудиокассету карандашом в 90-е.
Не забудьте потом обратно только перемотать.
❤1
Кстати, ещё про драму и ошибки: однажды мой подрядчик довольно изящно поступил с рядовым информером о том, что пользовательские настройки успешно изменены и что от пользователя больше ничего не требуется. Не мудрствуя лукаво, он покрасил этот информер в КРАСНЫЙ ЦВЕТ, а также снабдил его значком !!! и надписью ВНИМАНИЕ впридачу.
Типа, это как сидеть на ялтинском пляже в красных семейных трусах и орать прохожим "ЭЙ МУЖИК ПОДЬ СЮДЫ БЫСТРАААА СЛЫШ У ТЕБЯ ВСЕ В ЖИЗНИ НОРМАЛЬНО НЕТ ЭТО Я НЕ СПРАШИВАЮ ЭТО Я ТЕБЕ ГОВОРЮ А ТЕПЕРЬ КАНАЙ ОТСЮДА ДАЛЬШЕ".
Подрядчик, помнится, очень оскорбился моей просьбе перекрасить этот информер в серый цвет и убрать восклицательные знаки.
Не так заметно же.
#изкрестьянскогобыта
Типа, это как сидеть на ялтинском пляже в красных семейных трусах и орать прохожим "ЭЙ МУЖИК ПОДЬ СЮДЫ БЫСТРАААА СЛЫШ У ТЕБЯ ВСЕ В ЖИЗНИ НОРМАЛЬНО НЕТ ЭТО Я НЕ СПРАШИВАЮ ЭТО Я ТЕБЕ ГОВОРЮ А ТЕПЕРЬ КАНАЙ ОТСЮДА ДАЛЬШЕ".
Подрядчик, помнится, очень оскорбился моей просьбе перекрасить этот информер в серый цвет и убрать восклицательные знаки.
Не так заметно же.
#изкрестьянскогобыта
- Я СДЕЛАЛ КЛЕВЫЙ САЙТ А КОНТЕНТ-МЕНЕДЖЕР ЗАЛИЛ ТУДА НЕ КАРТИНКИ А ЛЮТОЕ ГОВНО ЧТО ДЕЛАТЬ?
На этот вопрос я обычно начинаю отвечать деликатно и издалека: сперва выражаю сочувствие. Потом наливаю чаю с разведенным там бальзамом «Иднакар». Потом спрашиваю, а какое отношение вы имеете к контент-менеджеру.
Вариант А. Вы - подрядчик, а контент-менеджер - представитель заказчика. В 99% случаев вы не можете сделать ничего, с чем я вас и поздравляю. Советую показывать будущим заказчикам изначальные дизайн-макеты, а сам живой сайт показывать издали, на экране дешевого нетбука, проезжая мимо на «Сапсане» на скорости 300 километров в час. Тут вы ничего поделать не можете, смиритесь, это вечная боль подрядчика.
В 1% случаев вы можете писать истерические письма руководству компании и в Страсбургский суд и добиться замены картинок, но я таких чудес не встречал.
Вариант Б. Вы работаете в одной конторе с контент-менеджером. Тут у вас простор для действий чуть пошире. Вы можете сделать одно из следующего:
- Дорасти до менеджера продукта, подмять под себя контент-менеджера и уволить его нахер и с жутким позором (что, сами понимаете, долго и сложно);
- Нажаловаться на контент-менеджера руководству контент-менеджера (впрочем, есть огромный риск, что руководство контент-менеджера скажет в ответ на ваши вопли про ЛЮТОЕ ГОВНО «а мне нравится» - и дело на этом закончится);
- Придумать жуткую систему требований к контенту, чтобы контент-менеджер и выдохнуть без вашего благословления и помощи не мог (осторожно, контент-менеджеры, способные творить ЛЮТОЕ ГОВНО, обычно отличаются дикой изворотливостью и способны творить свое сомнительное дело даже со связанными руками);
- Провозгласить себя UX-царем всей свой корпорации, провести исследования, доказывающие, что иллюстрации не воспринимаются аудиторией, пойти к высокому руководству и взять иллюстрации себе под крыло (этот вариант обычно стухает ровно в тот момент, когда вы пытаетесь выбить деньги хотя бы для проведения исследований);
- Провести дворцовую интригу, тайком подменить ЛЮТОЕ ГОВНО на что-то свое и сделать вид, что оно так и надо было (осторожно, тут включается мир большой политики);
- Смириться, выдохнуть и воспринимать ситуацию как Дукалис - легко, с юморком и бутылкой водки по пятницам (осторожно, вызывает привыкание).
Как видите, единственный рабочий вариант не пустить говно на вечеринку - это стать королем вечеринки, хотя если вы работаете в большой корпорации, то и тут будет замешана политика и вам постоянно будут подсовывать разную лажу под видом «ну, надо же поощрять инициативу наших сотрудников» или «ну, анатолий сергеич старался всю ночь делал» - и вам надо будет умело отбиваться.
Впрочем, работа в большой корпорации всегда сопряжена с политикой, так что привыкайте.
Еще, кстати, возможен вариант, что не контент-менеджер делает ЛЮТОЕ ГОВНО, а вы - но этот вариант я отбрасываю с гневом, потому что ЛЮТОЕ ГОВНО не будет читать мой канал (а если и будет, то это уже не ЛЮТОЕ ГОВНО, но ГОРДОЕ ГОВНО С ПЕРСПЕКТИВОЙ).
Так-то.
#изкрестьянскогобыта
На этот вопрос я обычно начинаю отвечать деликатно и издалека: сперва выражаю сочувствие. Потом наливаю чаю с разведенным там бальзамом «Иднакар». Потом спрашиваю, а какое отношение вы имеете к контент-менеджеру.
Вариант А. Вы - подрядчик, а контент-менеджер - представитель заказчика. В 99% случаев вы не можете сделать ничего, с чем я вас и поздравляю. Советую показывать будущим заказчикам изначальные дизайн-макеты, а сам живой сайт показывать издали, на экране дешевого нетбука, проезжая мимо на «Сапсане» на скорости 300 километров в час. Тут вы ничего поделать не можете, смиритесь, это вечная боль подрядчика.
В 1% случаев вы можете писать истерические письма руководству компании и в Страсбургский суд и добиться замены картинок, но я таких чудес не встречал.
Вариант Б. Вы работаете в одной конторе с контент-менеджером. Тут у вас простор для действий чуть пошире. Вы можете сделать одно из следующего:
- Дорасти до менеджера продукта, подмять под себя контент-менеджера и уволить его нахер и с жутким позором (что, сами понимаете, долго и сложно);
- Нажаловаться на контент-менеджера руководству контент-менеджера (впрочем, есть огромный риск, что руководство контент-менеджера скажет в ответ на ваши вопли про ЛЮТОЕ ГОВНО «а мне нравится» - и дело на этом закончится);
- Придумать жуткую систему требований к контенту, чтобы контент-менеджер и выдохнуть без вашего благословления и помощи не мог (осторожно, контент-менеджеры, способные творить ЛЮТОЕ ГОВНО, обычно отличаются дикой изворотливостью и способны творить свое сомнительное дело даже со связанными руками);
- Провозгласить себя UX-царем всей свой корпорации, провести исследования, доказывающие, что иллюстрации не воспринимаются аудиторией, пойти к высокому руководству и взять иллюстрации себе под крыло (этот вариант обычно стухает ровно в тот момент, когда вы пытаетесь выбить деньги хотя бы для проведения исследований);
- Провести дворцовую интригу, тайком подменить ЛЮТОЕ ГОВНО на что-то свое и сделать вид, что оно так и надо было (осторожно, тут включается мир большой политики);
- Смириться, выдохнуть и воспринимать ситуацию как Дукалис - легко, с юморком и бутылкой водки по пятницам (осторожно, вызывает привыкание).
Как видите, единственный рабочий вариант не пустить говно на вечеринку - это стать королем вечеринки, хотя если вы работаете в большой корпорации, то и тут будет замешана политика и вам постоянно будут подсовывать разную лажу под видом «ну, надо же поощрять инициативу наших сотрудников» или «ну, анатолий сергеич старался всю ночь делал» - и вам надо будет умело отбиваться.
Впрочем, работа в большой корпорации всегда сопряжена с политикой, так что привыкайте.
Еще, кстати, возможен вариант, что не контент-менеджер делает ЛЮТОЕ ГОВНО, а вы - но этот вариант я отбрасываю с гневом, потому что ЛЮТОЕ ГОВНО не будет читать мой канал (а если и будет, то это уже не ЛЮТОЕ ГОВНО, но ГОРДОЕ ГОВНО С ПЕРСПЕКТИВОЙ).
Так-то.
#изкрестьянскогобыта
Я торжественно обещаю, что никогда в этом канале вы не увидите постов вида: «Известнейший UX-гуру, да прославится его имя в летах, Патрик Хуйвэй опубликовал интересную заметку про UX-паттерны изготовления шляпок гвоздей, советуем прочитать, очень интересно: <<ссылка>>»
Дальше ты открываешь этот пост, читаешь полчаса статью про, действительно, UX-паттерны изготовления шляпок гвоздей, закрываешь статью - и живешь дальше как будто ничего не произошло. Ну и смысл, спрашивается, я лучше вместо этого почитаю Википедию про ПУНИЧЕСКИЕ ВОЙНЫ или, там, про КРЕКИНГ НЕФТИ или ГРУМИНГ ПУДЕЛЕЙ.
Кроме того, мне скучно кидаться чистыми ссылками - вы меня читаете не ради них, да и про это есть полно других годных каналов вроде дайджеста Юры Ветрова или «УХ-горна» Миши Хана. Они успешны и глобально любимы женщинами - так что за ссылками и списками идите к ним (Миша, дарова, я знаю, что ты меня читаешь!).
Наконец, есть и третий мотив: при виде огромного количества ссылок я впадаю в паническую депрессию, мне начинает казаться, что вся жизнь проходит мимо меня и что я только к глубокой пенсии дочитаю очередной дайджест за 2013 год, после чего перекрещусь и нырну наконец-то в могилу. Страшное дело.
В общем, херушки. Если я и буду чем-то делиться, то это, во-первых, будет что-то штучно-интересное, а во-вторых - я буду об этом еще и преизрядно разговаривать.
И я это все к чему: открывайте ворота и не закрывайте их в ближайшую пару часов, у нас на подходе телега с первым ссыльным экспонатом!
Дальше ты открываешь этот пост, читаешь полчаса статью про, действительно, UX-паттерны изготовления шляпок гвоздей, закрываешь статью - и живешь дальше как будто ничего не произошло. Ну и смысл, спрашивается, я лучше вместо этого почитаю Википедию про ПУНИЧЕСКИЕ ВОЙНЫ или, там, про КРЕКИНГ НЕФТИ или ГРУМИНГ ПУДЕЛЕЙ.
Кроме того, мне скучно кидаться чистыми ссылками - вы меня читаете не ради них, да и про это есть полно других годных каналов вроде дайджеста Юры Ветрова или «УХ-горна» Миши Хана. Они успешны и глобально любимы женщинами - так что за ссылками и списками идите к ним (Миша, дарова, я знаю, что ты меня читаешь!).
Наконец, есть и третий мотив: при виде огромного количества ссылок я впадаю в паническую депрессию, мне начинает казаться, что вся жизнь проходит мимо меня и что я только к глубокой пенсии дочитаю очередной дайджест за 2013 год, после чего перекрещусь и нырну наконец-то в могилу. Страшное дело.
В общем, херушки. Если я и буду чем-то делиться, то это, во-первых, будет что-то штучно-интересное, а во-вторых - я буду об этом еще и преизрядно разговаривать.
И я это все к чему: открывайте ворота и не закрывайте их в ближайшую пару часов, у нас на подходе телега с первым ссыльным экспонатом!
В общем, вот вам публицистический подгон. Если вы боитесь больших текстов в Хуиксе, то сходите попейте водички, но лучше привыкайте - я периодически буду пересыпать пряные смехуечки жестким гранитом науки.
Есть такая контора - Nielsen Norman Group, которую возглавляют несколько мощных юзабилити-старцев, на которых молятся все UX-специалисты. Надо сказать, небезосновательно молятся, потому что эти UX-старцы из Нильсен-Норман знают свое дело, пишут чрезвычайно годные материалы и вообще молодцы - даже я со своей лютой аллергией на UX-гуру отношусь к ним с большим уважением.
И сейчас я хочу с вами перетереть за важную статью, которую во времена палеолита написал один из этих UX-дедов - Якоб Нильсен: https://www.nngroup.com/articles/customization-of-uis-and-products/ (почитайте ее потом, а если не знаете английский - можете и вообще не читать, потому что я главное все равно перескажу).
Статья посвящена кастомизации. Если кто не знает, это когда вы даете пользователю настраивать что-то самостоятельно - от, скажем, нужных кнопок на главном экране до расцветки интерфейса (интересно, вспомнит ли тут кто скины для WinAmp). Кастомизация бывает интерфейсная и продуктовая, куда относят всякие хрени вроде конфигураторов - например, хотите вы заказать себе бургер, а вам - херакс! - конструктор бургера на весь экран, играйтесь на здоровье.
Не путайте только кастомизацию с персонализацией - когда интерфейс сам подстраивается под профиль конкретного пользователя. Например, знаем мы по хитрому алгоритму, что в наш интернет-магазин лавашей пришла женщина, и мы ей - раз! - и букет во весь экран, вай, хорошо. А если жлоб пришел какой, то ему автоматически наценку в 300% - мол, не зазнавайся, брат.
В какой-то мере кастомизацию можно считать персонализацией для бедных - если у нас не хватает средств и сил, чтобы автоматически подстроить интерфейс под пользователя, пусть сам пользователь настраивает интерфейс под себя, норм идея, да? Заодно и на дизайнере сэкономим!
Нет. Идея не норм.
Если мы предполагаем, что пользователь сам будет настраивать интерфейсы, то мы накладываем лишние ограничения на нашу работу:
- во-первых, сам интерфейс должен быть достаточно квадратно-гнездовым, чтобы пользователь мог в нем самостоятельно втыкать/вытыкать отдельные элементы;
- во-вторых, мы должны предусмотреть отдельный интерфейс для управления интерфейсом (обычно похожий на панель управления космическим кораблем);
- в-третьих, с высокой долей вероятности мы херим все будущие возможности по автоматической персонализации, потому что мы не можем иметь возможность перестраивать то, что пользователь настроил под себя - это вызовет у пользователя гнев и превратит интерфейс в бесконечный тяни-толкай.
Мы должны каким-то образом объяснить пользователю, захера ему надо тратить время и силы на подстройку интерфейса под себя, а не воспользоваться чем-то готовым. Вероятнее всего, пользователь нас пошлет и оставит все как было.
Мякотка в том, что современные пользователи - это не матерые айтишники 90х, которые настраивали под себя все мироздание вокруг и не особо парились; современные пользователи привыкли, что о них заботятся и экономят их время, а не предлагают самим представить себя дизайнером и собрать интерфейс своей мечты.
Есть такая контора - Nielsen Norman Group, которую возглавляют несколько мощных юзабилити-старцев, на которых молятся все UX-специалисты. Надо сказать, небезосновательно молятся, потому что эти UX-старцы из Нильсен-Норман знают свое дело, пишут чрезвычайно годные материалы и вообще молодцы - даже я со своей лютой аллергией на UX-гуру отношусь к ним с большим уважением.
И сейчас я хочу с вами перетереть за важную статью, которую во времена палеолита написал один из этих UX-дедов - Якоб Нильсен: https://www.nngroup.com/articles/customization-of-uis-and-products/ (почитайте ее потом, а если не знаете английский - можете и вообще не читать, потому что я главное все равно перескажу).
Статья посвящена кастомизации. Если кто не знает, это когда вы даете пользователю настраивать что-то самостоятельно - от, скажем, нужных кнопок на главном экране до расцветки интерфейса (интересно, вспомнит ли тут кто скины для WinAmp). Кастомизация бывает интерфейсная и продуктовая, куда относят всякие хрени вроде конфигураторов - например, хотите вы заказать себе бургер, а вам - херакс! - конструктор бургера на весь экран, играйтесь на здоровье.
Не путайте только кастомизацию с персонализацией - когда интерфейс сам подстраивается под профиль конкретного пользователя. Например, знаем мы по хитрому алгоритму, что в наш интернет-магазин лавашей пришла женщина, и мы ей - раз! - и букет во весь экран, вай, хорошо. А если жлоб пришел какой, то ему автоматически наценку в 300% - мол, не зазнавайся, брат.
В какой-то мере кастомизацию можно считать персонализацией для бедных - если у нас не хватает средств и сил, чтобы автоматически подстроить интерфейс под пользователя, пусть сам пользователь настраивает интерфейс под себя, норм идея, да? Заодно и на дизайнере сэкономим!
Нет. Идея не норм.
Если мы предполагаем, что пользователь сам будет настраивать интерфейсы, то мы накладываем лишние ограничения на нашу работу:
- во-первых, сам интерфейс должен быть достаточно квадратно-гнездовым, чтобы пользователь мог в нем самостоятельно втыкать/вытыкать отдельные элементы;
- во-вторых, мы должны предусмотреть отдельный интерфейс для управления интерфейсом (обычно похожий на панель управления космическим кораблем);
- в-третьих, с высокой долей вероятности мы херим все будущие возможности по автоматической персонализации, потому что мы не можем иметь возможность перестраивать то, что пользователь настроил под себя - это вызовет у пользователя гнев и превратит интерфейс в бесконечный тяни-толкай.
Мы должны каким-то образом объяснить пользователю, захера ему надо тратить время и силы на подстройку интерфейса под себя, а не воспользоваться чем-то готовым. Вероятнее всего, пользователь нас пошлет и оставит все как было.
Мякотка в том, что современные пользователи - это не матерые айтишники 90х, которые настраивали под себя все мироздание вокруг и не особо парились; современные пользователи привыкли, что о них заботятся и экономят их время, а не предлагают самим представить себя дизайнером и собрать интерфейс своей мечты.
И тут мы возвращаемся к статье UX-дедов, ссылку на которую я кидал выше. В ней приводятся цифры серьезного исследования, из которых следует, что пользователи не слишком любят кастомизируемые интерфейсы, теряются в них и теряют важное чувство контроля над продуктом.
Как упоенно пишут деды из Нильсен-Норман (а я им киваю), пользователи не видят в самой кастомизации никакого смысла, процесс настройки их отпугивает своей сложностью, неочевидностью и нажористостью, и они чувствуют себя чужими на этом продуктовом празднике жизни. То есть - добавлю от себя - пользователи не чувствуют заботы о себе и о своем потраченном времени, получая взамен интерфейс-импотент.
И деды научно выводят следующее:
1. Кастомизируемые интерфейсы - это муторное, сложное дело (как технологически, так и визуально), которое требует особого подхода, внимательной и долгой подстройки и длительного тестирования - и чаще всего не имеет никакого смысла.
2. Гораздо проще (и человечнее) обойтись без кастомизации, а вместо этого пустить ресурсы на постройку одного общего, но хорошо работающего интерфейса, учитывающего всю специфику.
3. Если уж приспичило поиграться в кастомизацию, у которой все же есть свои применения в очень редких случаях, то старайтесь сделать ее легкой, приятной, понятной и настраиваемой по щелчку пальцев. Иначе все будет зря.
Деды, в общем, молодцы. Статья их - древняя, ей уже почти 10 лет; в те времена пользователи еще были окружены разными кастомизируемыми продуктами и были к ним привычны. Сейчас же кастомизируемых интерфейсов и продуктов осталось совсем немного, и у пользователей уже пропала привычка настраивать все под себя. Я уверен, проведи деды из Нильсен-Норман свое исследование сейчас - цифры бы были еще более угрожающими.
Так что ну ее, кастомизацию эту, в жопу, - как бы намекает нам Якоб Нильсен, а я этому рукоплещу. Давайте лучше о людях заботиться и их время экономить.
#дедыписали
Как упоенно пишут деды из Нильсен-Норман (а я им киваю), пользователи не видят в самой кастомизации никакого смысла, процесс настройки их отпугивает своей сложностью, неочевидностью и нажористостью, и они чувствуют себя чужими на этом продуктовом празднике жизни. То есть - добавлю от себя - пользователи не чувствуют заботы о себе и о своем потраченном времени, получая взамен интерфейс-импотент.
И деды научно выводят следующее:
1. Кастомизируемые интерфейсы - это муторное, сложное дело (как технологически, так и визуально), которое требует особого подхода, внимательной и долгой подстройки и длительного тестирования - и чаще всего не имеет никакого смысла.
2. Гораздо проще (и человечнее) обойтись без кастомизации, а вместо этого пустить ресурсы на постройку одного общего, но хорошо работающего интерфейса, учитывающего всю специфику.
3. Если уж приспичило поиграться в кастомизацию, у которой все же есть свои применения в очень редких случаях, то старайтесь сделать ее легкой, приятной, понятной и настраиваемой по щелчку пальцев. Иначе все будет зря.
Деды, в общем, молодцы. Статья их - древняя, ей уже почти 10 лет; в те времена пользователи еще были окружены разными кастомизируемыми продуктами и были к ним привычны. Сейчас же кастомизируемых интерфейсов и продуктов осталось совсем немного, и у пользователей уже пропала привычка настраивать все под себя. Я уверен, проведи деды из Нильсен-Норман свое исследование сейчас - цифры бы были еще более угрожающими.
Так что ну ее, кастомизацию эту, в жопу, - как бы намекает нам Якоб Нильсен, а я этому рукоплещу. Давайте лучше о людях заботиться и их время экономить.
#дедыписали
Выходные выдались дождливые, так что вы, наверное переживаете: ни в салат лицом упасть на даче, ни под гитару «ЛЮБЛЮ ТЕБЯ ПЕТРА ТВОРЕНЬЕ» в небо поорать, ни чего еще интересного. И тут появляюсь я в ореоле хуикс-славы и спасаю ваш выходной ЦЕННЫМ ЗНАНИЕМ.
На самом деле, сегодня хочу поговорить про очень простую и злую штуку - хреновое отрабатывание проверки корректности ввода. Пример:
1. Вот, допустим, заходите вы, как на картинке выше, на главный экран какого-нибудь сервиса и хотите залогиниться. Тыкаете на клавиатуре в первую буковку логина - допустим, БЭ, - а сервис как начнет орать «ТЫ ЧЕГО СУПОСТАТ СРАНЫЙ ВВОДИШЬ НЕВЕРНЫЙ ЛОГИН?».
2. Вы смущаетесь и говорите сервису такой - мол, подожжи-подожжи, я еще не все - после чего нажимаете на вторую буковку логина - допустим, У, - а сервис в ответ продолжает орать «ТЫ ЧЕГО РУССКОГО ЯЗЫКА НЕ ПОНЯЛ СВОИ ИГРЫ ПРОДОЛЖАЕШЬ ХАКЕР А НУ ПШЕЛ ОТСЮДА».
3. Вы такой говорите ему - ненене, это ж я, борька самойлов, просто я еще не закончил, погодь - вводите третью букву ГЭ, сервис орёт, вы смущаетесь, и вся эта карусель злобы продолжается ровно до того момента, пока вы не введете в логин что-то минимально допустимое, чтобы проверка наконец-то успокоилась.
И это, доложу я вам, сценарий хреновый - подобно бабке в окошке регистратуры, вы лаете на пользователя все то время, пока он вводит правильную, по сути, информацию. Как с этим можно разобраться?
1. Лаять на неправильный ввод не тогда, когда пользователь нажал не на ту кнопку, а тогда, когда пользователь явно сместил свое внимание с этого поля - например, когда фокус (т.е. курсор) перешел в другое поле или с момента предыдущего нажатия прошло много времени.
2. Дать себе важное правило - лаять на пользователя только тогда, когда он ввел 100% какую-то ересь (например, поставил вторую собаку в поле ввода емейла).
Да, такая проверка потребует настройки гораздо большего количества сценариев, чем если пойти в лоб, и в ряде случаев заставит изрядно поломать голову, но зато вы не будете напрягать пользователя идиотским воем и предупреждениями, когда все и так идет нормально.
И эта боль очень часто встречается даже у уважаемых порталов и сервисов - скриншот у меня взят не с сайта ГАЛЯ.РУ (тьфу три раза), а со вполне рукопожатного музыкального сервиса Deezer, чей интерфейс и UX очень даже норм. Будьте внимательны.
#мелочьнепосмотрите
На самом деле, сегодня хочу поговорить про очень простую и злую штуку - хреновое отрабатывание проверки корректности ввода. Пример:
1. Вот, допустим, заходите вы, как на картинке выше, на главный экран какого-нибудь сервиса и хотите залогиниться. Тыкаете на клавиатуре в первую буковку логина - допустим, БЭ, - а сервис как начнет орать «ТЫ ЧЕГО СУПОСТАТ СРАНЫЙ ВВОДИШЬ НЕВЕРНЫЙ ЛОГИН?».
2. Вы смущаетесь и говорите сервису такой - мол, подожжи-подожжи, я еще не все - после чего нажимаете на вторую буковку логина - допустим, У, - а сервис в ответ продолжает орать «ТЫ ЧЕГО РУССКОГО ЯЗЫКА НЕ ПОНЯЛ СВОИ ИГРЫ ПРОДОЛЖАЕШЬ ХАКЕР А НУ ПШЕЛ ОТСЮДА».
3. Вы такой говорите ему - ненене, это ж я, борька самойлов, просто я еще не закончил, погодь - вводите третью букву ГЭ, сервис орёт, вы смущаетесь, и вся эта карусель злобы продолжается ровно до того момента, пока вы не введете в логин что-то минимально допустимое, чтобы проверка наконец-то успокоилась.
И это, доложу я вам, сценарий хреновый - подобно бабке в окошке регистратуры, вы лаете на пользователя все то время, пока он вводит правильную, по сути, информацию. Как с этим можно разобраться?
1. Лаять на неправильный ввод не тогда, когда пользователь нажал не на ту кнопку, а тогда, когда пользователь явно сместил свое внимание с этого поля - например, когда фокус (т.е. курсор) перешел в другое поле или с момента предыдущего нажатия прошло много времени.
2. Дать себе важное правило - лаять на пользователя только тогда, когда он ввел 100% какую-то ересь (например, поставил вторую собаку в поле ввода емейла).
Да, такая проверка потребует настройки гораздо большего количества сценариев, чем если пойти в лоб, и в ряде случаев заставит изрядно поломать голову, но зато вы не будете напрягать пользователя идиотским воем и предупреждениями, когда все и так идет нормально.
И эта боль очень часто встречается даже у уважаемых порталов и сервисов - скриншот у меня взят не с сайта ГАЛЯ.РУ (тьфу три раза), а со вполне рукопожатного музыкального сервиса Deezer, чей интерфейс и UX очень даже норм. Будьте внимательны.
#мелочьнепосмотрите
СМОТРИТЕ ЛЁХА В ТЕЛЕВИЗОРЕ: сегодня в 15:55 я буду выступать на Globus Partners Day (с бесплатной прямой трансляцией!) и расскажу про продуктовый дизайн, почему агентства делают говно и всякое-такое-прочее. Трансляция тут: https://www.facebook.com/tagline.digital/videos/792360464468583 (ищите меня на 34 минуте)
Доклад для широкой аудитории, так что не ждите УЗКОПРОФИЛЬНОЙ ГЛУБИНЫ, там, БРЫЗГОВ UX-ГУРУИЗМА или чего-то подобного, но общее представление о вопросе оно точно создаст.
Приходите и слушайте, а я буду чувствовать вашу моральную поддержку и раскрываться так, как никакой Алле Борисовне на концертах не снилось.
P.S. Вообще состав спикеров на Globus Partners Day весьма годный и там есть кого послушать (https://globus-event-org.timepad.ru/event/899454/), но поскольку мне за это никто не платит, я превращусь в эгоистичную жопу и про это вам не скажу - типа, смотрите, какой я классный, а больше никого и нету.
#концертыстасамихайлова
Доклад для широкой аудитории, так что не ждите УЗКОПРОФИЛЬНОЙ ГЛУБИНЫ, там, БРЫЗГОВ UX-ГУРУИЗМА или чего-то подобного, но общее представление о вопросе оно точно создаст.
Приходите и слушайте, а я буду чувствовать вашу моральную поддержку и раскрываться так, как никакой Алле Борисовне на концертах не снилось.
P.S. Вообще состав спикеров на Globus Partners Day весьма годный и там есть кого послушать (https://globus-event-org.timepad.ru/event/899454/), но поскольку мне за это никто не платит, я превращусь в эгоистичную жопу и про это вам не скажу - типа, смотрите, какой я классный, а больше никого и нету.
#концертыстасамихайлова
Facebook
Log in or sign up to view
See posts, photos and more on Facebook.
Хочу вам рассказать по-быстрому про штуку, которую многие или не знают, или постоянно забывают. Штука называется HADI, а значит она следующее: Хрен - Американцам, Дизайн - Индейцам.
Не, шучу, расшифровывается HADI как Hypothesis - Action - Data - Interpretation (гипотеза - действие - данные - интерпретацыя), а применяется так:
1. Вы делаете себе татуировку на пальцы левой руки с соответствующими буковками: на мизинец, значится, H, на безымянный A, на средний D, ну и так далее. Теперь вы как продуктовый авторитет, выходит.
2. Перед тем, как сесть за какую-нибудь продуктовую или интерфейсную штуку, смотрите на мизинец левого кулака и думаете «АГА ГИПОТЕЗА». И понимаете: прежде чем начать что-то делать, вам нужно сформулировать гипотезу, нафига вы это делаете. Пишете, там, «Мы верим на основании своего UX-гуруизма, что в дождливую погоду пользователи готовы покупать круассаны по ценам в 100 раз выше, и проверим это, показав фичу продажи круассанов в дождь тыще пользователей в ходе A/B тестирования. Мы будем правы, если треть пользователей экспериментальной группы купит круассанов больше, чем в контрольной группе». Пока хватит (запомните, кстати, такую манеру постановки гипотез - пригодится)
3. Смотрите снова на левый кулак и думаете «АГА ДЕЙСТВИЕ». И понимаете: вам нужно понять, как именно вы будете проверять гипотезу и проворачивать эксперимент с круассанной фичей, а также как и куда собирать данные. Продумываете план действий, его реализуете, запускаете эксперимент.
4. Глядите на вашего нового верного друга - левый кулак - и думаете «АГА ТЕПЕРЬ ДАННЫЕ». Это значит, что теперь вы должны собрать результаты проверки гипотезы воедино. Если не налажали на шаге 3 и все спланировали верно, это уже чисто технический шаг, требующий лишь времени.
5. Вызываете свой левый кулак еще раз. Читаете, глядя на него, с выражением: «АГА ИНТЕРПРЕТАЦИЯ». Теперь вы должны сделать самое сложное - выудить из полученных данных здравый смысл и примерить его на гипотезу. Для этого вы должны не налажать на предыдущих шагах и сделать правильные выводы, не выдавая желаемое за действительное.
6. Теперь вы понимаете, что ваша круассанная гипотеза провалилась или выжила. Причем вы должны быть рады обоим результатам - гипотезы любят не безошибочных, гипотезы любят быстрых и смелых. Выдыхаете. Кулак далеко только не убирайте - у вас должно появиться много новых классных гипотез, с которыми нужно будет работать. Видите, как хорошо быть продуктовым авторитетом?
И вот в идеале вы так и должны, как в стиральной машине, жить циклами гипотез - поставили гипотезу (самый нудный, но важный этап), проверили ее в действии (это самый нажористый этап в плане телодвижений), собрали данные, проинтерпретировали их (это самый хрупкий мозголомный этап), и дальше на новый круг.
При этом, что занятно, у вас одномоментно может крутиться куча разных гипотез с совершенно разным циклом проверки (что-то проверяется быстро, что-то вы сможете проверить на пользователях очень нескоро), но вы должны понимать следующее: то, что родила ваша голова, в любом случае нуждается в проверке реальной жизнью, и чем раньше, тем лучше.
#продукт
Не, шучу, расшифровывается HADI как Hypothesis - Action - Data - Interpretation (гипотеза - действие - данные - интерпретацыя), а применяется так:
1. Вы делаете себе татуировку на пальцы левой руки с соответствующими буковками: на мизинец, значится, H, на безымянный A, на средний D, ну и так далее. Теперь вы как продуктовый авторитет, выходит.
2. Перед тем, как сесть за какую-нибудь продуктовую или интерфейсную штуку, смотрите на мизинец левого кулака и думаете «АГА ГИПОТЕЗА». И понимаете: прежде чем начать что-то делать, вам нужно сформулировать гипотезу, нафига вы это делаете. Пишете, там, «Мы верим на основании своего UX-гуруизма, что в дождливую погоду пользователи готовы покупать круассаны по ценам в 100 раз выше, и проверим это, показав фичу продажи круассанов в дождь тыще пользователей в ходе A/B тестирования. Мы будем правы, если треть пользователей экспериментальной группы купит круассанов больше, чем в контрольной группе». Пока хватит (запомните, кстати, такую манеру постановки гипотез - пригодится)
3. Смотрите снова на левый кулак и думаете «АГА ДЕЙСТВИЕ». И понимаете: вам нужно понять, как именно вы будете проверять гипотезу и проворачивать эксперимент с круассанной фичей, а также как и куда собирать данные. Продумываете план действий, его реализуете, запускаете эксперимент.
4. Глядите на вашего нового верного друга - левый кулак - и думаете «АГА ТЕПЕРЬ ДАННЫЕ». Это значит, что теперь вы должны собрать результаты проверки гипотезы воедино. Если не налажали на шаге 3 и все спланировали верно, это уже чисто технический шаг, требующий лишь времени.
5. Вызываете свой левый кулак еще раз. Читаете, глядя на него, с выражением: «АГА ИНТЕРПРЕТАЦИЯ». Теперь вы должны сделать самое сложное - выудить из полученных данных здравый смысл и примерить его на гипотезу. Для этого вы должны не налажать на предыдущих шагах и сделать правильные выводы, не выдавая желаемое за действительное.
6. Теперь вы понимаете, что ваша круассанная гипотеза провалилась или выжила. Причем вы должны быть рады обоим результатам - гипотезы любят не безошибочных, гипотезы любят быстрых и смелых. Выдыхаете. Кулак далеко только не убирайте - у вас должно появиться много новых классных гипотез, с которыми нужно будет работать. Видите, как хорошо быть продуктовым авторитетом?
И вот в идеале вы так и должны, как в стиральной машине, жить циклами гипотез - поставили гипотезу (самый нудный, но важный этап), проверили ее в действии (это самый нажористый этап в плане телодвижений), собрали данные, проинтерпретировали их (это самый хрупкий мозголомный этап), и дальше на новый круг.
При этом, что занятно, у вас одномоментно может крутиться куча разных гипотез с совершенно разным циклом проверки (что-то проверяется быстро, что-то вы сможете проверить на пользователях очень нескоро), но вы должны понимать следующее: то, что родила ваша голова, в любом случае нуждается в проверке реальной жизнью, и чем раньше, тем лучше.
#продукт
🔥4
После конференций ко мне часто подваливают люди перетереть за продукты, процессы и все такое. Я очень люблю подобные моменты, потому что именно тогда люди спрашивают действительно интересные вещи. «ЛЁХ НО ЕСТЬ ЖЕ ВОПРОСЫ ИЗ ЗАЛА ПОСЛЕ ДОКЛАДА» - спросите вы. Да, есть, но, к сожалению, самые важные вопросы люди из зала не спрашивают - потому что эти вопросы, как им кажется, выглядят глупо (о, этот страх выглядеть глупо!). Поэтому я люблю общаться лично - именно тогда я понимаю, что действительно волнует и затрагивает людей.
И вот на одной из последних конференций ко мне подвалил чувак с очень простым вопросом: «А КАК ВЫ ВООБЩЕ ИССЛЕДУЕТЕ ПОЛЬЗОВАТЕЛЕЙ». Как выяснилось дальше, под этим вопросом (боясь выглядеть глупо) он скрывал следующее: «Мы понимаем, что пользовательские исследования нужны и важны, слышим про уикс-хуикс из каждой колонки, но, блин, с чего начать-то?»
Этот вопрос меня самого мучал очень долгое время. Мы все читаем от какого-нибудь там Юзабилитилаба про пользовательские исследования, про эти адские методологические процессы, занимающие месяцы, про репрезентативность выборки, количественные и качественные исследования, про ай-трекинг, юзабилити-лаборатории и прочий матстат, и потому процесс UX-исследований порой кажется каким-то таинственным ритуальным процессом, в котором простой смертный без корочки психфака (или хотя бы мехмата) не разберется НИКОГДА ВОВЕКИ ВЕКОВ ЗАКЛИНАЮ ВАС ИМЕНЕМ UX ГУРУ.
А на самом-то деле все очень просто, и сейчас я вам расскажу, какую систему с исследованиями я выстроил у нас в банке.
И вот на одной из последних конференций ко мне подвалил чувак с очень простым вопросом: «А КАК ВЫ ВООБЩЕ ИССЛЕДУЕТЕ ПОЛЬЗОВАТЕЛЕЙ». Как выяснилось дальше, под этим вопросом (боясь выглядеть глупо) он скрывал следующее: «Мы понимаем, что пользовательские исследования нужны и важны, слышим про уикс-хуикс из каждой колонки, но, блин, с чего начать-то?»
Этот вопрос меня самого мучал очень долгое время. Мы все читаем от какого-нибудь там Юзабилитилаба про пользовательские исследования, про эти адские методологические процессы, занимающие месяцы, про репрезентативность выборки, количественные и качественные исследования, про ай-трекинг, юзабилити-лаборатории и прочий матстат, и потому процесс UX-исследований порой кажется каким-то таинственным ритуальным процессом, в котором простой смертный без корочки психфака (или хотя бы мехмата) не разберется НИКОГДА ВОВЕКИ ВЕКОВ ЗАКЛИНАЮ ВАС ИМЕНЕМ UX ГУРУ.
А на самом-то деле все очень просто, и сейчас я вам расскажу, какую систему с исследованиями я выстроил у нас в банке.