Недавно проектировал b2b-сервис с множеством форм и таблиц. Это был пример типичного продукта из данной области с длинной историей, желанием владельцев бизнеса сделать интерфейс лучше, и распространенной ситуацией, когда тот, кто платит за систему, и те, кто ей пользуется, по-разному смотрят на интерфейс.
Честно говоря, сотрудники могут адаптироваться даже к очень неудобному интерфейсу, ведь им нужно платить за квартиру и кормить семью. Они обычно не жалуются, что формы неудобные или не хватает горячих клавиш для эффективной работы. Но это не значит, что дизайнер должен игнорировать эргономику.
Например, в статье «Why Users View Details Better with Slideovers» обсуждается использование пространства страницы. И я часто вижу стремление заполнить весь экран, как будто наличие пустого места — это важная проблема. Хотя цель должна быть в удобстве, а не в заполнении площади.
Компактное расположение информации ускоряет работу. Саккады (быстрые движения глаз при сканировании информации) становятся короче, когда данные находятся близко друг к другу. Глазам приходится делать меньше работы.
Но дизайнеры продолжают растягивать формы и таблицы на весь экран, заставляя пользователей с большими мониторами двигать не только глазами, но и головой.
Стоит помнить, что наш глаз видит резко только в пределах 2 градусов угла обзора, именно там мы можем читать и различать детали. В диапазоне 5-10 градусов четкость падает, дальше начинается периферическое зрение с общими очертаниями. И чем больше площадь для сканирования, тем быстрее устает пользователь. А хорошие интерфейсы не должны вызывать излишнего напряжения.
Как вам ваши b2b интерфейсы, удобные?
Честно говоря, сотрудники могут адаптироваться даже к очень неудобному интерфейсу, ведь им нужно платить за квартиру и кормить семью. Они обычно не жалуются, что формы неудобные или не хватает горячих клавиш для эффективной работы. Но это не значит, что дизайнер должен игнорировать эргономику.
Например, в статье «Why Users View Details Better with Slideovers» обсуждается использование пространства страницы. И я часто вижу стремление заполнить весь экран, как будто наличие пустого места — это важная проблема. Хотя цель должна быть в удобстве, а не в заполнении площади.
Компактное расположение информации ускоряет работу. Саккады (быстрые движения глаз при сканировании информации) становятся короче, когда данные находятся близко друг к другу. Глазам приходится делать меньше работы.
Но дизайнеры продолжают растягивать формы и таблицы на весь экран, заставляя пользователей с большими мониторами двигать не только глазами, но и головой.
Стоит помнить, что наш глаз видит резко только в пределах 2 градусов угла обзора, именно там мы можем читать и различать детали. В диапазоне 5-10 градусов четкость падает, дальше начинается периферическое зрение с общими очертаниями. И чем больше площадь для сканирования, тем быстрее устает пользователь. А хорошие интерфейсы не должны вызывать излишнего напряжения.
Как вам ваши b2b интерфейсы, удобные?
👀5
Media is too big
VIEW IN TELEGRAM
В Лувре я увидел работы Бриджит Райли, они контрастировали с работами других художников. Простые линии, простые фигуры, которые создают ритм, иногда уводят в иллюзии. На фоне классических залов это особенно выбивается — её оп-арт слишком аскетичен, чтобы всем нравится, но это интересно. Вдохновился этим и сделал вот такой вайбкодинг проект.
Смотрите inspired-by-bridget-riley.vercel.app
Смотрите inspired-by-bridget-riley.vercel.app
❤4🔥1👀1
В последнее время все чаще встречаются материалы о низкой эффективности ИИ в компаниях. MIT в новом отчете «State of AI in Business 2025» пишет, что 95% пилотов с генеративным ИИ проваливаются. У Harvard Business Review вышла статья «AI-Generated “Workslop” Is Destroying Productivity» про мусорный контент, который убивает продуктивность. ИИ явно не оправдывает обещанных ожиданий.
Я вижу три главные причины.
Первая — завышенные ожидания. Хайп и агрессивный маркетинг платформ создали иллюзию, что ИИ сам все сделает. Реальность оказалась скромнее. Я сам много экспериментирую с ИИ, но если попробовать выделить области в которых ИИ не только ускоряет работу, но и создает ощутимый прирост рентабельности, то список будет коротким.
Вторая — неумение работать с инструментом. EY опубликовали исследование: компании теряют до 40% потенциальной продуктивности из-за пробелов в подготовке персонала https://www.ey.com/en_gl/newsroom/2025/11/ey-survey-reveals-companies-are-missing-out-on-up-to-40-percent-of-ai-productivity-gains-due-to-gaps-in-talent-strategy. 88% сотрудников используют ИИ для базовых задач (поиск, обобщение), но только 5% применяют его на продвинутом уровне, чтобы трансформировать рабочие процессы. Многие крупные компании только в 2025 году запускают программы обучения сотрудников, в общем, процесс в самом начале.
Третья — отсутствие системного внедрения. Компании пытаются оптимизировать существующие процессы, а не создавать новые на базе ИИ-технологий. Структурных изменений не происходит. Основные успехи пока в замещении аутсорса и отказе от внешних подрядчиков, т.е. там, где задачи хорошо формализованы и есть четкие критерии успеха.
MIT в отчете «State of AI in Business 2025» указывает, что разница в эффективности внедрения определяется не качеством моделей, а подходом.
Получается, что успешное внедрение требует обучения сотрудников, заказных разработок с адаптацией под специфику компании, фокуса на бэк-офисе и структурных изменений процессов. Но это же требования к любой современной динамичной компании, которая готова соответствовать вызовам времени. ИИ приносит много перемен, но стратегия выживания в бизнесе остается неизменной — меняйся или умри.
А в вашей компании ИИ уже встроен в процессы или пока точечные эксперименты?
Я вижу три главные причины.
Первая — завышенные ожидания. Хайп и агрессивный маркетинг платформ создали иллюзию, что ИИ сам все сделает. Реальность оказалась скромнее. Я сам много экспериментирую с ИИ, но если попробовать выделить области в которых ИИ не только ускоряет работу, но и создает ощутимый прирост рентабельности, то список будет коротким.
Вторая — неумение работать с инструментом. EY опубликовали исследование: компании теряют до 40% потенциальной продуктивности из-за пробелов в подготовке персонала https://www.ey.com/en_gl/newsroom/2025/11/ey-survey-reveals-companies-are-missing-out-on-up-to-40-percent-of-ai-productivity-gains-due-to-gaps-in-talent-strategy. 88% сотрудников используют ИИ для базовых задач (поиск, обобщение), но только 5% применяют его на продвинутом уровне, чтобы трансформировать рабочие процессы. Многие крупные компании только в 2025 году запускают программы обучения сотрудников, в общем, процесс в самом начале.
Третья — отсутствие системного внедрения. Компании пытаются оптимизировать существующие процессы, а не создавать новые на базе ИИ-технологий. Структурных изменений не происходит. Основные успехи пока в замещении аутсорса и отказе от внешних подрядчиков, т.е. там, где задачи хорошо формализованы и есть четкие критерии успеха.
MIT в отчете «State of AI in Business 2025» указывает, что разница в эффективности внедрения определяется не качеством моделей, а подходом.
Получается, что успешное внедрение требует обучения сотрудников, заказных разработок с адаптацией под специфику компании, фокуса на бэк-офисе и структурных изменений процессов. Но это же требования к любой современной динамичной компании, которая готова соответствовать вызовам времени. ИИ приносит много перемен, но стратегия выживания в бизнесе остается неизменной — меняйся или умри.
А в вашей компании ИИ уже встроен в процессы или пока точечные эксперименты?
❤3
Как вам идея, что в работе связанной с UX вы обречены чувствовать быструю потерю интереса к проделанной вами работе, потому что людям свойственна гедонистическая адаптация?
Это не моя идея, а из статьи «UX Is Thankless and That's a Good Thing».
Гедонистическая адаптация — это психологический процесс, при котором человек возвращается к своему обычному уровню счастья после значительных позитивных или негативных событий.
Как бы радикально вы ни улучшили интерфейс или процесс, эффект «вау» исчезнет быстро. Новый опыт станет привычным, разум пересмотрит свои ожидания, и то, что вчера казалось прорывом, сегодня воспринимается как норма.
Если не ошибаюсь, то Стив Джобс говорил, что хороший дизайн кажется очевидным, когда его показывают, но до этого никто не понимает, что именно нужно сделать. И мой опыт это похож, люди удивительно быстро забывают, что каждое элегантное решение кем-то было придумано.
Это не моя идея, а из статьи «UX Is Thankless and That's a Good Thing».
Гедонистическая адаптация — это психологический процесс, при котором человек возвращается к своему обычному уровню счастья после значительных позитивных или негативных событий.
Как бы радикально вы ни улучшили интерфейс или процесс, эффект «вау» исчезнет быстро. Новый опыт станет привычным, разум пересмотрит свои ожидания, и то, что вчера казалось прорывом, сегодня воспринимается как норма.
Если не ошибаюсь, то Стив Джобс говорил, что хороший дизайн кажется очевидным, когда его показывают, но до этого никто не понимает, что именно нужно сделать. И мой опыт это похож, люди удивительно быстро забывают, что каждое элегантное решение кем-то было придумано.
Substack
UX Is Thankless and That's a Good Thing
Reframing Using Hedonic Adaptation Theory
❤4🕊1
Media is too big
VIEW IN TELEGRAM
Новый эксперимент без конкретной цели: звуковая генерация с триггером от видеокамеры и случайной генерацией на базе MagentaJS. Видео подтормаживает, потому что ноутбук не справляется с одновременной видеозахватом, сегментацией кадров, звуковой генерацией и записью.
Получилось вот такое чудо: https://v0-generate-music-on-demand.vercel.app/
Просто ради эксперимента.
Видео на Ютюбе https://youtu.be/3mH6iTzHXgw
Получилось вот такое чудо: https://v0-generate-music-on-demand.vercel.app/
Просто ради эксперимента.
Видео на Ютюбе https://youtu.be/3mH6iTzHXgw
Гуляя по Парижу и одновременно читая Дональда Нормана («Дизайн обычных вещей»), я задумался на тем, насколько американцу, который вырос в культуре, где функциональность часто доминирует над эстетикой, сложно понять ценность красоты как таковой. И это не просто вопрос национальной принадлежности (я беру слово «американцы» в кавычки не из-за паспортов, а из-за приверженности определенной парадигмы: рационализма, утилитарности, доминирования практической пользы над всем остальным).
Вопрос в том, насколько эта парадигма, заложенная в основы современного дизайн-образования, становится проблемой для всего мира.
Интересно, что сам Норман в «Эмоциональном дизайне» пытался говорить о важности эстетики, но даже там он стремился рационализировать ее, подчинить логике. А мне кажется, что это не просто разные аспекты одного явления, а ценностный выбор — это вещи, лежащие в разных плоскостях. Удобство и красота не всегда сосуществуют гармонично, иногда образ мышления, внутренняя культура подталкивают нас выбрать красоту, пренебрегая удобством. И этот выбор не возникает по нашему желанию — он формируется внешними усилиями: воспитанием, средой, традициями.
Кому-то везет, ценности передаются автоматически, если ты родился в определенной стране, семье, окружении. Кому-то приходится годами работать над собой, рефлексировать, чтобы развить вкус и понимание эстетики. Культура — это живой организм, у нее есть адепты и носители, которые распространяют и развивают ее. Это сложный механизм, зависящий от множества переменных, и он не сводится к одной формуле.
Приятно было бы думать, что все дело в деньгах. Мол, стоит людям разбогатеть, и сразу вырастет спрос на красоту. Но реальность показывает обратное. Особенно это заметно в постсоветских странах, где десятилетия насильственной социализации и унификации искусства под идеологические стандарты оставили след: люди часто просто не понимают, что такое эстетическая ценность. Конечно, будут прорывы, благодаря отдельным личностям с развитым вкусом, случайным обстоятельствам, но после каждого прорыва неизбежен откат в «дикость». И хорошо, если это движение окажется поступательным, если через пару поколений мы увидим прогресс. А если нет? Если нас ждет деградация, которую никто не заметит и не поймёт? Мир вокруг следующих поколений станет скучнее, примитивнее, лишенным глубины.
И все потому, что сегодня учатся не по тем книгам.
P.S. Простите за этот романтический, слегка беребердический пост. :)
Вопрос в том, насколько эта парадигма, заложенная в основы современного дизайн-образования, становится проблемой для всего мира.
Интересно, что сам Норман в «Эмоциональном дизайне» пытался говорить о важности эстетики, но даже там он стремился рационализировать ее, подчинить логике. А мне кажется, что это не просто разные аспекты одного явления, а ценностный выбор — это вещи, лежащие в разных плоскостях. Удобство и красота не всегда сосуществуют гармонично, иногда образ мышления, внутренняя культура подталкивают нас выбрать красоту, пренебрегая удобством. И этот выбор не возникает по нашему желанию — он формируется внешними усилиями: воспитанием, средой, традициями.
Кому-то везет, ценности передаются автоматически, если ты родился в определенной стране, семье, окружении. Кому-то приходится годами работать над собой, рефлексировать, чтобы развить вкус и понимание эстетики. Культура — это живой организм, у нее есть адепты и носители, которые распространяют и развивают ее. Это сложный механизм, зависящий от множества переменных, и он не сводится к одной формуле.
Приятно было бы думать, что все дело в деньгах. Мол, стоит людям разбогатеть, и сразу вырастет спрос на красоту. Но реальность показывает обратное. Особенно это заметно в постсоветских странах, где десятилетия насильственной социализации и унификации искусства под идеологические стандарты оставили след: люди часто просто не понимают, что такое эстетическая ценность. Конечно, будут прорывы, благодаря отдельным личностям с развитым вкусом, случайным обстоятельствам, но после каждого прорыва неизбежен откат в «дикость». И хорошо, если это движение окажется поступательным, если через пару поколений мы увидим прогресс. А если нет? Если нас ждет деградация, которую никто не заметит и не поймёт? Мир вокруг следующих поколений станет скучнее, примитивнее, лишенным глубины.
И все потому, что сегодня учатся не по тем книгам.
P.S. Простите за этот романтический, слегка беребердический пост. :)
❤8💯5
На Medium все больше выходит материалов от авторов, которые с помощью нейросетей пересказывают банальности или спорные идеи. Тем интереснее, когда попадается статья с авторской точкой зрения. Я подозреваю, в основе лежит попытка отрефлексировать меняющуюся реальность в работе дизайнера, но вместе с тем это и попытка нащупать дальнейшие пути развития и специалистов, и компаний.
Речь о статье "The value of Design in a product organisation" от Dan Ramsden (Creative Director for UX Architecture & UX Writing at the BBC).
Для меня у Dan Ramsden нашлось несколько интересных идей.
Во-первых, попытка отойти от навешивания ярлыков в работе дизайнера и посмотреть на суть стоящих проблем. Если просто назвать дизайн продуктовым, то это не помогает выделить уникальную ценность, которую создает дизайн. Дизайн процветает, когда помогает компании выявлять, формулировать и снижать риски, связанные с реальными проблемами пользователей. В то же время, зацикливаясь на своем продукте, дизайн легко уходит от решения реальных проблем к выдумыванию задач, которые лежат в русле уже созданного продукта, а не отвечают потребностям пользователей.
Во-вторых, мне нравится идея, что специалисты из разных областей обеспечивают не только широкий кругозор при решении задач, но и еще обеспечивают использование разных типов мышления. То есть вопрос не только в знаниях, но в том, что люди могут думать по-разному, и для решения разных задач нужны разные подходы. Поэтому важно междисциплинарное сотрудничество для достижения значительных результатов.
Эта идея мне особенно близка, потому что еще лет десять назад у меня в презентации, которая была посвящена предпроектной аналитике, был слайд о том, что разные задачи требуют разных подходов. И сейчас в лекциях о теории дизайна я стараюсь объяснить, что есть разные дизайн-методы, которые соответствуют, по большому счету, разным паттернам мышления, и для разного типа задач эффективно использовать разные подходы, а не пытаться всегда делать одно и то же.
Еще позволю себе процитировать определение продуктового дизайна, которое дает автор: «Дизайн — это набор структурированных процессов, позволяющих преобразовать замысел в эксперименты».
Мне кажется, это отличное определение, потому что оно смещает фокус от визуального представления, в котором часто застревает человек, думая о дизайне как о визуальном решении, к процессу, направленному на достижение желаемой цели. И в такой ситуации дизайн продукта перестает быть заботой только дизайнеров, а является результатом усилий множества вовлеченных специалистов разных направлений.
Речь о статье "The value of Design in a product organisation" от Dan Ramsden (Creative Director for UX Architecture & UX Writing at the BBC).
Для меня у Dan Ramsden нашлось несколько интересных идей.
Во-первых, попытка отойти от навешивания ярлыков в работе дизайнера и посмотреть на суть стоящих проблем. Если просто назвать дизайн продуктовым, то это не помогает выделить уникальную ценность, которую создает дизайн. Дизайн процветает, когда помогает компании выявлять, формулировать и снижать риски, связанные с реальными проблемами пользователей. В то же время, зацикливаясь на своем продукте, дизайн легко уходит от решения реальных проблем к выдумыванию задач, которые лежат в русле уже созданного продукта, а не отвечают потребностям пользователей.
Во-вторых, мне нравится идея, что специалисты из разных областей обеспечивают не только широкий кругозор при решении задач, но и еще обеспечивают использование разных типов мышления. То есть вопрос не только в знаниях, но в том, что люди могут думать по-разному, и для решения разных задач нужны разные подходы. Поэтому важно междисциплинарное сотрудничество для достижения значительных результатов.
Эта идея мне особенно близка, потому что еще лет десять назад у меня в презентации, которая была посвящена предпроектной аналитике, был слайд о том, что разные задачи требуют разных подходов. И сейчас в лекциях о теории дизайна я стараюсь объяснить, что есть разные дизайн-методы, которые соответствуют, по большому счету, разным паттернам мышления, и для разного типа задач эффективно использовать разные подходы, а не пытаться всегда делать одно и то же.
Еще позволю себе процитировать определение продуктового дизайна, которое дает автор: «Дизайн — это набор структурированных процессов, позволяющих преобразовать замысел в эксперименты».
Мне кажется, это отличное определение, потому что оно смещает фокус от визуального представления, в котором часто застревает человек, думая о дизайне как о визуальном решении, к процессу, направленному на достижение желаемой цели. И в такой ситуации дизайн продукта перестает быть заботой только дизайнеров, а является результатом усилий множества вовлеченных специалистов разных направлений.
❤3
Media is too big
VIEW IN TELEGRAM
Сегодня немного про вайбкодинг и GOMS — получился неожиданный микс.
При выборе способа создания интерфейса небольшое решение может вылиться в часы лишней работы для пользователя. GOMS позволяет это оценить заранее. Правда, нужно понимать, куда смотреть.
У меня сегодня небольшой пример: вайбпроект и калькуляция издержек по методу GOMS.
На Ютюбе https://youtu.be/UHksSxDv64M
При выборе способа создания интерфейса небольшое решение может вылиться в часы лишней работы для пользователя. GOMS позволяет это оценить заранее. Правда, нужно понимать, куда смотреть.
У меня сегодня небольшой пример: вайбпроект и калькуляция издержек по методу GOMS.
На Ютюбе https://youtu.be/UHksSxDv64M
Яндекс показал мне уведомление о новой функции — я не читая закрыл. Озон предложил что-то получить, если… — я не читая закрыл. Любое всплывающее окно в мобильном приложении вызывает у меня одну реакцию: как можно быстрее вернуться к привычной работе приложения.
Мир стал слишком сложным, и хочется хоть немного стабильности хотя бы в мобильном телефоне. Не хочется мега-апов с рекламными функциями и обязательными акциями. Хочется, чтобы просто работало.
Парадокс раздутых продуктов
В современных приложениях множество функций, о которых я даже не знаю. Со временем в голове сложилась четкая схема: какие приложения для чего, — и эту модель очень сложно изменить.
У меня нет лояльности к бренду. Есть доверие, что некоторые функции он делает чуть лучше конкурентов. Но это не означает, что я буду пользоваться другими функциями от этого бренда. Нужно, чтобы новая функция была объективно лучше и чтобы я о ней узнал, и сложил свое мнение.
Мы живем в эпоху продуктовой экспансии. Компании множат функции с идеей впихнуть все, что может принести деньги. Команды нацелены на запуск нового, потому что это становится продуктовым приоритетом.
Сосредоточенность на основном продукте уступает место менеджменту функциональных возможностей, нужных меньшинству пользователей. С позиции бизнеса это логично: новые продажи, апсейлы, персонализация, экосистема. Если пользователь зашел в банковское приложение, то почему бы не показать купон от партнера, полезный совет и каталог одежды?
Но так ли хорошо размывать фокус приложения? Превращать небольшое функциональное решение в большое и не всегда полезное?
Так ли опасно остановить функциональную экспансию и вернуться к приложениям, сфокусированным на главном?
Когда я пытаюсь ответить на этот вопрос, вижу много плюсов. Например, можно сократить расходы на разработку дополнительных функций. Реже выпускать обновления. Уменьшить размер приложений. Для меня это критично, потому что смартфон забит, и я вынужден изыскивать 250 мегабайт на установку новой версии банковского приложения ради пяти нужных функций.
Может, пора спрашивать пользователей не «Что добавить?», а «Что убрать?»
В любом приложении остается множество мест для улучшений без перегрузки функциями. Я всегда воодушевлен, когда кто-то создает уместную микроанимацию или делает путь пользователя бесшовным. Именно такие детали создают эмоциональную связь с продуктом.
Мне нравится принцип японских садов каре-сансуи — согласно старой пословице, сад считается завершенным, когда из него ничего нельзя убрать. Может, такая философия не подходит в чистом виде для создания приложений, но она стоит того, чтобы о ней поразмышлять.
Мир стал слишком сложным, и хочется хоть немного стабильности хотя бы в мобильном телефоне. Не хочется мега-апов с рекламными функциями и обязательными акциями. Хочется, чтобы просто работало.
Парадокс раздутых продуктов
В современных приложениях множество функций, о которых я даже не знаю. Со временем в голове сложилась четкая схема: какие приложения для чего, — и эту модель очень сложно изменить.
У меня нет лояльности к бренду. Есть доверие, что некоторые функции он делает чуть лучше конкурентов. Но это не означает, что я буду пользоваться другими функциями от этого бренда. Нужно, чтобы новая функция была объективно лучше и чтобы я о ней узнал, и сложил свое мнение.
Мы живем в эпоху продуктовой экспансии. Компании множат функции с идеей впихнуть все, что может принести деньги. Команды нацелены на запуск нового, потому что это становится продуктовым приоритетом.
Сосредоточенность на основном продукте уступает место менеджменту функциональных возможностей, нужных меньшинству пользователей. С позиции бизнеса это логично: новые продажи, апсейлы, персонализация, экосистема. Если пользователь зашел в банковское приложение, то почему бы не показать купон от партнера, полезный совет и каталог одежды?
Но так ли хорошо размывать фокус приложения? Превращать небольшое функциональное решение в большое и не всегда полезное?
Так ли опасно остановить функциональную экспансию и вернуться к приложениям, сфокусированным на главном?
Когда я пытаюсь ответить на этот вопрос, вижу много плюсов. Например, можно сократить расходы на разработку дополнительных функций. Реже выпускать обновления. Уменьшить размер приложений. Для меня это критично, потому что смартфон забит, и я вынужден изыскивать 250 мегабайт на установку новой версии банковского приложения ради пяти нужных функций.
Может, пора спрашивать пользователей не «Что добавить?», а «Что убрать?»
В любом приложении остается множество мест для улучшений без перегрузки функциями. Я всегда воодушевлен, когда кто-то создает уместную микроанимацию или делает путь пользователя бесшовным. Именно такие детали создают эмоциональную связь с продуктом.
Мне нравится принцип японских садов каре-сансуи — согласно старой пословице, сад считается завершенным, когда из него ничего нельзя убрать. Может, такая философия не подходит в чистом виде для создания приложений, но она стоит того, чтобы о ней поразмышлять.
💯6❤4
СПИК 2019 Money Driven Design.pdf
27.5 MB
Вышел обзор UX-прогнозов 2025 года от Якоба Нильсена. Читая четвертый пункт «Design That Pays», я вспомнил свой доклад 2019 года «Money Driven Design» — о том, что изменения в дизайне можно оценивать через их влияние на денежные показатели.
Тогда меня увлекала идея, что метрики, выраженные в деньгах, понятны всем. Через такие метрики проще разговаривать с менеджментом любого уровня, и они снимают многие блокеры в обсуждении дизайна. И несмотря на сложность подсчета, ими выгодно пользоваться.
Шесть лет назад это был интересный, но маргинальный подход, честно говоря, никто им не увлекся. Сейчас же все чаще пишут, что дизайн должен доказывать эффективность через ROI, LTV, CAC.
По прошествии этих лет я понимаю: тогда я был слишком оптимистичен. Бизнес-среда слишком сложна и изменчива, поэтому наши гипотезы легко могут рассыпаться при столкновении с реальностью. Но на 20% изменений мы точно можем смотреть через эту призму. И когда все находятся в равной степени неопределенности, эта небольшая разница может дать существенное конкурентное преимущество.
Кстати, в вашей практике вас заставляют считать ROI для дизайн-отдела или новых внедрений со стороны дизайна?
Тогда меня увлекала идея, что метрики, выраженные в деньгах, понятны всем. Через такие метрики проще разговаривать с менеджментом любого уровня, и они снимают многие блокеры в обсуждении дизайна. И несмотря на сложность подсчета, ими выгодно пользоваться.
Шесть лет назад это был интересный, но маргинальный подход, честно говоря, никто им не увлекся. Сейчас же все чаще пишут, что дизайн должен доказывать эффективность через ROI, LTV, CAC.
По прошествии этих лет я понимаю: тогда я был слишком оптимистичен. Бизнес-среда слишком сложна и изменчива, поэтому наши гипотезы легко могут рассыпаться при столкновении с реальностью. Но на 20% изменений мы точно можем смотреть через эту призму. И когда все находятся в равной степени неопределенности, эта небольшая разница может дать существенное конкурентное преимущество.
Кстати, в вашей практике вас заставляют считать ROI для дизайн-отдела или новых внедрений со стороны дизайна?
✍2
Media is too big
VIEW IN TELEGRAM
Сегодняшний мой вайбкодинг был больше не про сам проект, а про то, до какого состояния я его довел.
А довел я его до приложения, которое можно скачать и установить на телефон как полноценное. Что, собственно, я и сделал.
Изначально все было собрано в Google AI Studio как проект на Node.js. Потом код был локально развернут в виде сервиса. А дальше я подключил Capacitor, чтобы упаковать локальное приложение в решение, которое можно переносить между платформами. По сути, это веб-приложение, завернутое в оболочку, чтобы его можно было установить на устройство.
Инструкции мне выдавал сам Gemini, а я просто следовал строка за строкой — от переноса из облака на локальную машину до добавления новых файлов.
После этого я установил Android Studio и уже там что-то делал. Всё происходило как в тумане — второй раз без инструкции я это точно не повторю.
Ошибки сборки, конечно, были. Но тут на помощь пришел встроенный агент на базе Gemini: включил магию и просто все починил, чтобы приложение запустилось.
В итоге весь процесс пересборки веб-сервиса на Node в приложение, собранное в APK, вместе с установкой всех необходимых инструментов занял у меня часа четыре. Но за это время я успел и чаю попить, и сериал посмотреть, и пообщаться с ИИ о причинах ошибок и вариантах их решения.
В общем, несмотря на то что приложение очень простое и при переносе с веба на телефон потерялась одна функция, результат всё равно впечатляющий. Я до сих пор не могу привыкнуть к тем возможностям, которые дает современный стек технологий.
Видео на Ютюбе https://youtu.be/jEoX33VuqS0
Приложение http://podluzny.ru/APP/app-release.apk
А довел я его до приложения, которое можно скачать и установить на телефон как полноценное. Что, собственно, я и сделал.
Изначально все было собрано в Google AI Studio как проект на Node.js. Потом код был локально развернут в виде сервиса. А дальше я подключил Capacitor, чтобы упаковать локальное приложение в решение, которое можно переносить между платформами. По сути, это веб-приложение, завернутое в оболочку, чтобы его можно было установить на устройство.
Инструкции мне выдавал сам Gemini, а я просто следовал строка за строкой — от переноса из облака на локальную машину до добавления новых файлов.
После этого я установил Android Studio и уже там что-то делал. Всё происходило как в тумане — второй раз без инструкции я это точно не повторю.
Ошибки сборки, конечно, были. Но тут на помощь пришел встроенный агент на базе Gemini: включил магию и просто все починил, чтобы приложение запустилось.
В итоге весь процесс пересборки веб-сервиса на Node в приложение, собранное в APK, вместе с установкой всех необходимых инструментов занял у меня часа четыре. Но за это время я успел и чаю попить, и сериал посмотреть, и пообщаться с ИИ о причинах ошибок и вариантах их решения.
В общем, несмотря на то что приложение очень простое и при переносе с веба на телефон потерялась одна функция, результат всё равно впечатляющий. Я до сих пор не могу привыкнуть к тем возможностям, которые дает современный стек технологий.
Видео на Ютюбе https://youtu.be/jEoX33VuqS0
Приложение http://podluzny.ru/APP/app-release.apk
❤5🔥1
Вы не одиноки, если в прошедшем году к вам много раз подходили с идеей «геймифицировать что-то». Типично, когда на такой запрос дизайн и разработка отвечают «конечно», и начинается работа. Обычно некогда думать, стоит ли вообще это делать. Да и обычно не спрашивают, потому что идею уже «продали» начальству, а план утвержден.
Поэтому мне очень понравилась статья Sam Liberty «Gamification Does NOT Increase Motivation», где он предлагает более критично подойти к этому вопросу.
Ключевая мысль: геймификация не создает мотивации. Никакие баллы, значки или награды не заставят человека использовать продукт, который ему не нужен.
Сэм не против геймификации, но он за реалистичный подход. К сожалению, в своей работе многие команды выбирают скорость поставки вместо осмысленности в выборе фич. И неудивительно, что в этой ситуации планы по вовлечению проваливаются. Раз за разом мы видим одни и те же успешные кейсы, новых громких историй не появляется, что, скорее всего, говорит о трудности внедрения: делают много, пользы мало.
«Поведение возникает, когда мотивация, возможность и побуждение сходятся в один момент» — звучит просто, но за этим должно стоять глубокое понимание психологии. В зависимости от контекста меняются все переменные. А значит, слепое копирование механик геймификации с проекта на проект практически бессмысленно.
Хорошее правило при выборе фокуса: повысить мотивацию можно только для того, в чем человек уже заинтересован. Если интереса нет — геймифицировать бессмысленно.
Очень рекомендую статью. Она может сэкономить вам сотни часов разработки и помочь сфокусировать команду на действительно полезных вещах вместо модных.
Поэтому мне очень понравилась статья Sam Liberty «Gamification Does NOT Increase Motivation», где он предлагает более критично подойти к этому вопросу.
Ключевая мысль: геймификация не создает мотивации. Никакие баллы, значки или награды не заставят человека использовать продукт, который ему не нужен.
Сэм не против геймификации, но он за реалистичный подход. К сожалению, в своей работе многие команды выбирают скорость поставки вместо осмысленности в выборе фич. И неудивительно, что в этой ситуации планы по вовлечению проваливаются. Раз за разом мы видим одни и те же успешные кейсы, новых громких историй не появляется, что, скорее всего, говорит о трудности внедрения: делают много, пользы мало.
«Поведение возникает, когда мотивация, возможность и побуждение сходятся в один момент» — звучит просто, но за этим должно стоять глубокое понимание психологии. В зависимости от контекста меняются все переменные. А значит, слепое копирование механик геймификации с проекта на проект практически бессмысленно.
Хорошее правило при выборе фокуса: повысить мотивацию можно только для того, в чем человек уже заинтересован. Если интереса нет — геймифицировать бессмысленно.
Очень рекомендую статью. Она может сэкономить вам сотни часов разработки и помочь сфокусировать команду на действительно полезных вещах вместо модных.
❤3🤝3
Всех с наступающим Новым годом!
Прошедший был непростым, следующий, кажется, будет ещё сложнее. У Хармса есть хорошая фраза: "Жизнь всегда побеждает смерть неизвестным науке способом". И она мне нравится своим непробиваемым оптимизмом. Не знаю, какие неприятности ещё ждут впереди, но уверен, что куда важнее люди, которые окажутся вокруг, чем события. Надо ценить, любить, поддерживать тех, кто нас окружает. Сам стараюсь в меру скромных сил и всем этого желаю.
Прошедший был непростым, следующий, кажется, будет ещё сложнее. У Хармса есть хорошая фраза: "Жизнь всегда побеждает смерть неизвестным науке способом". И она мне нравится своим непробиваемым оптимизмом. Не знаю, какие неприятности ещё ждут впереди, но уверен, что куда важнее люди, которые окажутся вокруг, чем события. Надо ценить, любить, поддерживать тех, кто нас окружает. Сам стараюсь в меру скромных сил и всем этого желаю.
🎄8❤3☃3
Недавно наткнулся на статью Jeffrey Anthony «You've Been Listening to AI Music for 25 Years: You Just Didn't Know It» — и она дала мне повод для размышления, как о современной музыке, так и том, какой мир человек конструирует вокруг себя.
Jeffrey Anthony показывает, что музыка последние двадцать лет все больше подчиняется алгоритмическим правилам. Программы уже давно позволяют исправить все недочеты. И может уже не так важно, написана музыка Suno или человеком, если постобработка доводит ее до «безошибочности».
Шаг за шагом мы строим мир совершенства, сами того не замечая. Является ли это дорогой в счастливое будущее или путем к саморазрушению? Надо бы прожить лет 150 и узнать ответ на этот вопрос.
Jeffrey Anthony показывает, что музыка последние двадцать лет все больше подчиняется алгоритмическим правилам. Программы уже давно позволяют исправить все недочеты. И может уже не так важно, написана музыка Suno или человеком, если постобработка доводит ее до «безошибочности».
Шаг за шагом мы строим мир совершенства, сами того не замечая. Является ли это дорогой в счастливое будущее или путем к саморазрушению? Надо бы прожить лет 150 и узнать ответ на этот вопрос.
❤1👍1
Channel name was changed to «UX Point — канал Дмитрия Подлужного»
Недавно я рассказывал, как ИИ создает интерфейсы, которые могут стоить пользователю дней и даже недель напрасно потерянного времени за счет неудачных UX решений.
Если помните, то я приводил пример своего вайб-проекта по сбору ответов от разных ИИ моделей, и в этом интерфейсе добавление управления с клавиатуры потенциально экономило пользователю до 15 рабочих дней в год, против решения, которого было по умолчанию предложено и собрано v0 на базе Anthropic Claude. В тот раз для оценки потерь я ссылался на метод GOMS. Хоть метод старый, но я уверен, что не все с ним хорошо знакомы. Поэтому рекомендую статью Trevor Calabro «GOMS-KLM: Calculating Time-on-Task» .
Пусть вас не смущает, что я называл метод GOMS, а в статье он называется GOMS-KLM. Это я упрощал название, чтобы было проще.
Если этой статьи будет мало, то можете посмотреть мою статью «Количественные метрики на базе GOMS» . В ней в качестве бонуса есть ссылка на шаблон в Гугл Таблицах на таблицу со встроенным скриптом для более простого расчета метрики. У меня расчет делается чуть иначе, чем предлагает Тревор в своем варианте, так что можно посмотреть оба варианта и выбрать то, что вам будет удобнее.
Если кто-то использует GOMS (или его варианты) в своей практике, поделитесь опытом и впечатлением об эффективности этого метода сейчас.
Если помните, то я приводил пример своего вайб-проекта по сбору ответов от разных ИИ моделей, и в этом интерфейсе добавление управления с клавиатуры потенциально экономило пользователю до 15 рабочих дней в год, против решения, которого было по умолчанию предложено и собрано v0 на базе Anthropic Claude. В тот раз для оценки потерь я ссылался на метод GOMS. Хоть метод старый, но я уверен, что не все с ним хорошо знакомы. Поэтому рекомендую статью Trevor Calabro «GOMS-KLM: Calculating Time-on-Task» .
Пусть вас не смущает, что я называл метод GOMS, а в статье он называется GOMS-KLM. Это я упрощал название, чтобы было проще.
Если этой статьи будет мало, то можете посмотреть мою статью «Количественные метрики на базе GOMS» . В ней в качестве бонуса есть ссылка на шаблон в Гугл Таблицах на таблицу со встроенным скриптом для более простого расчета метрики. У меня расчет делается чуть иначе, чем предлагает Тревор в своем варианте, так что можно посмотреть оба варианта и выбрать то, что вам будет удобнее.
Если кто-то использует GOMS (или его варианты) в своей практике, поделитесь опытом и впечатлением об эффективности этого метода сейчас.
❤5
ADPList традиционно выдает мне бейдж одного из лучших менторов по клиенскому опыту. Спасибо за это. https://adplist.org/community-certifications/top100-dec-2025-customer-experience-cx-8a7a50
🔥3🎄1
This media is not supported in your browser
VIEW IN TELEGRAM
Про нижнее меню на сайтах сегодня решил написать после того, как натолкнулся на свою концепцию трехлетней давности.
Это вариант для сайта страховой, когда на главной странице внизу можно использовать дополнительное меню действия, такой вариант Floating Action Button.
Основная идея была: упростить навигацию для лояльных пользователей, а за счет наглядности снизить когнитивную нагрузку. Я исходил из пользовательского поведения: на сайты страховых компаний люди заходят редко и надо помочь клиентам сделать нужные шаги, чуть-чуть сместив объем информации на странице в пользу клиентов.
Когда я это делал, то столкнулся с проблемой, что хотя в сети мобильных пользователей больше, чем десктопных, но обоснованных подходов, как сделать мобильную навигацию нет.
Выбор был между тем, чтобы смещать навигацию вниз и делать ее полностью нижней, оставлять полностью вверху, найти компромисс между двумя вариантами.
Было несколько исследований, которые показывали, что использование свернутой навигации создает более плохой пользовательский опыт. Например, статья «Hamburger Menus and Hidden Navigation Hurt UX Metrics» напрямую указывает, что по результату проведенных в лаборатории исследований скрытая навигация (в бургер) приводит к усложнению выполнения задач, увеличению времени выполнения и т.д.
Но если мы посмотрим на рекомендации Google (Material Design) и Apple (Human Interface Guidelines) , то мы не найдем там отдельных рекомендаций для навигации по сайтам. Там есть рекомендации по использовании нижней навигации в мобильных приложениях. При этом там можно обратить внимание на такие моменты: ограниченное количество пунктов 3-5, равнозначность разделов, использование панели для навигации, а не для выполнения действий. И эти рекомендации хорошо ложатся на логику приложений с ограниченным ясным функционалом, чего не скажешь про сайты.
Хотя аргумент - сделаем как в приложении, мне приходилось слышать чаще всего. Как правило, те, кто делает такие предложения, не рассматривают аудиторию на сайте и в приложении, как разную, что довольно наивно.
Если посмотреть на Google Store, Apple, Amazon, Facebook и т.д., то эти компании не переносили на сайтах меню вниз, хотя в приложениях его используют. Для таких сайтов изменение даже на 1% это миллионы долларов, и я предполагаю, что такие компании точно должны были протестировать идею сделать навигацию, как в приложении. И раз до сих пор не сделали, то скорее всего это мешает продажам и другим важным метрикам.
Правда на это всегда есть Озон, Яндекс Маркет, Алиэкспресс и т.д., у которых на сайте все как в приложении. И почему-то я убежден что такое решение, основано не на исследованиях, а на волюнтаристском решении дизайн-директора или CEO этих компаний.
У меня был подобный опыт. В проекте для большого российского ecom с MAU в несколько миллионов, для которого я делал проектирование, я предлагал в мобильной версии сайта делать верхнюю навигацию, но компания решила сделать, как в приложении, и продавила себе нижний тулбар. После запуска новой версии сайта все показатели просели. Это невозможно объяснить только изменением навигации, но и она, на мой взгляд, приложила к этому руку. Все что непривычно - роняет поведенческие метрики. И пока для массового пользователя нижняя навигация на сайтах непривычна.
И если у вас есть свежие исследования про нижнюю навигацию на сайтах, то поделитесь пожалуйста.
Это вариант для сайта страховой, когда на главной странице внизу можно использовать дополнительное меню действия, такой вариант Floating Action Button.
Основная идея была: упростить навигацию для лояльных пользователей, а за счет наглядности снизить когнитивную нагрузку. Я исходил из пользовательского поведения: на сайты страховых компаний люди заходят редко и надо помочь клиентам сделать нужные шаги, чуть-чуть сместив объем информации на странице в пользу клиентов.
Когда я это делал, то столкнулся с проблемой, что хотя в сети мобильных пользователей больше, чем десктопных, но обоснованных подходов, как сделать мобильную навигацию нет.
Выбор был между тем, чтобы смещать навигацию вниз и делать ее полностью нижней, оставлять полностью вверху, найти компромисс между двумя вариантами.
Было несколько исследований, которые показывали, что использование свернутой навигации создает более плохой пользовательский опыт. Например, статья «Hamburger Menus and Hidden Navigation Hurt UX Metrics» напрямую указывает, что по результату проведенных в лаборатории исследований скрытая навигация (в бургер) приводит к усложнению выполнения задач, увеличению времени выполнения и т.д.
Но если мы посмотрим на рекомендации Google (Material Design) и Apple (Human Interface Guidelines) , то мы не найдем там отдельных рекомендаций для навигации по сайтам. Там есть рекомендации по использовании нижней навигации в мобильных приложениях. При этом там можно обратить внимание на такие моменты: ограниченное количество пунктов 3-5, равнозначность разделов, использование панели для навигации, а не для выполнения действий. И эти рекомендации хорошо ложатся на логику приложений с ограниченным ясным функционалом, чего не скажешь про сайты.
Хотя аргумент - сделаем как в приложении, мне приходилось слышать чаще всего. Как правило, те, кто делает такие предложения, не рассматривают аудиторию на сайте и в приложении, как разную, что довольно наивно.
Если посмотреть на Google Store, Apple, Amazon, Facebook и т.д., то эти компании не переносили на сайтах меню вниз, хотя в приложениях его используют. Для таких сайтов изменение даже на 1% это миллионы долларов, и я предполагаю, что такие компании точно должны были протестировать идею сделать навигацию, как в приложении. И раз до сих пор не сделали, то скорее всего это мешает продажам и другим важным метрикам.
Правда на это всегда есть Озон, Яндекс Маркет, Алиэкспресс и т.д., у которых на сайте все как в приложении. И почему-то я убежден что такое решение, основано не на исследованиях, а на волюнтаристском решении дизайн-директора или CEO этих компаний.
У меня был подобный опыт. В проекте для большого российского ecom с MAU в несколько миллионов, для которого я делал проектирование, я предлагал в мобильной версии сайта делать верхнюю навигацию, но компания решила сделать, как в приложении, и продавила себе нижний тулбар. После запуска новой версии сайта все показатели просели. Это невозможно объяснить только изменением навигации, но и она, на мой взгляд, приложила к этому руку. Все что непривычно - роняет поведенческие метрики. И пока для массового пользователя нижняя навигация на сайтах непривычна.
И если у вас есть свежие исследования про нижнюю навигацию на сайтах, то поделитесь пожалуйста.
👍1
В проектировании интерфейсов фокус-группа не всегда такая, как в маркетинговых исследованиях. Недавно наткнулся на статью в UX Magazine про использование юзабилити-тестов и фокус-групп — «Usability Tests vs. Focus Groups» , и это напомнило мне опыт использования фокус-группы в B2B-проекте для Mercedes-Benz Rus.
На мой взгляд, работа с фокус-группой — это эффективный инструмент в B2B-проектах или проектах, где в качестве конечных пользователей выступают руководители высокого уровня. Хотя бы потому, что ее проще организовать, особенно когда сам бизнес-заказчик заинтересован в хорошем результате проекта.
В 2018 году я проектировал интерфейс внутренних систем для Mercedes-Benz Rus. Это должен был быть набор инструментов, к которому получали доступ как сотрудники компании, так и дилеры. Причем подразумевался разный уровень доступа для разных должностей.
С одной стороны, было очевидно, что нужно вовлекать пользователей в проект, но CEO компаний не очень охотно идут на контакт. У всех нет времени, желания общаться, тем более с какими-то там UX-дизайнерами. Но вот приехать в офис Mercedes и поучаствовать во встрече, посвященной будущей системе, которую они потом будут использовать, — это совсем другое дело.
Но чтобы провести встречу с пользой, нужно что-то показывать. Люди обычно не способны представить будущую систему и качественно о ней рассуждать, но они гораздо лучше включаются в разговор, когда им что-то демонстрируют.
Для такой встречи нужно уже иметь готовый прототип с высокой степенью функциональности. Но, как ни странно, лучше отказаться от идеи показывать проект в дизайне. Когда люди видят дизайн, у них отключается критическое мышление. И хотя демонстрация прототипов с условными элементами не так эффектна, но она позволяет получить более качественное обсуждение проекта.
А чтобы разговор был управляемым, нужен опытный модератор. Важно, чтобы у всех была возможность высказаться. Потому что самое ценное в таком общении — это сами люди. Важно их мнение и возможность задавать им вопросы. Как правило, при живом обсуждении, когда участники действительно включены в процесс, можно получить куда больше ценной информации, чем в рамках формального разговора.
Пара итоговых советов по проведению фокус-группы для обсуждения концепции B2B-проекта:
— Подготовить прототип, достаточно детализированный и интерактивный, чтобы можно было обсуждать ключевые идеи. Не стоит пытаться охватить весь проект, лучше сосредоточиться именно на самом важном.
— Пригласить представителей целевой аудитории среди компаний-партнеров и за счет силы бренда обеспечить вовлеченный диалог. Важно, чтобы участники действительно относились к той аудитории, для которой делается проект.
— Нужен модератор, который сможет управлять процессом: вовлечет всех в разговор и не даст кому-то перетягивать одеяло на себя.
— Задать хорошие вопросы и дать возможность всем высказаться.
Не уверен, насколько этот подход масштабируется на B2B проекты без сильного бренда-заказчика. Но в ситуации, когда проблемен доступ к пользователям, фокус-группа может оказаться хорошим работающим инструментом.
На мой взгляд, работа с фокус-группой — это эффективный инструмент в B2B-проектах или проектах, где в качестве конечных пользователей выступают руководители высокого уровня. Хотя бы потому, что ее проще организовать, особенно когда сам бизнес-заказчик заинтересован в хорошем результате проекта.
В 2018 году я проектировал интерфейс внутренних систем для Mercedes-Benz Rus. Это должен был быть набор инструментов, к которому получали доступ как сотрудники компании, так и дилеры. Причем подразумевался разный уровень доступа для разных должностей.
С одной стороны, было очевидно, что нужно вовлекать пользователей в проект, но CEO компаний не очень охотно идут на контакт. У всех нет времени, желания общаться, тем более с какими-то там UX-дизайнерами. Но вот приехать в офис Mercedes и поучаствовать во встрече, посвященной будущей системе, которую они потом будут использовать, — это совсем другое дело.
Но чтобы провести встречу с пользой, нужно что-то показывать. Люди обычно не способны представить будущую систему и качественно о ней рассуждать, но они гораздо лучше включаются в разговор, когда им что-то демонстрируют.
Для такой встречи нужно уже иметь готовый прототип с высокой степенью функциональности. Но, как ни странно, лучше отказаться от идеи показывать проект в дизайне. Когда люди видят дизайн, у них отключается критическое мышление. И хотя демонстрация прототипов с условными элементами не так эффектна, но она позволяет получить более качественное обсуждение проекта.
А чтобы разговор был управляемым, нужен опытный модератор. Важно, чтобы у всех была возможность высказаться. Потому что самое ценное в таком общении — это сами люди. Важно их мнение и возможность задавать им вопросы. Как правило, при живом обсуждении, когда участники действительно включены в процесс, можно получить куда больше ценной информации, чем в рамках формального разговора.
Пара итоговых советов по проведению фокус-группы для обсуждения концепции B2B-проекта:
— Подготовить прототип, достаточно детализированный и интерактивный, чтобы можно было обсуждать ключевые идеи. Не стоит пытаться охватить весь проект, лучше сосредоточиться именно на самом важном.
— Пригласить представителей целевой аудитории среди компаний-партнеров и за счет силы бренда обеспечить вовлеченный диалог. Важно, чтобы участники действительно относились к той аудитории, для которой делается проект.
— Нужен модератор, который сможет управлять процессом: вовлечет всех в разговор и не даст кому-то перетягивать одеяло на себя.
— Задать хорошие вопросы и дать возможность всем высказаться.
Не уверен, насколько этот подход масштабируется на B2B проекты без сильного бренда-заказчика. Но в ситуации, когда проблемен доступ к пользователям, фокус-группа может оказаться хорошим работающим инструментом.
This media is not supported in your browser
VIEW IN TELEGRAM
Прототипы интерфейсов я делаю так давно, что первые из них собирал ещё в InDesign — старички могут всплакнуть, вспомнив это далекое время. И на протяжении всего этого пути я придерживался идеи, которую настойчиво транслировал вокруг себя, что хороший прототип должен быть черно-белым или, в крайнем случае, монохромным.
Цвет же я использовал как маркер, чтобы сделать кликабельные элементы в прототипах заметнее. И такого подхода было достаточно и для больших, и для маленьких корпоративных заказчиков. В конечном счёте, такие же рекомендации можно найти у Microsoft, IBM, NNgroup и других.
Время от времени возникала необходимость объяснять, зачем прототипы именно такие и почему мы не делаем сразу дизайн. Но в целом это не вызывало особых сложностей. Был общий консенсус, что все заинтересованы в качестве, а обсуждать упрощенный прототип без цвета и изображений по существу гораздо эффективнее, чем делать это на уровне дизайна.
Но в последние годы, наверное, уже года три, мне всё чаще приходится делать прототипы в цвете. И они всё больше начинают походить на дизайнерские решения. Причем в определенной степени сейчас это мой осознанный выбор. Размышляя о коммуникации с заказчиком, мне приходится признавать, что теперь эффективнее показать что-то с визуальным решением, чем монохромный вариант.
Для себя я объясняю это тем, что по какой-то неведомой космической причине корпоративные заказчики все реже считают итерационный подход хорошим и правильным. И все чаще склонны думать, что проект возникает сразу — целиком и полностью, во всей визуализации.
Желание критически относиться к дизайну, обсуждать прототип, искать лучшее решение становится все более редким явлением. Нужно либо сделать сразу «хорошо», с тем самым вау-эффектом, либо попасть в ожидаемое решение. И уже не так важно, будет ли это решение по верхней границе ожиданий или по нижней.
Вполне возможно, что мой опыт работы в агентстве накладывает отпечаток на такое восприятие.
Мне трудно точно определить причину, почему так происходит или почему это именно так ощущается. Но в качестве ответной реакции возникает чувство необходимости делать что-то похожее на дизайн. Проще всего это делать, когда есть дизайн-система, в такой ситуации можно хотя бы частично наследовать элементы. Сложнее, когда нет почти ничего.
В результате получаются вот такие high-detail прототипы, как в примере. Это был небольшой кусочек решения для B2B системы лояльности.
Вы замечаете, что клиенты стали по-другому относиться к итерационности? Или у вас все еще работают классические монохромные прототипы?
Цвет же я использовал как маркер, чтобы сделать кликабельные элементы в прототипах заметнее. И такого подхода было достаточно и для больших, и для маленьких корпоративных заказчиков. В конечном счёте, такие же рекомендации можно найти у Microsoft, IBM, NNgroup и других.
Время от времени возникала необходимость объяснять, зачем прототипы именно такие и почему мы не делаем сразу дизайн. Но в целом это не вызывало особых сложностей. Был общий консенсус, что все заинтересованы в качестве, а обсуждать упрощенный прототип без цвета и изображений по существу гораздо эффективнее, чем делать это на уровне дизайна.
Но в последние годы, наверное, уже года три, мне всё чаще приходится делать прототипы в цвете. И они всё больше начинают походить на дизайнерские решения. Причем в определенной степени сейчас это мой осознанный выбор. Размышляя о коммуникации с заказчиком, мне приходится признавать, что теперь эффективнее показать что-то с визуальным решением, чем монохромный вариант.
Для себя я объясняю это тем, что по какой-то неведомой космической причине корпоративные заказчики все реже считают итерационный подход хорошим и правильным. И все чаще склонны думать, что проект возникает сразу — целиком и полностью, во всей визуализации.
Желание критически относиться к дизайну, обсуждать прототип, искать лучшее решение становится все более редким явлением. Нужно либо сделать сразу «хорошо», с тем самым вау-эффектом, либо попасть в ожидаемое решение. И уже не так важно, будет ли это решение по верхней границе ожиданий или по нижней.
Вполне возможно, что мой опыт работы в агентстве накладывает отпечаток на такое восприятие.
Мне трудно точно определить причину, почему так происходит или почему это именно так ощущается. Но в качестве ответной реакции возникает чувство необходимости делать что-то похожее на дизайн. Проще всего это делать, когда есть дизайн-система, в такой ситуации можно хотя бы частично наследовать элементы. Сложнее, когда нет почти ничего.
В результате получаются вот такие high-detail прототипы, как в примере. Это был небольшой кусочек решения для B2B системы лояльности.
Вы замечаете, что клиенты стали по-другому относиться к итерационности? Или у вас все еще работают классические монохромные прототипы?
💅2