Наши любимые UX-деды из Норман-Нильсен недавно разродились многословной и желчной статьей про попапы - то есть всплывающие окошки.

Вот о чем пишет этот вестник ЗОЖ от мира UX:

1. Показывать попап сразу после загрузки или авторизации - ХРЕНОВО. Пользователь приходит и логинится явно не просто так, а с конкретной своей целью, а тут вы перед ним попапами машете и его отвлекаете.

Что делать: во-первых, придерживайтесь принципа взаимности (как его заумно называют деды - Reciprocity Principle): прежде чем совать что-то пользователям, дайте ему что-то полезное (или хотя бы поманите издали). Во-вторых, подумайте еще раз: скорее всего, ваша задача решается не только попапами.

Это касается окошек всех видов - и предупреждений, и рекламных объявлений, и запросов емейлов. Ловите тот момент, когда пользователь действительно позитивно к вам настроен и готов с вами жить дальше.

«КОКОКО, - взовьется иной маркетологический гость моего блога, - НО ВЕДЬ ТАКИЕ ОКОШКИ ДАЮТ ПОТРЯСАЮЩУЮ КОНВЕРСИЮ В ПОДПИСКИ». Это иногда правда так, соглашусь я (и UX-деды) - если судить в моменте. Но сколько пользователей вы взбесите таким манером на дальней перспективе? Много. Вот и думайте про долгие метрики тоже. Исключениями могут служить лишь самые экстренные случаи, когда вам непременно надо поломать пользовательский сценарий.

2. Спрашивать «ВАМ ПОНРАВИЛСЯ НАШ САЙТ?» до того, как пользователь составил представление о продукте - ХРЕНОВО. Спрашивать фидбэк у пользователя (вот эти все звездочки-оцените-нас, окошки для ввода отзывов и тому подобное) действительно можно и нужно. Главное - отлавливать правильный момент: чаще всего это окошко вылезает в самый неудобный момент, и сразу начинает люто бесить.

Что делать: привязать это окошко к финалу пользовательского сценария. Пришел ваш пользователь заказывать мешок картошки - так и спросите у него фидбэк, когда он эту картошку купит. И ни в коем случае не вставляйте эти окошки с запросом фидбэка посреди сложных задач, требующих сосредоточенности (типа заказа авиабилетов) - для таких UX-гуру припасен отдельный уголок в UX-аду.

3. Показывать один попап поверх другого - ХРЕНОВО. Тут я даже комментировать не буду: когда я натыкаюсь на подобные ПОПАПЫ ПОВЕРХ ПОПАПОВ ПОВЕРХ ПОПАПОВ, я вспоминаю то ли порносайты начала 00х, то ли зомби-апокалипсис, то ли и то и другое одновременно. Это просто плохо, некрасиво, муторно. Подвидом этого срама является целый паровоз из попапов, который тебе приходится сто лет закрывать.

Что делать: так не делать. Обходитесь одним сборным попапом, если совсем припекло - слайдером. А еще лучше - подумайте, как обойтись без попапов и общаться с пользователями без костылей.

4. Подсовывать в попапе на сайте предложение скачать мобильное приложение - ХРЕНОВО. Не, задумка владельцев сайтов понятна - к нам пришел мобильный пользователь, давайте-ка его перенаправим в мобилу, - но делается это чаще всего через жопу. Клиент, который зашел почитать какую-нибудь жалкую статью, бомбардируется ОКНОМ ВО ВЕСЬ ЭКРАН ПРО НАШЕ ВОЛШЕБНОЕ ПРИЛОЖЕНИЕ, скачивает его миллион лет по своему жалкому мобильному интернету - и в итоге понимает, что после открытия приложухи попал хрен знает куда и своей статьи не видит в упор. Финита, блин.

Что делать: рассказывать о приложении, не вклиниваясь между пользователями и продуктом. Обойдитесь ненавязчивыми плашками внизу экрана, контекстными подсказками - и, опять-таки, ищите для этого правильный момент, когда пользователь уже нашел и сделал, что ему нужно.

5. Делать ставку на то, что пользователи читают содержимое попапов - ХРЕНОВО. Они их просто не читают.

Что делать: не делать ставку на модальные окна. Попапы надо использовать только в действительно экстренных случаях и в тщательно спланированных местах, иначе будет плохо, сам старина Нильсен придет к вам с линейкой и надает по щам. А удар у него хлесткий.

#дедыписали

P.S. Вот злая статейка, с которой все началось: https://www.nngroup.com/articles/popups/ (тут еще и картинки есть повтыкать)

Не удержался и утащил к себе бонус - хитрую диаграммку, которая показывает разницу между модальными и немодальными окнами, а также между лайтбоксами и нелайтбоксами. Если коротко:

Лайтбокс - задник приглушен, фокус внимания тем самым смещен на само окно. Нелайтбокс - задник не приглушен, пользователь не так хорошо сфокусирован.

Если у нас модальное окно, то пользователь не может нажимать ничего на его фоне, если немодальное - позволяет взаимодействовать с фоновым контентом.

Чаще всего лайтбоксы бывают модальными, но это не точно.

#дедыписали

Вы же понимаете, что вы не просто подписаны на канал Хуикс - но включены в ФЕДЕРАЛЬНУЮ ПРОГРАММУ UX ТРЕША УГАРА СОДОМИИ И РАСШАТЫВАНИЯ ОКНА ОВЕРТОНА? Хорошо.

Так вот, тема со всплывающими окнами получила неожиданное продолжение - да такое, что я зацокал языком и воскликнул O LA LA (спасибо моей дражайшей супруге Вере Павловне за подгон, традиционный земной ей поклон, счастья, здоровья и мужа богатого).

Прежде чем мы продолжим и вы откроете ту ссылку, которую я вам дам, прочтите Важное Объявление:

1. Если вам нет 18 лет, то ОФИЦИАЛЬНО НЕ СОВЕТУЮ ХОДИТЬ ПО ССЫЛКЕ (хотя кого это когда останавливало)

2. Если вы на работе, сидите в присутственном месте и, допустим, окружены детьми малыми - ОФИЦИАЛЬНО НЕ СОВЕТУЮ ХОДИТЬ ПО ССЫЛКЕ (хотя кого это когда… ну, вы поняли)

3. Если вы трепетная, ранимая личность (что вы тут вообще позабыли в этом горниле чужих грехов?) - то ТОЖЕ НЕ СОВЕТУЮ. Вместо этого посмотрите на потешное видео с белочками: https://youtu.be/IDaqFiLvcB0

И запомните: я предупреждал.

Оставшихся же я приглашаю отрастить усы, раскрутить диско-шар и нырнуть в, гм, стихотворный труд французской дизайн-студии Twistudio: https://www.twistudio.fr/lespassantes/ (сайт открывается только с десктопа - и это важно)

Когда вернетесь обратно и тяжело выдохнете O LA LA, все же посмотрите на потешное видео с белочками: https://youtu.be/IDaqFiLvcB0. Обещаю, после всех этих процедур будете как огурчик.

И будете по-другому смотреть на всплывающие окна.

#царьхуикс #18плюсминус

У нас очередная хуикс-угадайка. Еще когда я вращался на агентской стороне, я ОЧЕНЬ часто натыкался на следующий дурацкий кейс:

1. К разработчику приходит заказчик и ставит задачу: хочу, мол, сайт. Или мобильное приложение. Или еще что цифровое.

2. Разработчик не на помойке себя нашел, а потому начинает ДИЗАЙН СУКА ПРОЦЕСС: изучает имеющиеся материалы, формирует сценарии (в формате JTBD, CJM - да хоть МЖМ).

3. Далее на основе сценариев разработчик делает прототипы интерфейсов - те самые уродливые черно-белые картинки, при виде которых следует кокетливо повизгивать «ДАННЫЙ ФОРМАТ ПРОТОТИПОВ ОТОБРАЖАЕТ ЛОГИКУ НО НЕ ЭМОЦИИ И ЭСТЕТИКУ ТАК ЧТО ОТСТАНЬТЕ СО СВОИМИ ШРИФТАМИ»).

4. Само собой, все артефакты ДИЗАЙН СУКА ПРОЦЕССА показываются менеджеру со стороны заказчика - кутылому молодому человеку, который лениво копается в прототипах и периодически ноет про то, что к Единовластному Большому Начальству (далее - ЕБН) мы понесем уже готовые макеты - дураку половину работы не показывают.

5. Поскольку день показа наработок ЕБН близится с угрожающей скоростью, уродливые прототипы отгружаются по мере готовности господину Дизайнеру, который начинает натягивать на каркас логического задротства полотнище креативности. Получается вроде ничего.

6. Настает встреча с ЕБН. На нее едут все участники от разработчиков, но первую скрипку играет господин Дизайнер - он же руками все рисовал, вот и показывает макеты самостоятельно.

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

8. ЕБН кивает, процеживает «Вроде ничего» и дает добро на запуск в работу.

9. Макеты запускаются в работу, выкатываются разработчиком.

10. Когда в проект запускаются пользователи, выясняется, что интерфейс - говно.

Немая сцена.

(ВОТ И СКАЗОЧКЕ КОНЕЦ А КТО СЛУШАЛ ТОТ ДМИТРИЙ САТИН ВРЕМЕН ОСНОВАНИЯ ЮЗАБИЛИТИЛАБ)

