Заскучали? Вот вам авторская хуикс-мудрость от Лёхи на каждый день.

Кстати, вы будете смеяться, но однажды я сталкивался с проектом, где заказчик просил "СДЕЛАТЬ ЧТОБЫ НА ГЛАВНОМ ЭКРАНЕ ВРАЩАЛСЯ ЗЕМНОЙ ШАР А НА ЗАДНЕМ ПЛАНЕ ВООДУШЕВЛЕННО ПЕЛ КАЗАЧИЙ ХОР"

Нет, не шучу. Да, так и сделали. Нет, ссылку не дам.

#каквтретьяковкусходил

ПАЦАНЫ ПАЦАНЫ ЛЁХУ ПОКАЗЫВАЮТ В ТЕЛЕВИЗОРЕ!!!!

Если вы хотели:

- Не читать в очередной раз мое жонглирование словами;
- Увидеть меня с золотым носорогом в руках;
- За каким-то чертом посмотреть, как я смотрюсь в кожаном кресле;
- В тридесятый раз выслушать мои байки про деда с банджо на картридже SNES (мои старинные читатели вспомнят этот, гм, кейс);
- Узнать, за что я люблю Dwarf Fortress;
- Понять, что роднит нейросети и Спартака;
- Просто послушать про прошлое, настоящее и будущее продуктового дизайна,

- то возрадуйтесь же! На вашей улице сегодня перевернулся грузовик с арбузами, блэкджеком и пифиями: https://www.youtube.com/watch?v=hG1aD1VUEEo

А если вы вообще пришли сюда из этого видео, то, как говорили в рекламе мещанских обогревателей "Доброе тепло", земной вам поклон и добро пожаловать.

#концертыстасамихайлова

Котаны, котаны, я с вами!

На вопрос «ЛЁХА ГДЕ ЖЕ ТЫ ЛЁХА» у меня будет вам два ответа:

1. Это был непростой год (с) Тут вам и позитивные штуки вроде выхода на новую работу (если вы не знали, нынче я продакт в «Магните»), и всякий адок вроде оттоптавшегося по мне ковида. Нужна была передышка, чтобы придти в себя и разобраться со свободным временем. Это штука чисто организационная.

2. Я сменил работу - и дизайна в моей жизни стало меньше. Если в Росбанке я хороводил команду дизайнеров и плотно отвечал в том числе за продуктовый дизайн, тут я больше морочусь развитием продукта, экономикой, бэклогами и всем таким. С точки зрения дизайнеров я уже не Артемий Татьяныч Лебедев, но пункт выдачи задач и бородатый дядя, который при необходимости поможет, но больше будет спрашивать.

Казалось бы, на этом и сказочке конец, Лёха садится на коня и уезжает в закат под песню ланфрен-ланфра. Но нет же!

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

Б. Хуикс как канал (и как вы лично) мне дорог, важен и вообще я вас люблю, котаны. Без вас жизни нету.

В. Работать меньше я не стал, поэтому у меня постоянно есть новые мысли, идеи и камни для кидания в окна, которыми я хотел поделиться - они не только про Хуикс, но и про всякое продуктовое.

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

И как быть - писать редко, но про дизайн, или более часто про все, что меня волнует в цифре? Для решения этого вопроса я провозглашаю себя Хуикс-атаманом, надеваю на себя казачью папаху и объявляю НАРОДНОЕ ВЕЧЕ. Любо!

Интересно ли вам в Хуиксе читать не только про дизайн, но и про цифровые продукты, их развитие и все такое? Как обычно, предельно откровенно, понятно, без напыщенного говна и с рубрикой БИСКВИТНЫЙ ДВОР
anonymous poll

ЛЁХА ДА ТЫ ПИШИ МИЛЫЙ ПРО ЧТО УГОДНО ТОЛЬКО ПИШИ – 261
👍👍👍👍👍👍👍 60%

О да! Мне интересно читать, чем живет продукт вне дизайна – 137
👍👍👍👍 32%

О нет! Меня интересуют только интерфейсы, дизайн и фигма всякая – 21
👍 5%

Я не хочу ничего решать, у меня лапки-выпадашки – 14
▫️ 3%

