Простите, что так пропал - решали тут на работе сложную задачу про волка, козу и капусту, которых надо переправить на другой берег в режиме Scrum’а (скрам-мастер, распевание скрам-псалмов по утрам и перевешивание стикеров с места на место прилагаются). Поскольку меня злобно у вас украли, я хочу отомстить ЭТОМУ ВАШЕМУ СКРУМУ и сказать про него от себя пару ласковых.

Точнее, про сам СКРУМ я рассказывать не буду - про него уже отхоливарено столько, что на двадцать гражданских войн хватит, - но хочу порассуждать о том, как СКРУМ взаимодействует с UX.

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

По замыслу СКРУМ-фундаменталистов, в этот момент должна устанавливаться благодать как на картинах эпохи романтизма (пейзане и пейзанки, коровы на залитом солнцем лугу и так далее); в реальной жизни вместо этого в итоге выстраивается типичная картина Брейгеля-старшего (алкашня, писающие собаки, разруха и уныние), особенно если говорить про UX-составляющую.

Почему так происходит? СКРУМ предполагает, что команда разработчиков обладает так называемыми Т-компетенциями: каждый специалист со временем прокачивается по смежным навыкам, и в идеальной перспективе аналитики начинают разбираться в коде, а разработчик - пропитываться аналитическими компетенциями, а все вместе они начинают учиться хитростям профессии QA. Сам по себе подход здравый: T-образные компетенции помогают балансировать нагрузку на команду и всем скопом наваливаться на задачи по аналитике и разработке. Ряд идеологов, впрочем, останавливается на делении на аналитиков и разработчиков, но общей сути это не меняет - все в команде начинают заниматься всем, попутно пропитываясь духом продукта, развивая чувство локтя и так далее.

Вся эта схема работает ровно до того момента, пока в СКРУМ не вклинивается UX. И вот тогда начинаются интересные вещи:

1. Наши бриганды - аналитики, девелоперы и QA - с жутким скрипом учатся UX-подходам, не понимают этой штуки и начинают творить лютую продуктовую фигню.
2. В процесс привлекается UX-дизайнер, который с порога начинает ЛЮТО, БЕШЕНО страдать: выполнение его работы требует долгих исследований и танцев с бубном, которые выходят за рамки спринта (что с точки зрения СКРУМа грешновато - все должно вписываться в спринт и преображаться в конкретный командный артефакт), а ту работу, которую он может сделать руками здесь и сейчас, он делает за три дня и сразу начинает скучать.
3. «ДАВАЙТЕ НАУЧИМ ЭТОГО СРАНОГО ДИЗАЙНЕРА КОДИТЬ ЧТОБЫ НЕ ПРОСТАИВАЛ» - начинает вопить СКРУМ-мастер и оказывается не прав, потому что большинство UX-дизайнеров органически не любят кодить и этому учиться не будут. Кроме того, если он даже будет кодить - кто ж будет исследовать и делать миллион подготовительных приседаний к дизайн-работе, которые требуют массу времени и сил?
4. «ДАВАЙТЕ РАСШАРИМ ДИЗАЙНЕРА СРАЗУ НА НЕСКОЛЬКО КОМАНД» - озаряет еще кого-нибудь, и бедного дизайнера начинают рвать на задачи нескольких команд сразу, от чего у него теряется весь фокус на задачах, подрывается командный дух и появляется ощущение, что он вернулся в старое-доброе агентство с 10 проектами в параллели и 20 менеджерами над головой.

5. «ЛАДНО ЛАДНО ДАВАЙТЕ ПРОСТО ПУСТИМ ДИЗАЙНЕРА РАБОТАТЬ НА ОПЕРЕЖЕНИЕ» - великодушно решает какой-нибудь сердобольный продакт овнер и разрешает дизайнеру планировать свою работу самостоятельно в отрыве от основного СКРУМ-процесса. И в этот момент для UX-дизайнера весь СКРУМ исчезает как с весенних яблонь дым: измученный дизайнер начинает работать по собственному, напрочь отвязанному циклу, перевешивая задачи на своей крохотной досочке и ориентируясь на единственную цель - давать основной СКРУМ-команде вовремя макеты.

На этом все выдыхают, успокаиваются и продолжают работать дальше. И все бы ничего, кабы не одно «но» - это уже не СКРУМ единой командой, а постоянное жонглирование разными методологиями и разными циклами разработки со всеми сопряженными рисками. Некоторым людям и особо либеральным Scrum-мастерам это ок, но многие упоротые СКРУМ-мастера начинают от того беситься и выть «УЧИТЕ ДИЗАЙНЕРА КОДИТЬ» и «УЧИТЕ РАЗРАБОТЧИКА ХУИКСУ». Наверное, где-то работает и такой подход с прокачкой, но в нормальном виде я его пока не встречал.