Угадайте, на каком шаге ВСЕ ПОШЛО НЕ ТАК?
anonymous poll

4 – 80
👍👍👍👍👍👍👍 30%

1 (да вы оптимист) – 69
👍👍👍👍👍👍 26%

2 – 69
👍👍👍👍👍👍 26%

3 – 23
👍👍 9%

5 – 8
👍 3%

6 – 6
👍 2%

8 – 4
▫️ 1%

9 – 4
▫️ 1%

10 – 3
▫️ 1%

7 – 2
▫️ 1%

👥 268 people voted so far.

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

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

1. К разработчику приходит заказчик и ставит задачу: хочу, мол, сайт (24%). Действительно, уже на этом этапе все может полететь в тартарары: в идеале, заказчик должен не ставить задачу «ХОЧУ КРАСНЫЙ САЙТ СО СЛАЙДЕРОМ», но выдвигать определенную бизнес-проблему, которую ему нужно решить. Иное дело, что это в идеале: в жизни полно кривых разработчиков, которые понимают только задачи «ХОЧУ САЙТ СО СЛАЙДЕРОМ» (и даже спрашивают об этом в брифе!), а также жопных заказчиков, которые решают, что они знают все лучше всех на свете. В итоге вторые заказывают то, что им не нужно, а первые не делают то, что от них ожидается. Вин, сука, вин.

2. Разработчик не на помойке себя нашел, а потому начинает ДИЗАЙН СУКА ПРОЦЕСС (24%). На первый взгляд, удивительно: смотришь на эти 24% и думаешь - ну чо такого, как же без дизайн-процесса вообще стартовать разработку? Ответ тут простой - нередко ДИЗАЙН СУКА ПРОЦЕСС затевается ради ДИЗАЙН СУКА ПРОЦЕССА: перед заказчиком раскатывается ДИЗАЙН-МЫШЛЕНИЕ, его мурыжат на КАСТДЕВ-ВОРКШОПАХ, ему затирают про ДЖОБС ТУБИДАН и ПЕРСОНАЖЕЙ, вовлекают в БРЕЙНШТОРМЫ и кормят АЙС БРЕЙКЕРАМИ, а на выходе выдают кусок унылого дермантина, который даже врагу подкинуть совестно (а разработать - и вообще невозможно). В итоге все наедаются говна, а признаться в этом стыдно, и потому все важно делают вид, что все прошло офигенчик. Посему заслушайте мораль: без ДИЗАЙН СУКА ПРОЦЕССА вы никуда не уедете, но он должен не просто быть, но работать, быть управляемым и понятным для всех, а его результаты - безусловно внедряться. Не верьте словам, верьте делу.

3. Далее на основе сценариев разработчик делает прототипы интерфейсов - те самые уродливые черно-белые картинки (9%). Тут тоже интересно. Прототипы - штука крайне полезная (поскольку сильно экономит время дизайнера и команды), но изредка и она оказывается опасной. Самые страшные мои истории были связаны или с тем, что мы увлеклись и сделали слишком сложные интерактивные прототипы, которые было безумно сложно поддерживать и изменять - или с тем, что мы увлеклись и сделали слишком красивые прототипы, которые потеряли черно-белую условность, но не стали красивыми макетами, застряв в безжалостном уродстве посередине. Поэтому совет - не увлекайтесь. Прототип на то и прототип, чтобы быть быстро сделанным, а потом выброшенным на обочину истории во имя финального продукта.

4. Все артефакты ДИЗАЙН СУКА ПРОЦЕССА показываются менеджеру со стороны заказчика - кутылому молодому человеку (32%). Это безусловный фаворит в нашем голосовании, и вы еще как правы. Если вам достался дурной менеджер со стороны заказчика, то я могу вас поздравить - вы попали на съемки документального кинофильма «Стелите гроб, я спать пришел».

Все дело в том, что ценность работы любого агентства (от студии Лебедева до кучки студентов под каким-нибудь дурацким названием типа ПРО ВЕБ ДЕВЕЛОПМЕНТ) напрямую зависит от менеджера на стороне заказчика. Достался вам хороший менеджер, который заинтересован в продукте - все будет хорошо: он даст развернуться вашему профессионализму во всю ширь, укажет вам на ваши косяки, поможет в случае неурядиц, наладит коммуникацию и будет верным адвокатом продукта (и отчасти вас).

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

И на этом пункте мы сделаем, пожалуй, перерыв. Сходите выпейте коньяку, посмотрите на склоны Кавказа, поиграйте с кошкой (или что там у вас заместо кошки и Кавказа); у нас все только начинается - следующий пункт будет весьма убойным, ведь мы будем говорить про ОТРИСОВКУ ДИЗАЙНА.