👥 433 people voted so far.

Знаете, что такое ад для дизайнера?

Нет, это не когда надо рисовать 3 варианта макета одного и того же на выбор.

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

И нет, это не когда заказчик отвечает вам на макет, который вы исследовали и строгали 2 недели, «ЭТИ КАРТИНКИ НАРИСОВАЛА БЫ МОЯ СЕКРЕТАРША ЗА 5 МИНУТ»

Нет. Настоящий, сука, ад - это когда твою работу берут и отправляют куда-нибудь в рабочую группу на ОБЩЕЕ ГОЛОСОВАНИЕ. Типа, коллеги, мы не можем выбрать нужный вариант, давайте проголосуем всем миром и выберем лучшее, коллеги. Спасибо, коллеги.

Тем самым дизайнер ставится врастопырку:

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

2. Если все пойдет хорошо и ОБЩЕЕ ГОЛОСОВАНИЕ одобрит макеты дизайнера, то тем самым ему какбе намекают, что, вася, ты сейчас молодец и мы тебя одобрили, но ты смотри… такое не всегда может быть, в следующий раз можешь и не понравиться. Дизайнер чувствует себя во власти толпы.

3. Если все пойдет плохо и ОБЩЕЕ ГОЛОСОВАНИЕ зарубит макеты дизайнера, то тем самым ему какбе выносят вердикт, что ты, вася, не командный игрок, работаешь херово и вообще это тревожный звоночек. Дизайнер чувствует себя говном.

4. И - самое главное - при этом хороший дизайнер задается вопросом: да какого черта?!!

Какого черта эти люди вообще принимают решение, нравится или не нравится дизайн, они не целевая аудитория, они работают в той же компании, они знают его лично (и, например, могут проголосовать против, потому что рожа дизайнерская не понравилась) и вообще не ре-ле-вант-ны? Как вообще можно оценивать дизайн голосованием в почте? Это же, сука, не так делается!

И вот тогда - вот тогда - дизайнер может услышать за спиной перестук копыт, ощутить на своем левом плече когтистую лапу и услышать басовитое: «СЫНОК ДОБРО ПОЖАЛОВАТЬ В АД»

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

P.S. Еще у нас царская новость - я подключил комментарии к постам. Теперь вы можете рассказывать свои не менее ужасающие истории, я могу не менее ужасающе шутить в ответ, ну и вообще начнем устраивать интерактив. За идею спасибо боярину Кириллу Алексеичу.

Начинать можно с этого поста, всегда-ваш-лёха-коллеги-спасибо-коллеги.

«ЛЁХА ТЫ РАССКАЗАЛ ПРО АД ДЛЯ ДИЗАЙНЕРА А КАК ПО УМУ ЖИТЬ ТО» - спросили меня дорогие читатели в комментариях.

Нате на лопате 5 правил Лёхи по согласованию дизайна:

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

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

(не путайте только мудака и въедливого заказчика, но об этой разнице поговорим в отдельном посте)

🍉 Ошибайтесь раньше, ошибайтесь чаще.

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

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

Дополнительный бонус от частых сверок с клиентом: в какой-то момент он начнет перенимать вашу логику мысли и будет чаще принимать вашу сторону.

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

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

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

🍱 Договаривайтесь на берегу о дизайн-процессе - кто, что, когда, каким образом. Чем более структурно и авторитетно вы будете действовать, тем меньше глупых вопросов будет возникать по ходу дела.

Такие вот нехитрые правила. Наверняка их можно придумать еще (ату в комментарии! давайте их собирать!), но конкретно на эти грабли приходилось натыкаться много раз. Фразы «Да вы будете ко мне ходить до скончания века, пока мне не понравится», «Да моя секретарша нарисовала бы это за 15 минут» и «А что тут делает Шуфутинский?» до сих пор эхом звучат в моей голове

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

Окей, зумеры, поделюсь своей воскресной менеджерской болью.

Есть такая штука - поспринтовая разработка, крайней формой выражения которой является Скрам (или, как выражаются некоторые интересные айтишники, Скрум).

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

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

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