И не только я: на Западе очень многие проходились по сложным отношениям СКРУМа и UX, в том числе наши любимые гуру-деды из Норман-Нильсен Групп.

Так что если вас угораздило женить UX и СКРУМ, готовьтесь рвать задницу - не себе, так окружающим. Жизнь - все-таки сложная штука.

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

Друзья мои сердешные, как вы помните, я категорически не пускаю в этот блог рекламу - много мне платить не будут, а каждый из вас у меня и так на вес золота, чтобы подсовывать вам всякое гуано. Заместо этого я периодически палю бесплатную годноту, которая может оказаться вам полезна. Мне не жалко, а вам ничего не стоит - вот вам и основы для ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЙ между нами.

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

В этот раз мы будем собираться по теме бизнес-анализа и говорить про то, как (и зачем) стать бизнес-аналитиком, что это вообще такое, как описывать бизнес-процессы и работать с этим хозяйством. Хедлайнером конвента будет Семен Злобин из компании Align Technology (https://www.aligntech.com, это крупный международный медтех). Давним читателям нашего хуикс-блога товарищ Семен Злобин уже знаком - это постоянный поставщик нашего БИСКВИТНОГО ДВОРА, за что ему очередной земной поклон.

Собираемся мы 13 июля в 11.45 в Москве на территории Даниловской мануфактуры (Варшавское ш., 9, стр. 1Б) в офисе Align Technology. В программе разговоры, общение и еще раз разговоры: как правило, каждая наша встреча превращается в уютную дискуссию, где можно поговорить о своем наболевшем.

А теперь ВНЕЗАПНЫЙ ПОВОРОТ СЮЖЕТА: это собрание мы решили открыть для широкой публики, чтобы придти на него мог каждый желающий. Бесплатно, без смс и прочих лопухов.

Нужна лишь регистрация вот тут: https://forms.gle/7BXRXaRATZhpExATA

Почему мы говорим об этом в последний момент? А чтобы веселее было (все равно мы это делаем не для количества).

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

Я тоже буду с высоченной вероятностью, так что подходите знакомиться, устроим заодно АВТОРСКИЙ ВЕЧЕР ЛЁХИ БОРОДКИНА И СВИДЕТЕЛЕЙ ЕГО ХУИКСА.

#агабесплатнаягоднота

«АНАЛИТИКИ НЕ УМЕЮТ В UX И ТВОРЯТ ЛЮТУЮ ФИГНЮ? ЛЁХА ТЫ СОВСЕМ ПОЕХАЛ ЧТО ЛИ?» - такие добрые письма стали мешками поступать в нашу дорогую редакцию с прошлого четверга, и я понял, что меня то ли не так поняли, то ли я сам не так выразился.

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

Вот вам три мысли.

1. Если в большинстве случаев посадить неподготовленного человека в кресло дизайнера, нахмурить скрам-брови и сказать «МАЛЮЙ МНЕ ИНТЕРФЕЙСЫ», то действительно получится вышеупомянутая лютая фигня. Рисовать интерфейсы - это определенный навык, который требует знания инструментов, наличия художественного вкуса, понимания методологий и так далее. Воспитать хорошего дизайнера - это долгий, муторный и требующий определенной предрасположенности процесс, который проходят далеко не все.

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

3. Наконец, самое главное. Я допустил лютую ошибку, что не провел в четверговом посте четкой грани между «дизайнером» и «UX-подходами»: если визуальному дизайну обучишь не каждого, то принципы работы с UX способны освоить практически все участники процесса за вычетом уж совсем откровенных психопатов. Более того, я всегда выступаю против ЭЛИТАРНОГО СТАТУСА ХУИКС-СПЕЦИАЛИСТОВ - по моей мерке, UX-компетенциями в продуктах будущего должны обладать все участники команды, чтобы понимать, как результат их труда будет сказываться на пользовательском восприятии, клиентской лояльности и, соответственно, успехе продукта в целом.

Я глубоко убежден, что в будущем в командах все будут UX (и аналитики, и разработчики, и QA, и менеджеры, и кто угодно еще), и это слово станет наконец-то бессмысленным и ненужным.

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

#изкрестьянскогобыта #снимаюшапку

Наши любимые 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.

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

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

#богихуикса