Допустим, мы с вами проектируем лэндос по перспективнейшей услуге - катанию на свиньях. И вот мы такие берем и расписываем:

1. Рассказываем про катание на свиньях: что это старинный обычай, тянущий свои корни из посконной древности.

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

3. Показываем, что катание на свиньях подходит как для одиночек (верхом), для семейных пар (в пролётке), для семей с детьми (тройка свиней, запряженная цугом в телегу). Приводим тут же восторженные комментарии в доказательство: «Я всегда думал, что катание на свиньях - это страшно и непонятно. Но оказалось, что хрюша такая теплая и щетинистая, что захотелось взять ее домой)))) но жена против! день прошел НА УРА! (Виталий, 35 лет)»

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

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

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

И все, дальше идем взрывать рынок, выходить в ТОП-100 и становиться свиными олигархами (я ж вам обещал в самом начале? 💪💪💪💪💪). Пользуйтесь на здоровье.

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

Я - существо гордое, но стадное. По ТГ-каналам катается флешмоб - так и у нас пусть покатается как жеребёнок по заливному лугу кверху копытцами.

Флешмоб такой: нужно перечислить 3 самые недооценённые и 3 самые переоцененные вещи в чем-либо. У нас с вами Хуикс - значит, будет про Хуикс.

Начнём с самых недооценённых вещей:

1. UX.

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

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

2. UX/UI-дизайнеры

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

3. Командная UX-работа

UX - это про рисование картинок сумасшедшим одиночкой (чтобы денег много не тратить)? Тогда вот вам и ещё одно обесценивание - роль команды в UX.

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

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

А вот самые переоцененные вещи:

1. UX/UI-дизайнеры

Ха, как я вас подловил! Да, дизайнеры - это одновременно и недооценённые страдальцы, и переоцененные бонвиваны. Что, впрочем, логично: поскольку UX/UI-дизайнеров в полном смысле слова не ценят, на передний план вылезают модные ребята с подворотами, которые часами могут рассуждать про цвет тиффани, последние награды авввардс и НАСМОТРЕННОСТЬ, но при этом ни бельмеса не понимают в том, для кого и зачем они рисуют свои нетленки. Там, где художник сьедает с потрохами психолога, на смену UX проходит Хуикс, запомните.

(Кейс, где психолог сьедает художника, чуть менее печален - на выходе мы можем получить просто удобное унылое говно, оно даже выстрелить может)

2. Методологии и серьёзные щи

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

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

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

3. Сраные слайдеры на главных страницах.

Я долго думал, что ещё есть третье переоцененное в Хуиксе, и вдруг понял - сраные многостраничные слайдеры на главной. Это фиаско, роспись дизайнера в своём бессилии, аналог термина «пол-шестого» применительно к интерфейсам.

Я про это когда-то писал, поэтому не буду шибко повторяться, но слайдеры в действительности плохо работают. Никто не будет внимательно читать склад рекламы дальше первого, ну ладно, второго, ну окей, третьего (МАКСИМУМ) слайда, если только вы не рассказываете связную историю или попали на сверхлояльную аудиторию, которая вами живо интересуется. И все это надо измерять и проверять.

Скорее всего, если вам в голову пришла мысль «а не херануть ли сюда слайдер» - это повод задуматься и его не херануть.

Что ж, таковы новости из мира Лёхи к этому часу, всем спасибо, здоровья, счастья.

А теперь ВНИМАНИЕ ВОПРОС! А что вы считаете самым пере- и недооценённым в UX- и хуикс-дизайне?

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

КСТАТИ, У МЕНЯ ЖЕ ЕСТЬ ЧИТАТЕЛИ!!! - внезапно вспомнил я, пока писал новый пост (спойлер!) про тяни-толкай между бизнесовыми и системными аналитиками.

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

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

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

Поехали!

* Организация, запрещенная на территории Российской федерации

#хуикс-вече