#хуиксугадайка #изкрестьянскогобыта

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

5. Поскольку день показа наработок ЕБН (Единовластное большое начальство - прим.ред.) близится с угрожающей скоростью, уродливые прототипы отгружаются по мере готовности господину Дизайнеру (4%). За этот вариант проголосовало мало человек, хотя здесь сокрыта парочка бомб замедленного действия.

Во-первых, прототипы надо отгружать не по мере готовности, а посценарно, чтобы господин Дизайнер мог нарисовать не изолированные экраны, но внятную пользовательскую историю от начала и до конца. Без этого невозможно ни нарисовать качественные интерфейсы, ни тем более хоть как-то оценить их - ну, красиво и красиво, а общей взаимосвязи-то нету.

Во-вторых, господина Дизайнера надо подключать к процессу как можно раньше. Я всегда ратую за то, что нормальный старт работ над интерфейсом должен начинаться с общей встречи на несколько человек, где на бумаге будут прорабатываться основные подходы с точки зрения пользователей, ключевая бизнес-логика поведения экранов и оцениваться техническая реализация. По ролям эти несколько человек могут быть разные, но компетенции у них должны быть взаимодополняющие - и UX, и бизнес, и технологии. Без этого хороший интерфейс не сварить: если вы будете действовать по принципу «сперва нарисовали красиво, потом начинаем натягивать бизнес-логику» - то получится нежизнеспособная херня, если будете действовать по принципу «сперва проработали логику - а потом давайте рисовать» - то получится функциональная, но мертвая и скучная картинка.

Поймите, эмоциональный и логический дизайн не могут идти последовательно, друг за другом в полной изоляции - они должны начинаться в одной точке одновременно, и в этой точке должны определяться основные правила игры над интерфейсом для всех сторон. Диктатура визуала/бизнес-логики/техники - это путь в никуда, единственная диктатура, которую вы должны принимать - это диктатура продукта. А он про всё сразу, он про живой организм, он про взаимосвязь всего и вся.

6. Настает встреча с ЕБН. На нее едут все участники от разработчиков, но первую скрипку играет господин Дизайнер - он же руками все рисовал, вот и показывает макеты самостоятельно. (2%). Презентация решения дизайнером - классический подход, хотя и не лучший: лучше всего, когда команда коллективно рассказывает про разные аспекты макетов, потому что она прорабатывала их совместно. Иначе возможен перекос в сторону «МАНЬКА ГЛЯНЬ КАК КРАСИВО ТО» без конструктивного обсуждения.

7. Макеты господин Дизайнер показывает примерно в той же очередности, как и делал (1%). А вот тут, братушки и сестрицы, сокрыта огромная, грандиозная лажа. Запомните: всегда, нет, ВСЕГДА макеты надо показывать не в той последовательности, что вы делали, а в виде конкретного сценария: вот, мол, сценарий, вот так пользователь его проходит, вот тут заканчивает, досвиданья. Если вы будете показывать так - вам обеспечена конструктивная обратная связь и нормальное одобрение. Будете показывать разрозненные макеты - нарветесь на подозрительно легкое «ОК» или цепляние к цвету кнопочек, воздуху в заголовках и прочей фигне. И при таком раскладе вы в любом случае будете править макеты на разработке, когда заказчик НАКОНЕЦ-ТО примерит ваши макеты на реальный сценарий - и это будет дорого, долго и болезненно.

Сценарный подход (а в основу его можно класть тот самый CJM) серьезно упрощает и подготовку макетов, и согласование, и объяснение внутри команды. Придерживайтесь его и только его, макеты россыпью никому не интересны.

8. ЕБН кивает, процеживает «Вроде ничего» и дает добро на запуск в работу. (2%) Еще раз: самый плохой заказчик - это не тот, который докапывается до ваших макетов, а тот, который быстро со всем соглашается. Это значит, что ему пофиг на проект - и не дает вам гарантии, что он не начнет цепляться по делу на более поздних стадиях продукта. Будьте внимательны.

9. Макеты запускаются в работу, выкатываются разработчиком (1%). На этом этапе часто происходит море продуктовой фигни, но в большинстве случаев - это фигня, посеянная намного раньше. Про трудности общения с разработчиком мы еще отдельно поговорим.

10. Когда в проект запускаются пользователи, выясняется, что интерфейс - говно. (1%). Ну, тут почти без комментариев. Если на этом этапе что-то пошло НЕ ТАК, то вам некого винить кроме самого себя. Что наворотили, то и кушайте.

#хуиксугадайка #изкрестьянскогобыта

