Давайте задумаемся о библиотеке исследований. На рынке царит многообразие разных «умных» тулов для исследования, типа Dovetail или Condens. Но для многих команд такая сложность избыточна и они начинают гнуть более доступные инструменты, такие как Airtable, Confluence или Coda (это мы). Отчётики на отдельных страничках стоят на полочках. Всё красиво и аккуратно, как мы любим. Но что-то не клеится интегрировать такие инструменты в процесс принятия решений… 😶‍🌫️

Давайте честно обрисуем ситуацию. Если ваш продукт ставит перед вами задачу проверить пару продуктовых гипотез, то вы с большей долей вероятности сначала прикинете: «А какие из них я уже проверял(а)?» — и попробуете отыскать отчёт в личных закромах, чтобы сэкономить ресурсы. Если же такой ресёрч не проводился или отчёт безвозвратно потерян, то, засучив рукава, мы начинаем всё заново. Здесь бы нам пригодилась вышеупомянутая база, где хранится всё и всё можно найти. Так? 😒 Наверное.

Почему так неуверенно? Да потому, что даже если такая база есть, то ею всё равно никто без «палки» не пользуется. Никто не знает, появилось ли там что-то интересное и кто это сделал. Люди максимум кладут туда «своё», чтобы не забыть. На централизованное донесение информации просто не хватает ресурсов. Чтобы такой базой пользоваться, каждый дизайнер и исследователь должен загрузить себе в мозг всё, что там есть, как блокчейн, чтобы вспомнить, когда время придёт. 🤞

Уже утопично, правда? Но у нас же есть AI, больше не нужно всё помнить, он всё знает за нас, так? Верно, но только если есть наполняемость базы. Если там 3 ресёрча за 1998 год, то никаких полезных инсайтов мы не получим. Ответы AI будут очень похожи на ответы вашей мамы: «Раньше было так». 🥴

Так что пока база не будет наполняться, ничего не получится. И давайте честно — если у нас не хватает мотивации переименовать слой в Figma, о заполнении каких отчётов идёт речь? Может, тоже делегировать это AI? Можно, но тогда вы перекладываете на него и интерпретацию результатов, их анализ и reasoning. То есть AI превращается в какого-то волшебника Изумрудного города или Сверх-компьютер из «Автостопом по галактике». 42, а что 42, непонятно.

То есть, чтобы обеспечить достаточную точность работы модели, нужно аккуратно скармливать ей данные, а это уже их подготовка, а это — смотри пункт про слой в Figma.

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

Как вывод, я считаю, что исследования просто жизненно необходимы. Но вот все эти мощные специализированные инструменты актуальны для продуктов или проектов с большим числом исследовательских команд. Ценность их использования в небольших продуктах может и не отбить операционные расходы. А у вас как?

Меня, конечно никто не просил, но я сам пришёл к Саше на канал Дизайн-душнила и подушнил там на целый подкаст. Обсуждение получилось живым и интересным: обсудили эвристики, персонализацию и токсичность дизайнерского комьюнити 🤪

👀👀👀👀 Последний в этом году выпуск «ДиЛ» 🔥

В этот раз мой гость Дмитрий Ваницкий — дизайн-директор в EPAM. Для нас с Димой это уже кажется ежегодная традиция. Правда в тот раз я был гостем 👋

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

Было очень интересно, экспертно и живо 💎

Не забывайте ставить 💗

📹 YouTube
🎵 Яндекс Музыка
💙 Подкасты ВКонтакте
🎵 Apple Podcasts
📚 Литрес
🎧 Podster.fm

⚡️ Канал VanillaThunder
🎞 VanillaThunder на Ютубе
📝 На медиум

📕 Книга о ремесле счастья

Вот и 2024 год подходит к концу, и, по доброй традиции, хочу подвести итоги года, если, конечно, упомню всё. Если вкратце, то на год я возлагал надежды, и они отчасти оправдались, ведь даже самый лютый фейл — это опыт. И опыта в этом году у меня было много. 🤤

🥛 AI-jam. За этот год идея, которую я придумал, гуляя с собакой, переросла в серию ивентов в 7 странах, где дизайнеры соревновались в командах в использовании AI для повседневных задач. Откровенно говоря, интерес людей был не таким, на который я рассчитывал, и, тем не менее, мы очень здорово провели время, и спасибо всем, кто был вместе с нами. И если вы сами захотите провести такой ивент — напишите мне, и я поделюсь с вами методичкой и материалами.