Дорогой читатель @slavasokolov прислал нижеследующий партнёрский материал от Медузы и ещё каких-то перцев, даже упоминать их не хочу.

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

#бомбаж

По многочисленным заявкам объясняю, почему картинка от Медузы про UX/UI (см. выше) - зловредное неправильное чмо.

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

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

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

🍷 Хинкали, вино, пхали, красный диван и даже вы сами - это в данном случае UI. Это то, с чем будет взаимодействовать гость и через это получать хорошее настроение.

🎉 Хорошее настроение - это и будет в данном случае UX, то есть позитивный субъективный опыт (эмоции, впечатления) от взаимодействия.

Проектировать UI - это думать, какие сделать пхали, какое выбрать вино, чем накрыть диван и куда его выдвинуть. Это про конкретные предметы и их свойства.

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

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

Чувствуете, да? Хороший продукт создается не там, где некий этап «UX-дизайна» предшествует этапу «UI-дизайна», а там, где UI-дизайн является составной частью UX-дизайна, направленного на построение полноценного, вкусного, сытного, качественного взаимодействия.

UI - это то, что создает UX, а UX - это то, что придает весь смысл UI. Это гораздо более сложное и переплетенное взаимоотношение, чем голимые «этапы» и «шаги».

Чтобы вы прочувствовали это получше, сейчас я сделаю шашлык из тезисов с клятой медузовской картинки.

1. UX: создание удобного и функционального продукта. UI: создание узнаваемого и приятного в использовании продукта

Херь собачья. Чтобы создать идеальный UX, вам нужно сделать полезный (функциональный), удобный и интересный (узнаваемый, приятный) продукт. UX-дизайн заморачивается этим всем.

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

2. UX: планирование пользовательских сценариев и расположение элементов. UI: создание. конкретных элементов интерфейса: кнопки, поля ввода, баннеры.

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

Я знаю, это сложный момент, поэтому вернусь к грузинскому примеру. Когда вы подбираете мягкое красное покрывало для дивана, вы о чем думаете - чтобы было красиво или чтобы гостю было приятно? Да вы про все думаете - и чтобы было красиво, и через это гостю было приятно. Так и UX/UI-дизайнер об этом думает, неспроста же это сочетание возникло и хорошо себя показывает.

3. UX: проведение тестирований и глубинных интервью с пользователями. Работа с их результатом. UI: построение интерфейса по результатам тестирований с опорой на гайдлайны, тренды и насмотренность.

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

И в-третьих, что за белиберда с «работа с результатом интервью» в UX? UI с этим не должны работать, что ли?

4. UX: все внимание - на мыслях и ощущениях пользователя и том, какую из его задач решает сервис. UI: все внимание - на действиях пользователя и том, как сервис решает его задачи.

Дебилизм верблюжий. UX-дизайн как проектирование ВЗАИМОДЕЙСТВИЯ делает упор на мыслях, ощущениях и действиях пользователей, которые ведут его к выполнению своей задачи. UI-дизайн делает упор на том, на какие интерфейсы эти действия, ощущения и мысли приземлить.

5. UX: создается на основе информации о пользователях совместно с аналитиками. UI: создается на основе UX-дизайна и передается разработчикам.

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

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

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

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

😻 Когда хороший хозяин лепит хинкали, он думает про гостя, его вкусы и предпочтения на всем протяжении процесса, а потому хинкали выходят вкусными, душевными и теплыми. После них хочется сказать «Вай мэ!».

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

Не надо так.

#бомбаж

Хочу, братья мои, перетереть с вами за аналитиков - уж очень разные они бывают.

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

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

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

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

Формально, впрочем, все не так страшно. По своему замыслу бизнесовые и системные аналитики делятся так:

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

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

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

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

Чуете, да? Из-за того, что живая разработка не всегда идет по принципу «сперва придумай идеальный сценарий, а мы его реализуем», но часто закольцовывается, пересекается и ходит по кругу, БА начинает думать как СА, а СА начинает думать как БА. Со временем начинают происходить и еще более чудовищные вещи: БА может при продумывании задачи учитывать системную архитектуру и какие-нибудь особенности микросервисов, а СА - описывать задачи с минимальным вовлечением БА. БА приобретает черты СА, а СА начинает издали походить на БА.

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

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