В жизни каждого половозрелого мужчины когда-нибудь наступает момент, когда он ищет себе UX-дизайнера.

(ну ладно, не каждого, не только половозрелого и не только мужчины, но вы же должны были это прочитать)

Вот и сейчас я ищу UX-дизайнера к себе в команду - работать над мобильным банком для физлиц. Вакансия жирная и хорошая, почитать про нее можно здесь: https://www.facebook.com/photo.php?fbid=2407201779325694&set=a.286139581431935&type=3&theater

«ЛЁХА Я ДИЗАЙНЕР НА НАСИЖЕННОМ МЕСТЕ Я ПОЛУЧАЮ МИЛЛИОН В МЕСЯЦ У МЕНЯ ВСЯ СПИНА В МЕДАЛЯХ Я ЧИТАЮ ТЕБЯ РАДИ ИСКУССТВА А ТЫ МНЕ ВАКАНСИЕЙ В НОС ТЫЧЕШЬ» - обидятся особо щепетильные гуру из числа вас.

Андрюха, спокойно, отвечу я. В следующем посте я расскажу вам, как подбираю себе проектировщиков и дизайнеров - давно грозился, да вот что-то повода написать не было.

А теперь есть.

#миртрудхуикс

Когда-то, когда мне было 33 года (то есть неделю назад), я вам обещал рассказать про то, как нанимаю себе хороших дизайнеров и проектировщиков.

Короче, усаживайтесь на табурет, сейчас буду лечить за методологию. У нас на повестке 3 пункта - два очевидных (хотя и важных) и ОДНО ЗОЛОТОЕ ЦАРСКОЕ НОУ-ХАУ, которое я припас напоследок. Если кто торопится и меня не уважает - сразу мотайте на следующее сообщение, а я пока покапитаню.

Перво-наперво, вам надо написать нормальный текст про вакансию: рассказать про то, как называется должность, куда вам этот человек нужен, с чего он вам понадобился, чего должен будет делать, уметь и знать, расписать про условия работы, и тут вы щас такие подумали, что попали в телеграм-канал «БОГИ ЭЙЧАРА» (не ищите, такого нет), поэтому скажу главное.

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

Второе, что вам надо будет сделать - это пообщаться с кандидатом. Тут я тоже не буду играть в телеграм-канал «ЭЙЧАР МАМИНОЙ ПОДРУГИ» (тоже не ищите) и расписывать подробно собеседование, но основное скажу. Обычно я делю собеседование на две части: сперва кандидат рассказывает о себе по формату «Как я докатился до жизни такой», а я задаю вопросы (как по поводу жизни и быта кандидата, так и очень сложные вопросы вроде «Что такое UX» или, там, «Чем отличается CJM от JTBD»), а потом мы меняемся местами: я рассказываю про проект, а вопросы задают мне.

Тут я смотрю не столько на то, что говорит кандидат (отвечать на вопросы по поводу JTBD можно и лошадь научить), но то - как он это говорит. Тут важно очистить кандидата от заученных фраз и формулировок и вывести его на настоящую живость мысли, чтобы оценить, как человек думает, сомневается, анализирует, критикует, воспринимает критику. Логика простая: инструментам и методикам можно научить любого, а вот умение слушать, думать, чувствовать и мудро действовать на дороге не валяется, и это хрен воспитаешь.

Если кандидат прошел через этот этап, он попадает на Самое Важное, на Святую Святых, на Царь-жемчужину Процесса Найма - на мое тестовое задание.

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

И все. Вот весь секрет. Давайте теперь рассмотрим внимательно, по каким принципам строится Мое тестовое:

1. Требования должны быть мутные. Это сделано намеренно: хороший дизайнер должен уметь работать в дефиците вводных и информации и его не должны пугать странные задачи, а наоборот - они должны вызывать желание разобратьтся.

2. Задание предоставляет максимальную свободу действий. Это, на самом деле, тяжело - когда тебе говорят «придумай сам себе условия задачи», родить интересное решение куда сложнее, чем когда тебя ставит через 100500 ограничениями. Но это и интересно проверить в кандидате.

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

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

5. Видно трудолюбие и чувство меры. Я не прошу нарисовать конкретно А, Б и В, но прошу нарисовать ровно столько, сколько кажется нужным. И здесь становится заметно, насколько человеку интересно заниматься своим делом и важно попасть ко мне на работу: если человек нарисовал полтора экрана, снабдил их каким-то корявым абзацем и на этом успокоился, нам с ним точно не по пути. И наоборот: если человек без лишних пинков с моей стороны продумал детали, попробовал разные варианты, подтянул обоснование к основным шагам и реально вкачался в тестовое - это человек, с которым будет интересно поговорить. Ну и попутно на этом проверяется опыт кандидата - это становится видно как на ладони.