🦌 Ouroboros. О, тут я хапнул много опыта. Идея была простой: создать сайт, где бы я мог делиться тренировками и мыслями о калистенике, а заодно поднимать миллионы на реферальной программе Amazon'а. Главный вывод: в одиночку такие проекты вести невероятно трудно, и результат гарантирован только в той области, где вы на самом деле профи. В моём случае ресурс у меня реально появился, причём неплохой, а вот с SEO и рефералкой — провал. Несмотря на то что я инвестировал в эти крутые AI-тулы и пробовал оптимизировать контент, без помощи экспертов всё это пшик. Ну или работает не так, как я представляю. Как итог — куча опыта, клёвый ресурс и апперкот по моему времени и кошельку.

👍 Display. На фронте ещё одного sandbox-проекта для немодерируемого тестирования дела обстоят получше, ведь тут команда есть. За год мы переработали систему проведения исследований, позволив создавать команды, проекты и нанимать респондентов, а также добавили возможность проводить тесты на живых сайтах. Успехи есть, тут я доволен, но впереди ещё долгий путь.

⭐️Learn. Продолжим положительную динамику моим рабочим проектом. Learn, а лучше сказать Eduverse — это экосистема продуктов для обучения наших профессионалов всему, что может им пригодиться. Это и каналы привлечения, и LMS, и Exam-creator, и автоматизированная система проверки практики. И тут есть чему порадоваться, ведь за этот год мы пересобрали почти весь опыт обучения и нафаршировали всю систему AI под завязку не просто потому, что хайп, а потому, что этим реально пользуются. И как вишенка на торте, нашу работу оценили на Brandon Hall Awards, где мы взяли три награды.

🔥 Vanilla Podcast. Ещё немного в копилочку. Идея снова была проста: запускаем канал на YouTube, производим контент, включаем монетизацию и гребём деньги лопатой. Лопата не пригодилась, зато теперь у меня есть ламповое местечко, где я могу говорить на всякие разные темы с самыми разными людьми (надеюсь, вам тоже достаёт). Будем продолжать.

Ну и в завершение я бы хотел пожелать вам в 2025 году гораздо больше позитива, как мышления, так и событий, которые будут вас радовать. Побольше приятного опыта и успешных проектов. Счастья-здоровья и корабль любви! 🛳❤️

Если не трудно, расскажите, что у вас как за год? )

🍭С наступившим всех! Как у вас дела? Как настроение? Признаюсь честно, у меня не очень. Состояние, хорошо знакомое мне с детства. Лет в 12 у меня была любимая игра «Age of Empires 2», я мог рубиться в неё днями, однако стоило мне сделать перерыв, например, съездить на дачу покопать огород, как возвращаться в мир завоеваний совсем не хотелось. При этом я осознавал, что стоит только создать новую игру, как всё понесётся по новой, но делать этого совершенно не хотелось.

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

⚡️ Начинайте вкатываться с чего-то небольшого, не стоит ожидать от себя той же продуктивности, что и до перерыва. Она придёт, но позже, а пока просто сосредоточьтесь на процессе, и маленькие победы подтолкнут вас к более сложным задачам.

⚡️Отключите голову и не рационализируйте: «почему так», «а зачем». Просто начинайте делать.

⚡️Если чувствуете, что дело идёт со скрипом, то переключите внимание на то, что вам действительно нравится, так колёса смажутся интересом.

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

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

🤔 С вероятностью 90% на любом собеседовании вы услышите вопрос о персонах, JTBD, journey maps или любом другом артефакте. «А как вы его сделали? А сколько людей опросили? А как потом применили?» — всё для того, чтобы узнать вашу технику. Но если отдалить свою линзу, то ключевой вопрос: «А зачем вы вообще создавали этот артефакт?»

И если не кривить душой, то в подавляющем большинстве ответом будет «Потому что на собеседованиях об этом спрашивают, и мне нужно что-то показать, чтобы меня взяли на работу» или «Потому что нас так учили». 💡 Хотя правильным ответом здесь будет только «Чтобы понять, как работает система и как её улучшить».