Скрум можно проиллюстрировать вот таким слайдом, который я когда-то собрал для работы:

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

👨‍👨‍👦‍👦 У вас нет всех специалистов - например, за аналитикой приходится ходить в отдел аналитики и просить их, чтобы они взяли в работу вашу задачу наподумать. В этом случае принцип «Давайте выберем хотелку из бэклога, возьмемся за руки и выкатим ее первую реализацию через 2 недели» не сработает - придется ждать аналитику от других людей.

🦍 Задача эпически сложная и в прокрустово двухнедельное ложе Скрума не укладывается. Да, я знаю, что апологеты Скрума сейчас начали орать «КАК ЖЕ ТАК ЛЁХА ЛЮБУЮ ЗАДАЧУ МОЖНО ДЕКОМПОЗИРОВАТЬ ДО ЭЛЕМЕНТАРНОГО МИНИМУМА И ЗАПУСКАТЬ ЕГО» - так вот, ни черта подобного. Говорю это как продакт, чье приложение пришлось интегрировать с системой 1982 года выпуска в течение двух, сука, месяцев беспрерывной возни (и это было только начало).

👯‍♀️ Дизайн херово дружит со Скрумом. В этом убеждался и лично я, и мои любимые деды из Норман-Нильсен групп (см., например, тут: https://www.nngroup.com/articles/ux-agile-backlog). Суть в следующем: работа дизайнера занимает много времени и очень трудно прогнозируема - в самом начале пути сложно сказать, попадем ли мы с первого раза в нашего пользователя и чем закончатся результаты предварительных тестирований прототипов. Нет, конечно, можно крикнуть на дизера «А НУ КА БЕСОВО ОТРОДЬЕ ЧТОБЫ ЧЕРЕЗ НЕДЕЛЮ МАКЕТЫ БЫЛИ У МЕНЯ» - но мы, во-первых, получим лютую херню, а во-вторых - не спасем разработку, потому что дизайн ей нужен не под конец, а в самом начале спринта.

🍄 Возникают вопросы по нагрузке. Берем предыдущий кейс с дизайнером: ну, ок, заставили мы беднягу нарисовать макеты не за неделю даже, а за три дня, а дальше-то что он будет делать? Трогать макет он не может - он в разработке. Скрум-апологеты в этой ситуации не теряются и дают два совета.

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

Второй совет - «А ПУСТЬ ОН ВПРОК МАКЕТЫ ДАЛЬШЕ РИСУЕТ, ИССЛЕДОВАНИЯ ПРОВОДИТ И ТАК ДАЛЕЕ». Но, ребята, вот тут стопэ. На кой хер дизайнера тогда включать в спринт, если он ЗАВЕДОМО будет заниматься не задачами спринта, а какой-то перспективной фигней, проходящей вне церемоний Скрама?

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

#скрумота

А вот и следующая серия Хуикса!

Видите, я как сериал про Шерлока Холмса (который с Кубмербрджайчем) - каждый сезон выходит раз в столетие. И у этого есть суровая причина: интенсивность моей жарки мыслью напрямую зависит от вдохновения, а оно - от того, насколько мне хорошо на работе. Если мне хорошо - у меня дофига мыслей и спортивной злобы, если мне плохо - то хрен вы меня услышите.

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

Вариантов как жить, на самом деле, четыре.

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

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

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

😻 Вариант четвертый. Я его назову скромно ЛЁХА - не потому, что я его придумал, а потому что он мне нравится; вообще так живут многие. Можете его расшифровывать как Легкий Ёмкий Хромированный Алгоритм. Щас расскажу, в чем его прикол.

Вариант ЛЁХА строится следующими шагами.

1. Забиваете на пункт из Скрам Гайда, который запрещает вам изменять Скрам. Если что, скажете потом - Лёха разрешил.

2. Разделяете команду на две части - в одну загоняете UXеров, дизайнеров и аналитиков (назовем ее кокетливо Discovery Team), в другую загоняете разработчиков, QA и аналитиков (назовем ее незамысловато Dev Team). Тут вы скажете - Лёха, проснись, ты уже не понимаешь, что сам пишешь - у тебя аналитики сидят и там, и там. Но нет: так надо, слушайте дальше.

Эти две подкоманды будут заниматься радикально разными вещами. Так, Discovery Team возьмет на себя исследовательскую работу, которая сопряжена с большой мерой неопределенности. Она возьмет идею фичи от менеджера и пойдет говорить с бизнесом, пользователями, раскапывать имеющиеся возможности, описывать решение и так далее. Dev Team же будет работать с уже очерченными (и отрисованными!) задачами, вышедшими из-под пера Discovery Team - будет брать в работу постановку и дальше делать свою черную девелоперскую магию.

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

4. Пытливый читатель, я думаю, обратил внимание, что Discovery Team и Dev Team отличаются друг от друга степенью рискованности своей работы. Если Discovery работает в режиме «пойди туда не знаю куда, принеси то не знаю что», то Dev Team, в идеале, работает с четко сформулированной задачей, которая, конечно же, может притаить в себе рискованную жопу (кому сейчас легко), но хотя бы на уровне базовых вводных шататься не будет. И в этом есть своя суровая крестьянская правда: разработчики как никто другой ценят определенность, четкость и однозначность, а дизайнеры и исследователи, по долгу работы, не должны пугаться лютой неопределенности.

5. Раз у нас есть две подкоманды с радикально разными ценностями - то и процессы мы им можем дать разные. Следите за руками:

⁃ Discovery Team, вся из себя неопределенная, может работать со своими задачами по Канбану - по сути, постоянному конвейеру задач (который идеально подходит для того, чтобы довести задачи до реализации максимально быстро, насколько позволит неопределенность);
⁃ Dev Team, вся из себя системная и четкая, может работать со своими задачами по Скраму (который идеально подходит для того, чтобы дать команде четкий фронт работ, спрогнозировать результат и не лезть к ним лишний раз с дурацкими изменениями).

6. Иными словами, мы выстраиваем глобальный процесс, при котором канбанный конвейер Discovery Team своим дальним концом упирается в Скрам Dev Team и служит для него постоянно работающим источником задач.

7. Выглядит все это примерно так:

Для особых задротов даже так скажу: мы выстраиваем систему, когда Definition of Done канбанной команды Discovery становится Definition of Ready скрамообразной команды Dev.

В чем плюсы такого подхода:

⁃ Есть стройная производственная схема, соединяющая продуктовую идею на уровне «Ну я хз» с конкретной реализацией;
⁃ Каждый работает в своей комфортной системе координат, никого не надо давить солдатским сапогом и переламывать об колено.
⁃ Если мы что-то можем спрогнозировать - мы это можем спрогнозировать; если где-то должны работать со свистящей неопределенностью - работаем с ней.
⁃ Мы можем масштабироваться и плодить отдельно столько Discovery и Dev-команд, сколько нам нужно.

А вот в чем минусы:

⁃ Управленчески это требует определенной хореографии;
⁃ Есть риск, что команда развалится надвое и будет потеряно горизонтальное общение между Discovery и Dev;
⁃ Аналитиков будет рвать на части. Возможно, вы полечите это разделением на бизнес- и системных аналитиков, а возможно - не полечите.
⁃ Некоторые агиле-коучи будут объявлять вас отступниками и подсылать к вам наемных убийц.

Но вообще - схема рабочая. Так я делал мобильный банк, так я работал над цифровой аптекой, и так я сейчас буду работать на новом продукте. Схема ЛЁХА проверена Лёхой, держите от меня гарантию качества, печать и что там еще вам приложить надо.

Такие дела. Фух, ребята, как же я по вам соскучился.

#скрумота

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

И вот, спрашивает чувак, нужно ли мне заморачиваться тем, чтобы веб и мобила работали по одним и тем же правилам и выглядели похоже? Или можно дизайнерам все оставить на откуп и НЕ ПЕРЕУБЕЖДАТЬ ИХ ДЕЛАТЬ ЕДИНООБРАЗНО А ТО С НИМИ СПОРИТЬ ТЯЖЕЛО А ОНИ ХУДОЖНИКИ И ТАК ВИДЯТ ПО-РАЗНОМУ?

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

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

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

Ладно, думаете вы, чорт с тобой, обращаетесь к нему соответственно чину корабельного секретаря, посылаете нарочного и, наконец, договариваетесь о встрече. Предварительно вы решаете контрольно созвониться.

И вот настает день встречи, вы набираете Васяну, говорите «Привет» и начинаете панически решать, как вам к Васяну обращаться - как к ГЫГЫГЫ ВАСЯНУ ЛЮБЛЮ ТЕБЯ ВСЕЙ ДУШОЙ или как к корабельному секретарю. Но Васян сам приходит вам на выручку и молвит скрипучим скучным голосом «Аааа это ты пенёк обоссанный, какая шаболда тебя ко мне занесла, титька ты тараканья? Ты как с дамой общаешься?»

И вот вы мне скажите, дорогие: как вы будете относиться к такому Васяну, с которым вообще не знаешь чего ожидать на каждом этапе коммуникации? Правильно: как к конченому дебилу, от которого надо держаться подальше.

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

И как мы должны называть дизайнеров, которые каждый тянет дизайн-одеяло на себя в в ущерб продукта?

Правильно: титьки тараканьи.

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

Давно, друзья, к нам не захаживала рубрика БИСКВИТНЫЙ ДВОР, где мы разбираем говнорешения, гоним их, надсмехаемся над ними.

Сегодня у нас в гостях малюсенький кейс-никчемушка от одного зелёного банка - давайте условно называть его Сбербанк.

Кейс простой: мы хотим перевести деньги по номеру телефона. У нас на счету 19 992,04 рубля, мы переводим 19 992 рубля, что может пойти не так?

Ааа, сука, все может пойти не так. Вы не можете перевести из 19 992,04 рублей 19 992 рубля, потому что 19 992 в загадочной зелёной реальности превышает 19 992,04.

Вы, конечно, можете поправить очки на носу и сказать, что:

⁃ Там наверняка закопана комиссия;

⁃ Срабатывают хитрости округления копеек (на самом деле нет);

⁃ Давно известна лютая ненависть Сбера к переводам по номеру телефона (т.н. СБП), доходящая до анекдотов и маразма, когда функция скрывается за семью экранами, восемью запорами и девятью рычагами, лишь бы не пустить туда пользователя.

Но, Герман Оскарович, я-то тут при чем? Откуда мне знать про комиссию и почему я должен быть заложником неведомой корпоративной херни?

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

1. Пользователь должен понимать, что произойдёт на следующем шаге (а это я в их божественном интерфейсе не понимаю);

2. Пользователь должен понимать, что только что произошло (этого я тоже не уразумел).

Предупреждений о комиссии нет. Текст ошибки - херовый.

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

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

Братцы, палю бесплатную годноту.

Если кто-то желал увидеть Того Самого Лёху (т.е. меня) сегодня в прямом эфире, то эта золотая возможность настала: в 18.00 я буду выступать на краснознаменном митапе Epic UX, где буду рассказывать про роли и должности, связанные с UX - с ними творится поистине невероятный терминологический бардак, в который я обожаю кидаться кирпичами и грязью. Сегодня кирпичи и грязь вы сможете увидеть своими глазами.

Запись тоже будет. К слову, на Epic UX выступают и другие, очень годные спикеры: например, дорогой моему сердцу Гриша Коченов из «Агимы», которого слушать - не переслушать, Миша Правдин из Avito и другие. Программа действительно вкусная.

Зарегаться на мероприятие и вообще почитать о происходящем можно тут: https://bit.ly/3AiJUaE

😱😱😱 ВАЖНО! Митап бесплатный + вдовесок организаторы из Epic Growth отсыпают 7 дней бесплатного доступа к своим ресурсам, НО ЕСТЬ НО: если вы не откажетесь за эти 7 дней от подписки, с вас спишутся бабки.

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

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

На этом конкурс хуикс-частушек в комментах объявляю открытым.

Редкий случай, когда перед ботом @ChastushkiBot хочется снять шляпу.

UPD. Кто разберется, блин, как в комменты аудиосообщения из бота привешивать - тому ментальный пряник.