6. Видно, как дизайнер работает со сроками. Еще раз, сроки я прошу назвать сам; в этот момент интересно смотреть, как человек оценивает свои возможности, свое время и работу - особенно в мутных поставленных условиях. И дальше надо смотреть - укладывается человек в сроки, не укладывается, просит ли он о переносе - и как просит, и так далее. Это тоже очень важный показатель.

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

И это тестовое - работает. Все мои дизайнеры и проектировщики - что в мою агентскую бытность, что сейчас, на стороне продукта - проходили через этот мутный ад и до сих пор вздрагивают при слове «фотообои», но задание того стоит. ЛЁХА РЕКОМЕНДУЕТ, в общем.

#батинаправда

Редко когда бывает, что я топочу ногами и реву от восторга от книги. Но сейчас именно такой момент.

Когда-то, когда я только въезжал в проектирование и дизайн, я вдохновлялся геймдизайном и профессией геймдизайнера в частности - просто потому что я очень давно (с 1988 года!) безотрывно люблю компьютерные игры и чуть-чуть знаю, как устроен их процесс создания изнутри. Какие-то вещи я вообще брал оттуда напрямую: например, постулат, что продуктовый дизайн - это не только процесс придумывания картинок; что продуктовый дизайнер - не специалист разряда «подай-принеси», а человек, который определяет душу и множество сторон продукта и должен его сопровождать; и так далее.

Сейчас я начал читать царскую книгу «Геймдизайн» от Джесси Шелл (долгих лет жизни Тане Субботиной за мудрый подгон) - и посмотрите, какая там красота:

—

Геймдизайн - это процесс принятия решений о том, какой будет игра.

То есть, чтобы создать игру, мне нужно просто принять одно решение?

Нет. Чтобы решить, какой будет игра, вы должны принять сотни и даже тысячи решений.

Геймдизайн требует наличия специального оборудования?

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

Так значит, геймдизайнер просто придумывает истории для игры?

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

Геймдизайнер - это единственный человек, который может принимать решения об игре?

Давайте сформулируем вопрос по-другому: каждый, кто принимает решение относительно того, какой будет игра, - это геймдизайнер? Дизайнер - это роль, а не человек. Практически каждый разработчик в команде принимает решения о том, какой будет игра, просто создавая для нее контент. Эти решения можно отнести к геймдизайну, и, когда вы их принимаете, вы становитесь геймдизайнером. Поэтому независимо от того, какую роль вы занимаете в команде разработки, понимание принципов геймдизайна поможет вам делать свою работу лучше.

—

Заметили, да? (это уже я, Лёха, говорю) Замените слово «гейм» на «продуктовый», «игру» - на «продукт», а «игрока» - на «пользователя» - и вы получите идеальное краткое описание сути продуктового дизайна.

Процесс создания игр вообще до крайности похож на процесс создания цифровых продуктов, но отличается одним: он честнее. Если пользователя можно заставить использовать продукт-говно (нет альтернатив, заставило руководство, нужно срочно решить задачу), то заставить игрока играть в игру-говно вы не сможете никогда, единственной мотивацией игрока является то, как игра доставляет ему нужные эмоции и впечатления.

Именно поэтому процессы геймдизайна (от общей идеологии продукта до интерфейсов) куда более зрелые, устоявшиеся и глубокие, чем это принято в основной массе во «взрослых» цифровых продуктах - там просто нет права на ошибку в плане пользовательского опыта.

#играйгармонь #йоукнига

Простите, но у меня тут бомбит после собеседования очередного кандидата.

Вот знаете, на каких вопросах срезаются кандидаты в UX-дизайнеры?

Думаете, на хитрожопых задачах вида «какие цветовые сочетания наиболее комфортны для глаз аудитории 60+ Кемеровской области»? Или «какая комбинация клавиш в Figma позволяет вам наиболее экономно нарисовать векторный кукиш?» Или же «Опишите исчепывающий набор действий, когда к вам приходит руководство и говорит, что вам надо за выходные доделать дизайн-систему за уволившимся специалистом другого отдела?»

Ха-ха 3 раза.

Вот вам самые убийственные вопросы-2019, выносящие UX-дизайнеров пачками что твои спартанцы:

1. Что такое цифровой продукт?

2. Что такое UX?

3. Что такое CJM? Что такое Jobs To Be Done?

4. Что такое Agile? Что такое Scrum? Что такое «водопад»?

И срезаются кандидаты не потому, что не смогли дать описание из учебника (тут-то я как раз люблю, когда кандидаты своими словами и мыслями все рассказывали, так интереснее), а потому что ВООБЩЕ ничего сказать по этому поводу не могут.