⚡️Можно ли делать крутые проекты без артефактов? Hell yeah! А можно ли тратить месяцы на полировку слайдов и отчётов, но так и остаться на месте? Ещё как! Можно ли найти баланс? НУЖНО!

Я не за то, чтобы не делать никакие исследования или не создавать артефакты в принципе, я за то, чтобы держать в голове основную цель: зачем вы это делаете? Если персона нужна вам для того, чтобы понять мотивы и цели аудитории и механизмы их достижения — сделайте персону. Но не нужно полировать этот артефакт до безупречности. 🎯 20% усилий на 80% результата.

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

👨‍🦳 Эх, было времечко... Я не часто вспоминаю былые времена, особенно когда я был безусым юнцом-дизайнером. Только иногда я просыпаюсь в холодном поту с криком «Грёбаный Вьетнам!», когда вечером смущённо понастальгировал. Но вот этот пост заставил меня задуматься: а что бы я посоветовал начинающим дизайнерам?

1. Не планируйте свою карьеру наперёд! Тут я с автором в корне не согласен. Если вы сейчас придумаете план по захвату кресла руководителя дизайн-отдела в течение 5 лет, то с вероятностью 99% ваш план пойдёт по... Не увенчается успехом. Вместо того, чтобы продумывать каждый шаг и строить learning paths, начните с базы и того, что вам действительно интересно. 👨‍💻

2. Начинайте с базы. Помните, что на начальных этапах вам никто не доверит продукт. Сами посудите, если ваша тётя объявит себя крутым брокером, вы доверите ей управление своим портфелем? Если у вас он есть, конечно, а не как у меня. Думаю, что нет. Так и в дизайне. Начинайте с маленькой пользы, которую вы можете нанести, отточите свои hard-skills, чтобы не тратить время на их изучение, когда перейдёте к чему-то посложнее. Не нужно бросаться на продуктовые метрики, пока вы не умеете красить кнопки. И пусть хейтеры кричат, что старые книги — это кринж, кивайте, но читайте! В них столько же знаний, как и в момент, когда они были написаны. Не бывает ненужных знаний — вы пустой сосуд. 👻

3. Сразу примите тот факт, что вы будете делать говно. Примите это. Миф о том, что кто-то положил пальцы на трекпад и сразу выдал шедевр — фуфел на палке. Ваши первые работы будут плохи, важно, как вы их анализируете и делаете выводы. Это поможет вам отстраниться от своей работы, когда её начнут поливать другие дизайнеры, а они начнут. Также важнейший навык — смотреть на то, что делают другие, и досконально разбирать работы на части. А ещё более важно, эти выводы превращать в решения — действовать и не бояться ошибаться! 😦

4. Если вам сложно себя заставлять учиться, то подумайте, насколько вам действительно важно стать дизайнером. Если вы думаете, что ментор, как надзиратель, запинает вас в профессию, то у меня новость — на работе ментора может и не быть. И кто вам тогда поможет? Вы должны развить в себе самый важный навык — самообучение. И консультироваться с ментором по вопросам «я застрял, как мне выбраться?», а не «что мне делать?». 😬

5. Изучать бизнес нужно только после того, как вы разовьёте системное мышление. Начинайте с простых вопросов: «Как это работает?» Вместо того, чтобы погружаться в тонкости ведения бизнеса, разбирайтесь в том, как устроены более прямолинейные процессы и почему. Experience mapping вам в помощь. 🤝

Вот, наверное, всё. А какие советы вы бы дали себе молодому/молодой? 🤓

Я думаю, что вы уже не раз слышали такое выражение, как «Low hanging fruits» 🍑. Обычно, на приоритезационных сессиях в эту категорию попадает то, что мы можем сделать быстро, без особых инвестиций, но что принесёт какую-то пользу. Чаще всего именно в этот квадрат и устремляются все глаза, когда встаёт вопрос о том, что нам делать дальше. 👀 Но почему? Потому, что это легко. Но ведь легко ≠ полезно. Происходит подмена понятий.

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