Подкину, впрочем, вам еще пару исключений:

1. Помимо ветки развития в супераналитика, СА в теории могут эволюционировать в системного архитектора, который плевать хотел на эти ваши бизнесовые замороки.
2. У БА есть отдельная ипостась - БА в консалтинговом агентстве. Эти ребята живут по своим специфическим правилам, далеким от нашей крестьянской разработки, и это отдельный жанр жизни и интересный опыт.
3. Никто не отменял жизни в огромных жестких мегакорпорациях, где ты сидишь как чистый БА или СА, перекладываешь задачки в жире по регламенту и медленно погружаешься в корпоративный дзен.

Но это исключения. В остальном же запомните:
⁃ Если ты БА, то готовься стать СА - или работать в узком забюрократизированном сегменте;
⁃ Если ты СА, то готовься стать БА - или работать в узком забюрк.. забрю… забор… тьфу, короче, вы поняли;
⁃ Если ты набираешь аналитиков себе в живой продукт, смотри на то, кто тебе нужен и что человек умеет, а не на то, кто как прозывается. Это все в большинстве случаев пустое.

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

Котаны, до меня доехала книга Карла Вигерса The Thoughtless Design Of Everyday Things, сейчас буду делиться впечатлениями.

(Да-да, это из той самой посылки, которую Амазон от меня пытался зажопить несколькими постами ранее - но доставил-таки, курилка)

Если вы сейчас подумали «ЧО ЗА ВИГЕРС-ХУИГЕРС», то представьте себе, будто Джордж Лукас отжал у мышастого лицензию на «Звездные войны» и снял новую часть, при этом экспериментируя с новыми жанрами и привлекая нормальных сценаристов и режиссеров. Мощное возвращение, да?

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

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

И вот этот самый Вигерс, император аналитики и проектирования, без объявления войны выпускает книгу про дизайн, в которой нескрываемо стебется над книгой The Design Of Everyday Things («Дизайн привычных вещей») под авторством Дона Нормана - чудодейственного старца, который, на минуточку, когда-то придумал термин «UX».

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

Мои постоянные читатели хорошо знакомы с рубрикой БИСКВИТНЫЙ ДВОР, где мы берем разные говнокейсы и с улюлюканием раскладываем их на плоскости. Это особый, приятный сердцу спорт на жанровом стыке искусства и охоты на бешеных кабанов.

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

Все это перемежается ссылками на цитаты из себя любимого и еле сдерживаемыми приступами трололо наподобие вот такого:

(эта важная иллюстрация, если вы не поняли, показывает зазор между нормальным решением и полным говном)

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

1. Делайте продукт простым и очевидным в использовании.

2. Учитывайте реальные сценарии использования

3. Учитывайте широкий разброс контекстов использования

4. Делайте так, чтобы пользователь с трудом мог ошибиться (тут мои навыки переводчика, как видите, дали слабину).

5. Давайте пользователю полезную обратную связь.

6. Не тратьте время пользователя впустую.

7. Подчиняйте дизайн удобству для пользователя.

8. Учитывайте огромную вариативность людей.

9. Не возлагайте на пользователя большую ментальную нагрузку.

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

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

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

Вигерс снова крутой, будьте как Вигерс.

P.S. А! Вспомнил еще историю, как Карл Вигерс однажды моего кореша на хер послал, но про это я вам отдельно расскажу.

#йоукнига

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

Для начала давайте договоримся: я буду называть бизнесовых и системных аналитиков словом «аналитик», а вы будете делать вид, что так и нужно, ладно?

(почему так можно - читайте парой постов выше)

Итак, у нас есть дизайнер и аналитик, которых надо увязать в единый процесс. Чисто по логике у нас есть три доступных варианта:

🖕 Вариант АЗЪ. Сперва аналитик прописывает требования и спецификации, затем дизайнер по ним рисует макеты.

Вариант классический и повсеместно распространённый, но хероватый.

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

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

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

Все демотивированы, сказки не выходит, занавес.

🤞 Хотя подождите! У нас же есть еще вариант БУКИ! В этом случае дизайнер может рисовать макеты первым, а аналитик городить свою аналитическую балалайку на их основе.

Впрочем, это тоже херня, заканчивающаяся примерно одним и тем же: дизайнер рисует классные макеты, передаёт аналитикам и слышит через 15 минут от них вой «ДА ЭТО ЖЕ ТАК НЕ РАБОТАЕТ». И начинаются переделки и хождения кругами, сопровождающиеся срачами и воплями «ДА ОТКУДА ОН ЭТУ ХЕРНЮ ВЗЯЛ». Тоже не фонтан.

🤟 Вариант ВЕДИ. Пускаем аналитику и дизайн в параллель - нехай соревнуются.

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

⁃ ТАК ЧТО ЖЕ О МУДРЫЙ ЛЁХА, - спросите вы скромного меня, - ВЫХОДА НЕТ ЖИЗНЬ БОЛЬ И АНАЛИТИКА И ДИЗАЙН ЭТО ДВА УРОБОРОСА ПОЖИРАЮЩИХ ДРУГ ДРУГА И НАШИ НЕРВЫ?

Нет, друзья мои. Есть еще более хитрый вариант, про который я умолчал - и который пойдёт у нас под названием ВАРИАНТ ГЛАГОЛЬ.

👌 Итак, вариант ГЛАГОЛЬ. Мы берём и переплетаем между собой работу аналитика и дизайнера. Не ставим в параллель, не чередуем, а именно переплетаем как аджарец - сырную косичку.

Выглядеть это может так. Приходит к команде сумасшедший продакт типа меня и говорит: «ЖЕЛАЮ ЧТОБЫ БЫЛА КНОПКА НА НЕЕ ЖМЕШЬ И ВСЕ МЕНЯЕТСЯ».

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

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

Расхождения будут - но их можно будет легко отработать в паре. Из-за тесного взаимодействия они смогут договориться в духе «ну чо, Василь Игнатыч, накидаешь мне наброски экранов по моим обрывкам юзкейсов, как мы обсуждали?» или «Макар Степаныч, аналитик ты мой дорогой, я пока рисовал - нашел дурацкий кейс, давай подумаем, как система себя должна вести». Аналитик и дизайнер становятся единой боевой единицей и начинают подстраховывать друг друга - подобная конструкция давно показала свою жизнеспособность в большом маркетинге и называется там креативной парой (в рекламе она состоит из копирайтера и арт-директора - по сути, аналогичных ролей).

Прелесть хорошо выстроенной креативной пары в том, что в ней отпадает вопрос, кто должен ОБЯЗАТЕЛЬНО работать первым, а кто вторым: люди вместе решают общую задачу, и в состоянии сами договориться, кто что делает в какой момент времени - где-то в параллели, где-то сменяя друг друга, а где-то работая буквально вместе рука об руку.

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

И дальше начинается хорошая жизнь. Вылезла ХИЩНАЯ ЖОПА? Не беда, креативная пара в состоянии сообща решить, где нужно бороться интерфейсными методами, а где - изменяя функциональность. Дизайнер уперся в левый юзкейс? Не проблема, аналитически-дизайнерская пара способна пересмотреть процессы и обрубить лишнее, чтобы все работало гармонично. Пользовательское тестирование показало, что все фигня? Не вопрос, креативная пара придумает, как с этим справиться.

И так далее: хорошо выстроенная пара способна бороться с неопределенностью, решать возникающие жопы и двигаться вперед.

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

Тем самым термину «дизайн» возвращается его истинное значение, коль скоро это не только отрисовка внешнего вида решения, но и продумывание его логики и внутренней структуры.