«НУ ЭЭЭ ЦИФРОВОЙ ПРОДУКТ ЭТО КОГДА ДИЗАЙНЕРУ ГОВОРЯТ ЧТО ДЕЛАТЬ». «НУ ЭЭЭ UX ЭТО КОГДА У НАС ИНТЕРФЕЙСЫ». «НУ ЭЭЭ CJM КАКОЕ CJM» (а у нас в вакансии сказано: не знаешь что такое CJM - не приходи).

У-у-у, бомбит.

#изкрестьянскогобыта

Говорят, что когда БОМБИТ - то лучше всего поделиться своим БОМБИТОМ с другими. Вот как вы считаете, на пустом месте мне голову рвет - или все-таки так не должно быть?
anonymous poll

И вправду - дичь какая-то – 187
👍👍👍👍👍👍👍 64%

ЭЭЭ CJM КАКОЙ CJM – 40
👍 14%

Ничего страшного, что средний UX-дизайнер не знает про продукты, UX, CJM, JBTD и прочее. Еще научится! – 30
👍 10%

ЛЁХА ДА ЛАДНО ЭТО ВСЕ НЕ НУЖНО ДИЗАЙНЕРУ – 17
👍 6%

Я ничего не понял, но сочувствую – 17
👍 6%

👥 291 people voted so far.

Гуглопочта для восстановления пароля предложила мне сперва ввести правильный пароль, а потом уже его восстанавливать.

На этом у меня пока все.

#богихуикса

«ДА ЛАН ЧО ХУИКСЕРУ ТЕХНИКОЙ ЗАМОРАЧИВАТЬСЯ, - слышишь иной раз такие рассуждения. - ТЕХНИКОЙ ПУСТЬ ИНЖЕНЕРЫ ЗАНИМАЮТСЯ". И добавит такой товарищ, пошевелив усами: "ПУСТЬ КОНЬ ДУМАЕТ У НЕГО ГОЛОВА БОЛЬШАЯ КАК ГОВОРИТСЯ."

А я вздохну и расскажу быль, почему UX-спец должен быть инженером хотя бы в душе.

Есть такой туроператор - TUI, и у них есть довольно простая процедура заказа тура:

1. Выбираете конкретный тур (когда, куда)
2. Выбираете перелёт (авиакомпания, время)
3. Заполняете паспортные данные всех участников
4. Вносите предоплату или сразу оплачиваете 100%
5. Вам подтверждается тур
6. Вносите вторую часть платежа, если не оплатили 100% на шаге 4
7. Получаете документы
8. Едете в Египет бухать, устраивать сауну прямо в номере и топить гольф-кар в бассейне (реальная, кстати, история; были у меня друзья... а, нет, не сейчас).

И вроде бы все хорошо и нормально, да?

А теперь следите за тем, как в ход вступает РЕВУЩАЯ РЕАЛЬНАЯ ЖИЗНЬ ЗА ХОЛМАМИ РАЗДАЮТСЯ ДАЛЕКИЕ ЗВУКИ БАЛАЛАЙКИ И ХРУСТ САПОГОВ МЕДВЕДЬ ПРОСЫПАЙСЯ МУЖИК ПРИШЕЛ ТВОИ УШИ ДРАТЬ.

Первым делом давайте заменим мирный пункт «Заполняете паспортные данные» на радиоактивное «Начинаете носиться по всей квартире и искать, куда запропастилось свидетельство о рождении ребёнка». Тогда начнется вот что:

1. Вы тратите 15 минут на поиск свидетельства о рождении и находите его почему-то в ЦЕЛЛОФАНОВОМ ПАКЕТЕ С ЦЕЛЛОФАНОВЫМИ ПАКЕТАМИ на кухне.

2. Выдыхаете, возвращаетесь к компьютеру и вводите данные. Система говорит ОК и пускает вас дальше.

3. Вам выводится счёт на оплату, который меньше ожидаемого процентов на 30. Вот так сюрприз! Вы думаете - ну лан, это же первый этап оплаты. Успокаиваетесь. Вносите деньги.

4. Сервис сообщает, что все готово, дожидайтесь финального подтверждения от менеджера.

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

6. Вы присматриваетесь к итоговому чеку и документам и обнаруживаете до кучи, что там начисто отсутствуют авиабилеты. Антинаебин начинает пульсировать в висках.

7. Вы звоните в TUI и три менеджера спустя разбираетесь, в чем дело: пока вы носились волчком и искали свидетельство о рождении, сервис покупки авиабилетов отвалился по таймауту. Личный кабинет TUI при этом проявил настоящее индейское хладнокровие и сделал то, чего не сделаешь даже специально: он оставил вас с туром, но без авиабилетов.