Да и девелоперы подливают масла в огонь своими: «дорого» или «невозможно». 🔥Неужели лентяи? Или вдруг разработчики начали заботиться о бизнесе? Не то и не другое. Всё потому, что их просто пинают! Выставляют нереалистичные ожидания и заставляя экономить ресурсы.
Пара таких спринтов, и команда уже перестраивает свой майндсет с «сделаем, как будет лучше» на «сделаем, как нам будет проще». И вот мы получаем некоторую выученную беспомощность, когда вопросы о том, что, может, стоит сдвинуть релиз на пару недель, уже даже не возникают. Но разве это гонка? Что-то я не видел случая, когда скорость релиза приносила больше пользы, чем вреда. 🏎

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

Как с этим бороться? Как говорил Дамлдор: «Поступайте, как правильно, а не как просто». 🧙🏻‍♂️Сбалансируйте свои приоритеты: принимайте во внимание не только вещи, которые вы можете сделать прямо сейчас (например, мелкие багфиксы или добавление незначительного функционала), но и какие инвестиции вам нужно сделать для того, чтобы в будущем вкусить большие и сочные плоды (например, рефакторинг кода, внедрение новой архитектуры или разработка инновационной фичи, которая выведет продукт на новый уровень). Не бойтесь больших задач, ведь декомпозицию никто не отменял. Разбивайте сложные задачи на более мелкие и управляемые, планируйте ресурсы и время, и постепенно двигайтесь к цели.

Так поднимите же голову и мыслите стратегически! Анализируйте долгосрочные перспективы, оценивайте риски и инвестируйте в будущее вашего продукта.

Читаю сейчас книгу Карен Хорни «Невроз и личностный рост», и как оказалось я эгоцентричный невротик с завышенными требованиями от себя и реальности, движимый внешним одобрением. 🤪 Ну а кто сейчас нет, да?

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

Если бы я был эмоционально целостным и независимым (хе-хе), то когда кто-то доносил мне обратную связь по моей работе, я бы мог просто сказать «Спасибо!» и исправить недочёты. 😡 Но в реальности мой внутренний критик-гопник орёт: «Чё он сказал про нашу работу? И ты это просто так оставишь? Он сомневается в нашем профессионализме! Нужно доказать ему, что мы лучшие!» И вот я сижу ночью и делаю то, о чём меня даже не просили, чтобы завтра словить «Молодец, что овертаймишь! Но мы это пока просто не сможем сделать».

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

⚠️Disclaimer: если какой-то синдром мешает вашей жизни, то его нужно прорабатывать. Я не призываю вас забить на своё психологическое здоровье, нет. Но если ваши комплексы не мешают жить вам и окружающим, то может это не комплексы, а особенности? Не пытайтесь переделать себя в кого-то другого, идеального и неприкосновенного, так вы навредите себе больше, если будете ещё и переживать о том, что не соответствуете идеальному образу себя. 😇 Просто примите, что иногда вы требуете от себя больше, и это нормально, если при этом вы не кладёте на алтарь своё физическое здоровье. Ничего плохого не случится, если иногда вы сделаете что-то сверх своих обязанностей или потратив немного больше времени, чем наэстимировали, или последуете за своим интересом даже, когда все отправятся на диванчик. А как ещё расти?

Что думаете?

Сейчас я по уши в OKR, и это не про “заполнил табличку — жди чудес”. Это когда ты такой:
⚡️ “Ставим амбициозные цели!”
😇 “Измеряем прогресс!”
🤔 “А почему никто этим не пользуется?”

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

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

Что будет:
— Где грань между креативностью и профессионализмом? Разберёмся.
— Технологии vs Человеческий интеллект. И это всё, что ты можешь, AI?
— Истории креативного успеха и дизайнерского провала.

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

Ссылка на сам стрим (там и напоминашку можно поставить).

Время: 19:00 UTC +02:00

Статья об ошибках A/B-тестирования давненько лежала у меня в загашнике, и только сейчас я решил сделать небольшую выжимку, ибо советы реально толковые! 💡 Вашему вниманию 6 ошибок, которых следует избегать:

1. Тестировать плохо сформулированные гипотезы.❓ Помните, что хорошая гипотеза не только описывает, что вы тестируете, но и почему. То есть «Изменённое положение CTA приведёт к большему числу покупок» не даёт нам представления, а почему и за счёт чего, собственно, это должно произойти, а значит, мы не знаем, что именно измерять. Вместо этого переформулируем: «На данный момент мы теряем множество лидов на этапе завершения заказа. (Почему?) Изменение положения кнопки позволит сразу замечать следующий шаг пути (За счёт чего?), что приведёт к увеличению числа завершённых покупок (Что изменилось?)».

2. Смотреть на данные только в суммарном виде. 📊 Здесь мы рискуем попасть в так называемый парадокс Симпсона, когда эксперимент показывает один результат по усреднённым значениям, а в сегментированном — другой. Например, когда мы тестируем понятность нового флоу, средние результаты могут показать, что он работает лучше контрольного, но стоит нам разбить результаты по когортам, как может оказаться, что для некоторых ролей или, например, регионов, он покажет значительно худшие или лучшие результаты. А это повод достать лупу и исследовать кроличью нору поглубже.

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

4. Заканчивать тестирование, как только оно достигает статистической значимости. ⏱ Вам нужен запас. Во-первых, вы рискуете сделать поспешные выводы на данных, которые могут измениться со временем. А во-вторых, данные нужно будет чистить, что может снизить количество респондентов, и в нужный доверительный интервал вы уже не попадёте. Так что наберитесь терпения и ждите. Сколько? Сложно сказать. Пока не увидите, что паттерн стабильный; пока не наберёте +15–20% от минимальной необходимой выборки; или ещё один день.

5. Тестировать без пилотного запуска. 🧑‍✈️ Конечно, если вы эксперт и всё настроили правильно, то вы… всё равно можете обосраться. Прежде чем раскатывать полномасштабное исследование, проведите тест теста на маленькой выборке, чтобы убедиться, что всё настроено верно.

6. Игнорировать контр-метрики. ⚠️ Помимо того, что ваш тест может показать прирост целевой метрики, он может также наломать дров в других местах, куда не падает наше «далеко не всевидящее око». Починили конверсию — поломали активацию. Починили активацию — поломали конверсию. Так у нас, конечно, всегда будет работа, но лучше вырваться из порочного круга и собрать лист метрик здоровья продукта и принимать их в расчёт при каждом тестировании.

Вот такие советы, тестируйте и не факапте, дорогие друзья! 🎉

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

Мысль была здравой, так как наша DS действительно была заточена на сложные интерфейсы Delivery и People Management, где нужно смотреть на нагруженные дашборды, продираться через сложные таблицы и видеть на экране всё, что может пригодиться для принятия сложных управленческих решений. Наша же LMS была направлена на потребление контента — обучение, чтение, просмотр видео и т. д. Как вы понимаете, вещи не совсем совместимые.

Эту мысль я и положил в основу нового концепта — упрощённое потребление контента. 💃 А под шумок ещё пустил свою рванину в пляс: заменил fontface, укрупнил заголовки до максимума, стёр весь визуальный шум… а чё такого? Это же концепт. Просто посмотреть, как может быть, да? Нет.

Оказалось, что новое видение очень даже зашло, и стейкхолдеры реально решили его имплементировать, несмотря на то, что всё там было из говна и палок, шито белыми нитками: гигантская часть интерфейса, пограничные случаи, интеграции и легаси просто не брались в расчёт. ☹️ Ещё одной ложкой бензина в костёр пылающего зада послужил вброс: «А теперь нам это всё нужно развернуть на нашей либе!» Понимаете иронию? Я специально максимально далеко отходил от статуса Кво, чтобы создать себе побольше проблем… Нужно было идти в команду либы и просить их создать нам новую тему, даже две, так как тёмная тема тоже просочилась в скоуп. А ещё и респонсив… В общем, получилась романтическая история совы и глобуса. Если бы не самоотверженность команды, из этого болота выгрести не получилось бы. Поклон вам в чистые ноженьки!

Ретроспектива проведена, выводы сделаны. И вот снова наступает солнечный день, и снова поступает предложение создать концепт будущей AI-driven платформы вместо нашей текущей экосистемы. 🤖 Ну, думаю, тут либа вообще ни при чём, про остальное спрошу: что в скоупе, что нет. И вроде метим только в десктоп, делаем всё сами, с нуля, никаких зависимостей. А может, вообще не будем ещё ничего делать, так что чего напрягаться-то? Бдительность моя была немного усыплена. А очень зря.