8. Вы аннулируете билет, молясь, чтобы деньги не успели списаться, а то ждать потом миллион лет возврата.

9. А дальше что? Ага: вы проходите всю процедуру с первого шага, по степени своей подозрительности готовые поспорить с самим Ким Чен Иром.

И мораль у нас сегодня будет такая. Вся эта канитель с личным кабинетом и таймаутами решается довольно легко: достаточно поставить проверку того, не изменилась ли стоимость тура при переходе с экрана заполнения документов на экран оплаты. Не изменилась - отлично, работаем дальше; изменилась - выводим предупреждение и запускаем отдельный процесс.

Но сложность подобных историй в том, что их легко разбирать лишь пост-фактум, когда система уже работает и приносит пользователям реальную боль. Если же вы хотите предусмотреть подобную ситуацию заранее, вам придется сделать небывалое: прорабатывать UX не только с точки зрения психологии, но и с точки зрения инженерии. Для того, чтобы подобных косяков не возникало, нужно прекрасно понимать работу системы изнутри, а особенно - работу на стыках с другими системами, ведь именно там, в точках интеграции, привыкли гнездиться особо упоротые UX-демоны. Именно там будут возникать разнообразные ошибки и внештатные кейсы, которые вам нужно будет разобрать, учесть и отработать в плане UX.

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

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

#богихуикса #изкрестьянскогобыта

Лучше нашей любимой рубрики БИСКВИТНЫЙ ДВОР может быть только рубрика БИСКВИТНЫЙ ДВОРЪ ВЪ СИНЕМАТОГРАФѢ.

Никита Мельников (@nikmelnikov, да золотится слава его в умах) прислал удивительную немую фильму-скринкастъ УВЛѢКАТЕЛЬНАЯ ТАЙНАЯ ЖИЗНЬ ЛИЧНАГО КАБИНЕТА.

Ссылку на фильму я вам сейчас дам, а пока советую включить фоном вот эту музыку: https://www.youtube.com/watch?v=dJ-Su4utvm8

Готовы? Тапёр играет? Тогда вот вам обещанный СИНЕМАТОГРАФЪ: http://somup.com/cqjwY4ew6t. Как посмотрите, возвращайтесь сюда. Музыку пока не отключайте.

Вот сижу и вижу, как авторы придумывали этот интерфейс.

— АСКОЛЬД, - говорил один из создателей, хохоча и крутя длинный ус, - ДАВАЙТЕ ПРИДУМАЕМ КАК ПОЛЬЗОВАТЕЛЮ ЖИТЬ ЧЕРЕЗ ЖОПУ.

— КОНЕЧНО ЭРАСТ, - отвечал второй из создателей, крутя гири в полосатом трико, - ДАВАЙТЕ ЗАСТАВИМ ПОЛЬЗОВАТЕЛЯ СТАРОГО КАБИНЕТА ВВЕСТИ СВОЙ ЛОГИН А ПОТОМ УЙТИ ПО КАКОЙ ТО ЛЕВОЙ ССЫЛКЕ И ЗАЛОГИНИТЬСЯ ТАМ ЗАНОВО.

— МАЛЬЧИКИ МАЛЬЧИКИ, - захлопала в ладоши старуха Габальда, третья создательница ЛК, - НЕХОРОШО ПОЛЬЗОВАТЕЛЯ ОСТАВЛЯТЬ В НЕВЕДЕНИИ!!! ПУСТЬ ЗНАЕТ КУДА ОН ПОПАЛ!!!

И как-то сам собой родился текст понятного и полезного уведомления: «Пользователь еще не перенесен».

«ЭКОЙ ВЫЙДЕТ АНЕКДОТ», - захохотал Аскольд. «ВЗДУЛИ ПОЛЬЗОВАТЕЛЯ КАК МОРСКОГО ЧЕРТА», - затрясся от юмора Эраст. «НЕ ОКАЗИЯ А КОНФУЗ», - мерзко завизжала старуха Габальда.

Так родился личный кабинет 2DOMAINS.

КОНѢЦЪ.

P.S. Чего бы я сделал на месте Аскольда, Эраста и Габальды? Сделал бы переброс пользователя из новой формы логина в старую с сохранением введенных данных. Да, это несет в себе много технических подводных камней, но это всяко лучше, чем плевать в душу пользователю - вы плюнете и забудете, а он-то запомнит.

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

А еще я бы сохранял текст во введенных полях только там, где нужно (спойлер: в поле ввода капчи - не нужно), иначе застрянете в той эпохе, когда щеки кирпичами натирали.

#бисквитныйдвор