И снова я со всей дури прыгаю на грабли недальновидности: мобила вползает в скоуп, зависимости текущих систем выходят из тени, и либа тут как тут. 😡 Короче говоря, чтоб я ещё раз послушал Скарлетт О’Хара и «подумал об этом потом»!

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

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

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

Концепты, по определению, служат одной цели — разъяснить, как что-то может работать, помочь собрать в голове пользователя или заказчика ментальную модель. 🤯 При этом он совсем не обязательно должен на 100% отражать реальность, быть построенным на дизайн-системе или вообще быть цифровым. Он вполне может быть выполнен в виде user flow, сториборда или бумажного прототипа (как давно я их не видел!).

Чаще всего концепты можно встретить на этапах пресейла, где нужно на верхнем уровне обрисовать, что именно мы хотим создать, чтобы затем это оценить и представить заказчику пропоузал; или во время POC (proof of concept), где у нас возникла определённая гипотеза, которую мы хотим проверить.

🪙 Давайте сначала о пресейлах. Судьба концепта после этой фазы незавидна. Совсем. После того, как контракт подписан, чаще всего концепт реиспользовать не получается, потому что собран он из говна и палок. На то есть ряд объективных причин. Во-первых, клиент не подпустит к своей DS кого попало, чтобы они собирали решения на ней, вот и приходится собирать UI-киты на своих опухших от варикоза коленках. Во-вторых, времени на каждый такой пресейл выдаётся в 3 раза меньше, чем просит самый наивный студент, а значит работать приходится в два раза больше и быстрее. В-третьих, вероятность выигрыша пресейла хочет обнять 0, как брата. Вкладывать много усилий в заведомо неиспользуемую работу никто не хочет. Ну и наконец, вы не можете гарантировать, что концепт полностью отражает видение заказчика. Конечно, вряд ли вы встретите неадекватов, которые просили AI-driven CRM, а после подписания запросили лопату. Но вот плавно перетекающие и изменяющиеся требования — это повсеместная история. То есть вроде как сперва действительно хотелось AI-driven CRM, но после первого погружения стало очевидно, что новое решение не очень-то и нужно, проще исправить старое. Вот и получается, что ваш турбо-концепт становится королём мусорного ведра.

🛡 Теперь давайте поговорим о том, что происходит с концептами на этапе POC. Здесь ситуация немного лучше, так как концепты строятся чаще в рамках существующего продукта и у вас может даже быть доступ к собственным библиотекам и сорсам. При этом не стоит путать концепт с рядовой фичёй. И для того и для другого можно строить прототипы и проводить тестирование, но концепт, как я уже говорил, скорее призван дать понять, как что-то будет работать. Например, нарисовать интерфейс для работы с AI-ассистентом — это задача. А вот интегрировать AI-ассистента в существующую LMS — это уже концепт, так как ХЗ, как, куда, зачем и как эта херабора будет работать. И для того и для другого мы скорее всего создадим визуальный прототип, но во втором случае голова будет болеть сильнее, так как не будет ни документации, ни оформленных требований. При этом, опять же, концепт только создаёт общее представление, без углубления в детали и пограничные кейсы. Затем чаще всего следует этап тестирования и принятия решения: а будем ли мы вообще это реализовывать.

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

Нашёл пост, который очень хорошо отражает мои мысли о том, почему Figma в последнее время так расстраивает дизайнеров.

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

Все последние апдейты будто недостаточно инновационны. Казалось бы, пример InVision должен был научить, что нельзя считать себя «слишком большим, чтобы упасть». Но падают все, стоит только ударить посильнее.

И тут даже ценовая политика и глубокие корни в корпоративные кошельки не помогут — достаточно взглянуть на Photoshop.

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

Веб-разработка уйдёт в ноу-код (Webflow или Framer), визуалы найдут себе что-то получше (даже ту же Canva), и останутся тут только рожки да ножки сурового интерпрайза.

А что делать? Держать нос по ветру, и не класть свои яйца в одну корзину. Не потому, что какой-то тул хороший, а какой-то плохой, а потому, что дистанция между ними сокращается, а баки потенциала у Figma пустеют. Так что им хорошо бы инвестировать во что-то существенное в самое ближайшее время. Хотя чё это я в самом деле, разбухтелся? 🥸