Павел Шерер дописал цикл о функциональной архитектуре: о детальном проектировании и подводных камнях.

— У каждой функции и функционального раздела должно быть уникальное название: конкретное и максимально понятное, чтобы сразу уловить суть, на английском;
— Название функции должно отражать действие. Например: AddUser;
— Функциональные сценарии прорабатываются итеративно: от простых к детализированным, чтобы успевать накопить достаточно данных для глубокой проработки;
— Описать функцию с помощью схем не всегда возможно, иногда поможет только текст;
— Описание должно включать назначение, входные и выходные данные, зависимости (например, confirmPhone нельзя реализовать, пока не заработает sendSMS), пример использования;
— Сюда можно добавить User Stories, Use Cases и всё, что посчитаете нужным;
— Если названия макетов будут соответствовать документации, это упростит жизнь разработчикам. Например, ShoppingCart — корзина, ShoppingCart.empty — её пустое состояние;
— Нужен баланс в уровне проработки. Слишком общая проработка отрывает архитектуру от реальности. Слишком детальная перегружает, усложняет восприятие и развитие;
— Если рано детализировать одну подсистему, не получится учесть нюансы других (которые ещё не проработаны), и работа может отправиться в мусорку;
— Невозможно задизайнить сложную систему, не понимая, как она будет работать. Но нельзя знать всё. Чем раньше вы «обстучите» свои решения об коллег, тем надёжнее они станут;
— Отдельная задача — убедить бизнес не начинать разработку слишком рано, недостаточно проработав проект;
— Будьте готовы в процессе детальных изысканий возвращаться на высокий уровень на существенно его изменять.

#functional_architecture

Ира Моторина написала о формировании тональности голоса продукта с помощью Emotional journey map.

— Простота, полезность и понятность не могут быть особенностью голоса продукта, это общие принципы коммуникации. Кто будет читать сложный, бесполезный и непонятный текст?
— Голос зависит от легаси (визуальный стиль и так далее), аудитории и ценностей (ради чего продукт выбирают);
— Пример ценностей продукта, связанного с безопасностью: спокойствие и своевременность;
— Текст может не отражать все ценности, но не должен им противоречить;
— Уникальный голос повышает узнаваемость продукта;
— Тональность голоса зависит от сценария. Ради основных сценариев люди используют продукт (заказ такси). Второстепенные не обязательны (оценка поездки, оплата бонусами);
— В Bolt на экранах заказа такси текст нейтральный, короткий и безличный, чтобы не отвлекать. На карточках в магазине приложений — эмоциональные глаголы, сильные прилагательные, которые призваны заинтересовать;
— Предложите пользователям выполнить задачи в продукте и оценить свои эмоции (можно предложить варианты из исследования Пола Экмана);
— Эмоции людей должны определять реакцию продукта, не наоборот. Случилось что-то хорошее — радуемся вместе с пользователем, возникли проблемы — проявляем сочувствие;
— Естественный тон голоса повышает вовлечённость, конверсию и удовлетворённость пользователей.

#tov

Илья Бирман написал о чекбоксах.

— Классический вид — квадрат с опциональной галочкой, обозначающей включённость;
— Группу чекбоксов, как и радиогруппу, лучше не располагать в строку, чтобы не путать, к какому квадрату относится подпись;
— Если смысл выключенного чекбокса неочевиден (☑️ Подключить демо-доступ прямо сейчас), лучше использовать радиогруппу с явно названными вариантами (Подключить демо-доступ: 🔘 Прямо сейчас, 🔘 Позже в личном кабинете);
— Для удобства прицеливания кликабельным делают обычно не только чекбокс, но и текстовую подпись. Поэтому лучше не вставлять ссылки в подпись;
— Если ваши чекбоксы действуют мгновенно, без нажатия на кнопку подтверждения, убедитесь, что действия обратимы и что кнопки не запускают процессы (даже обратимые);
— Для мгновенных действий лучше подходит тумблер;
— Чекбокс может управлять группой дочерних чекбоксов: включение родительского включает все дочерние и наоборот;
— У родительского чекбокса может быть дополнительное состояние, когда включена только часть дочерних. Его обозначают точкой или прочерком;
— Тогда нажатие на родительский чекбокс последовательно переключит группу: все включены → все выключены → включены только те, что были включены до нажатия на родительский чекбокс (то есть надо сохранять исходные состояния дочерних чекбоксов).

#checkbox

Роман Шарай написал, как говорить о повышении зарплаты.

— Убедитесь, что полностью справляетесь с основными обязанностями: соблюдение сроков, стабильное качество, хорошая обратная связь от коллег, улучшение пользовательского опыта и метрик;
— Подготовьте список своих инициатив, которые принесли пользу команде, продукту, улучшили процессы и атмосферу;
— Например: проактивные изменения в продукте (предложили редизайн фичи, который увеличил конверсию), внедрение инструментов (стали использовать дизайн-систему, которая увеличила скорость работы команды);
— Улучшение процессов и атмосферы: запуск воркшопов для обмена опытом, наставничество для джунов;
— Всё это собрать можно в виде презентации, документа с кейсами, таблицы прогресса (новые навыки, проекты, влияние на продукт за период);
— Хороший повод для разговора о повышении зарплаты — перформанс-ревью;
— Если его в компании нет, отдельная задача — выбрать подходящее время для разговора;
— Оцените, давно ли вам повышали зарплату, какова рыночная зарплата специалистов вашего уровня, есть ли у компании финансовые возможности;
— Выберите правильный момент. Например, после успешного релиза.

Копия в Виси. #salary

Меган Чан написала о тестировании визуального дизайна.

— Визуал влияет на первичное впечатление от продукта, привлекает внимание, транслирует идентичность бренда, вызывает эмоции;
— Отношенческое (attitudinal) тестирование: покажите дизайн пользователям, а затем узнайте их отношение к увиденному;
— Сделать это можно в рамках 5-секундного теста, тестирования предпочтений, теста первого клика или юзабилити-тестирования;
— Открытое объяснение предпочтений: задайте открытый вопрос о дизайне (почему нравится или не нравится), дополнительно попросите описать увиденное, выбрать более привлекательный вариант;
— Подходит, если вы ничего не знаете об ожиданиях аудитории. Позволяет отсеять субъективные предпочтения (не нравится фиолетовый). Может быть неэффективен в немодерируемых исследованиях (понапишут фигни);
— Открытый выбор слов: попросите перечислить прилагательные, описывающие дизайн. Обработка ответов может быть непростой;
— Закрытый выбор слов: попросите выбрать прилагательные из списка. Проще обработать, но нельзя выявить новые точки зрения. Хорошо в модерируемых исследованиях, так как можно узнать причины выбора того или иного слова;
— Числовая шкала: выберите 3−5 характеристик бренда и попросите оценить, насколько хорошо дизайн их отражает;
— Поведенческое (behavioral) тестирование позволяет оценить визуальный дизайн как часть целостного опыта, который зависит и от контента, и от нюансов взаимодействия. К ним можно отнести айтрекинг и а/б-тестирование.

In English. #visual #user_testing

Денис Зеленых написал о кавычках и тире.

— В русской типографике используют «кавычки-ёлочки» для выделения прямой речи, терминов, условных обозначений, названий произведений. „Кавычки-лапки“ — для выделения внутри кавычек-ёлочек;
— В английской — “quotation marks”. ‘Одиночные кавычки’ — для цитат внутри цитат или выделения специфических терминов;
— Общепринятые названия можно писать без кавычек (Volkswagen);
— В британском английском, наоборот, одинарные кавычки — основные, внутри них используются двойные;
— В русской типографике дефис разделяет части слов и телефонных номеров;
— Длинное тире используют в диалогах, вместо пропущенных слов, для обозначения прямой речи и пауз, между подлежащим и сказуемым, для указания маршрутов (поезд Москва — Санкт-Петербург). Обычно его отделяют пробелами с двух сторон;
— Среднее тире применяют для обозначения интервалов и пробелами не отделяют;
— В американской типографике длинное тире не принято отбивать пробелами;
— Цифровое тире (figure dash) используют как разделитель в выражениях из одних чисел, например, как разделители в телефонных номерах;
— Минус используют в математических выражениях (отбивается пробелами) и для обозначения отрицательных чисел (не отбивается).

#typography

Маргарита Романова написала, что с 11 марта изменится в тарифах Фигмы.

— Вместо Design seat, DevMode seat и FigJam seat с разными уровнями доступа будет 4 роли;
— Full seat — редактирование Figma (c Dev Mode), FigJam, Figma Slides;
— Dev seat — редактирование FigJam, Figma Slides, просмотр Figma (c Dev Mode);
— Collab seat — как Dev seat, но без Dev Mode;
— View seat — просмотр всего, но без Dev Mode;
— Design seat станет Full seat и подорожает: $20 в месяц или $192 в год, $55 в месяц для плана Organization;
— FigJam seat → Collab seat;
— Dev Mode seat → Dev seat и станет доступен на плане Professional;
— Для каждой роли можно настроить режим выдачи доступа: а) ручной, б) автоматический, если оплаченных мест хватает, в) автоматический;
— Если у пользователя есть права Edit в файле или проекте, он может запросить платную роль и без апрува ей пользоваться 3 дня;
— Даже если сразу отозвать случайно выданный доступ сверх оплаченных мест, он попадёт в счёт.

#figma #management

Включать камеру на созвонах или не включать?
Ответ: всегда включать.

Но не всё так просто.
Удаленная работа усложняет коммуникацию, не смотря на множество чатов и скоростной интернет. До сотрудника можно достучатся из любого утюга, но полученное сообщение (две галочки) и понятое – разные вещи. Разговор без видео напоминает звонок по старому проводному телефону, бесконечные повторения вопросов, «я отвлекся», «пропала связь» и тд

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

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

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

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

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

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

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

Дизайнеры любят дизайнить, разработчики программировать, но 80% работа в IT это коммуникация и работа в команде. Нам нужно обсуждать, спорить, убеждать, жаловаться, радоваться, злится вместе, видя эмоции друг друга. Так рождается вовлеченность, симпатия и отношения которые больше митингов по расписанию.

Так рутинные проекты становится интересными и работа кажется не такой скучной. А встреча с коллегами в офлайне намного приятней и не такая неловкая как с кругами с буквами.

Михаил Нежник подготовил гайд по анимации в Фигме.

— Если на экран ведут несколько элементов, можно их выделить и потянуть связь до целевого фрейма. Переход будет настроен для всех выделенных элементов;
— Можно скопировать анимацию (выделить её, нажав слева от названия триггера на панели Interactions, и скопировать) и вставить выделенным элементам;
— Также можно её отредактировать или удалить у всех выделенных элементов;
— Настройка «Sticky, stop at top edge» фиксирует элемент при прокрутке внутри блока, а при достижении границ блока прокручивать его уже вместе со страницей (лучше увидеть);
— Для экшена прокрутки (Scroll to) можно выбрать объект и положительное или отрицательное количество пикселей. Тогда прокрутка остановится на это количество после или до объекта. Не забудьте настроить Overflow для прокручиваемого фрейма;
— Смарт-анимация смотрит, что изменилось на связанных фреймах. Если элемент с одним названием изменил размер или переместился, получится плавный переход между состояниями;
— Ease in — анимация начинается медленно и ускоряется к концу;
— Ease in back — элемент сначала отходит назад (а потом как Ease in);
— Ease out back — анимация начинается быстро, замедляется к концу, элемент пролетает немного дальше точки назначения, но возвращается к ней.

#figma #animation

продуктовые дизайнеры заебали

никаких выводов и нравоучений, просто наблюдения:
1. удивительно, но редкий дизайнер сейчас способен говорить…барабанная дробь…о дизайне. все разговоры только о метриках, исследованиях и дизайн-системах. важные штуки, без сомнения, но они не должны доминировать в сознании дизайнера.
2. мало кто из дизайнеров сейчас способен создавать что-то новое. говорят, что аэродинамическая труба сделала все автомобили одинаковыми, так и продуктовый дизайн, кажется, делает одинаковыми все цифровые продукты. отчасти в этом виноваты корпорации, но ведь и дизайнеры хороши.
3. очень сложно встретить сейчас любопытного дизайнера, как будто это какой-то вымирающий вид. такое ощущение, что грейды и матрицы компетенций целиком и полностью определяют как ребятам работать и развиваться.
4. дизайнеры по какой-то причине считают, что переход в продакты — это рост. для некоторых это действительно так, но для большинства — это новая работа, в которой все предстоит начинать сначала.
5. все стали какими-то чересчур ориентированными на потребности бизнеса. это, может, и неплохо, но за этой ориентированностью часто теряются те, ради кого большинство из нас пришли в профессию — пользователи.

Ваня Соловьёв написал, к чему готовиться дизайнерам, ставшим лидами.

— Часто ими становятся дизайнеры, прекрасно справляющиеся со своими обязанностями. Но управление — совсем другая компетенция;
— Учитесь у менеджеров, читайте книги о менеджменте;
— Бизнесу не важно, как вы выстроите процесс, важно, чтобы команда достигала бизнес-целей;
— Чтобы определиться со стилем управления, прочитайте книгу Ольги Лукиной «Бизнес и/или свобода»;
— «Надзиратель» помогает получить быстрые результаты, но подавляет творческую свободу;
— «Яблочное дерево» подразумевает создание условий для развития дизайнеров. Принципы: самостоятельность важнее контроля (возможность совершить ошибку), аргументы выше авторитета;
— При делегировании важно не убить инициативу, передавая только мелкие или скучные задачи, и не оставлять совсем без контроля, чтобы сохранить качество и выдержать дедлайн;
— И придётся научиться конкретно и достаточно детализировано формулировать задачи;
— Детализация зависит от уровня специалиста. Джунам нужны чёткие инструкции, мидлам достаточно видения решения проблемы, синьорам можно лишь задать ориентиры;
— Попросите дизайнера кратко изложить своё понимание задачи, чтобы избежать недоразумений;
— Критикуйте приватно, хвалите публично;
— Микроменеджмент указывает на то, что что-то пошло не так. Возможно, задача не соответствует уровню дизайнера. Но он допустим в период адаптации;
— Фасилитируйте встречи: придерживайтесь темы встречи, давайте высказаться всем, фиксируйте, что обсуждали и о чём договорились;
— Анализируйте свой опыт и извлекайте уроки из ошибок.

#management

Влад Крят написал об оформлении макетов.

— Отсутствие стандартов усложняет работу с чужими макетами, особенно в большой команде;
— Дизайнеры работают в тёмной и светлой теме примерно поровну, поэтому оптимальный цвет фона рабочей области #6B6B6F;
— Макеты лежат внутри секций, фоновый цвет которых зависит от того, какая тема интерфейса показана в макетах: светлая (#DADAE2) или тёмная (#38373D);
— Секции показывают: 1) happy flow: основной путь только с ключевыми ответвлениями, чем линейнее, тем лучше, 2) дополнительные экраны: ошибки, загрузки, альтернативные состояния экранов;
— На дополнительные экраны можно ссылаться в основном пути;
— Основной путь можно разделить на логические части и показывать их в отдельных секциях;
— Сценарии-микросхемы, где развилки и состояния компактно расположены и связаны сеткой соединительных линий, выглядят круто, но изучать их неудобно;
— Уникальные экраны идут слева направо, их состояния — сверху вниз;
— В нумерации экранов (например, «1.1») первое число — номер уникального экрана, второе — его состояние. Но иногда достаточно лишь названия, например, в наборе экранов с ошибками;
— Соединительные линии выходят из места, с которым пользователь взаимодействует. Если их начало лежит рядом с макетом, место взаимодействия может быть неочевидным;
— Если появляется много пересечений стрелок, значит макеты превращаются в микросхему. Надо декомпозировать;
— Макеты можно сопровождать полезными метками, например: Prod (экран в показанном сценарии уже разработан), Webview, Copyright (требуется редактура);
— Единые правила для расстояний между макетами, блоками с комментариями и так далее помогают воспринимать любой макет быстрее.

#handoff

Игорь Бутков понятно написал для начинающих о стилях, переменных и дизайн-токенах в Фигме.

— Минус стилей: если в большой дизайн-системе надо заменить один цвет на другой, каждый стиль придётся обновлять по отдельности;
— С переменными такой проблемы нет: цвет становится значением переменной (корневого токена), с которой можно связать другие переменные;
— Корневые токены варьируются по цветам и контрастности, например: purple-500;
— С ними могут быть связаны семантические токены — абстрактные названия, указывающие не на сам цвет, а его функцию, например: background.primary;
— Если нужна возможность отдельно настраивать, например, цвета кнопок, можно добавить компонентные токены, например: button.primary.default;
— Минус: таких токенов будет очень много;
— Преимущества абстрактных названий: если вместо button.purple будет button.primary, фиолетовый цвет можно легко заменить на розовый, и логика названий не сломается;
— Для обозначения числового шага используют S, M, L или числа с большим шагом: 100, 200, 300;
— Числа удобны, если размеров много и могут добавляться промежуточные шаги (250 добавить проще и он будет понятнее, чем 2L).

Токены Atlassian. #figma #design_system #color

Влада провалила вайтборд и написала о своих ошибках.

— Время ограничено. Хорошо, если вы умеете быстро въезжать в тему;
— Попробуйте узнать заранее, из какой предметной области будет задача или над чем работает команда, которая вас собеседует;
— Готовясь, можно натренировать выстраивание диалога о задаче. Поговорите со знакомыми дизайнерами об их задачах, как если бы это был вайтборд;
— Ответы на вопросы «Чего хочет бизнес», «Кто ваш пользователь» и «Какие метрики» скорее сбивают, чем помогают найти лучшее решение. Спросите о целях и не уходите глубоко в анализ;
— Решение не должно быть лучшим. В какой-то момент придётся остановиться и выбрать из того, что получилось придумать. Важнее показать навыки коммуникации и рассуждения;
— На случай тупняка заранее подумайте над вопросами, которые будете задавать интервьюеру;
— Есть шаблоны дизайн-процесса для вайтборда (например, генерация идей там может быть отдельным этапом). Но чужие неотработанные на практике подходы будут сбивать, лучше придерживаться своего привычного процесса, адаптировав его под формат вайтборда;
— Примеры задач для вайтборда от компаний вроде Озона и Яндекса.

#career #whiteboard_challenge

Маша Русскова поделилась выводами из исследований текста в интерфейсе.

— За одно посещение веб-страницы люди в среднем успевают прочитать не более 28% слов;
— При средней длине предложения в 14 слов читатели понимают 90% написанного. Наш предел — 25 слов;
— Вопросы в заголовках привлекают больше внимания, чем утверждения (больше CTR). Лучше работают персонализированные вопросы со словами «вы», «ваш». «Оцените главную страницу» → «Как вам главная страница?»;
— Цифры в коммуникациях работают лучше числительных: больше CTR и выше доверие производителям с сомнительной репутацией. «Сдадим квартиру за семь дней» → «Сдадим квартиру за 7 дней»;
— Действительный залог лучше страдательного: люди лучше понимают информацию. «Деньги будут возвращены» → «Мы вернём деньги»;
— Плюс это соответствует тренду новой искренности. В примере выше стало понятно, кто несёт ответственность за возврат.

#writing

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

— Придумывая тестовое, определите, какие задачи (или их типы) надо решать дизайнеру в ближайшее время (например, месяц);
— Составьте список, какие навыки для этого потребуются;
— Тестовое должно помочь эти навыки оценить и при этом вдохновлять на его выполнение;
— Идеально, если его можно выполнить не больше чем за 4 часа (или за 1 час в формате вайтборда);
— Придумайте несколько задач на выбор, чтобы соискатель мог поработать над тем, что больше по душе. Выбор раскроет его предпочтения и профессиональный профиль;
— У задач должно быть множество решений, чтобы можно было показать креативность, способность синтезировать концептуальные решения, выбрать лучшее из возможных;
— Они должны быть интересными (нетиповыми, нелёгкими) и включать возможность трактовки или противоречия. Как дизайнер с этим справится, покажет его уровень;
— Подготовьте критерии оценки (не более 20). Они должны основываться на том, какого подхода, профессиональных качеств и способностей вы ждёте от специалиста, которому надо будет решать определённые в начале задачи;
— Например: даны полные ответы на все вопросы, ни один не проигнорирован (внимательность и фокусировка); решения учитывают цели бизнеса и интересы пользователя (способность работать в сложном контексте);
— Сгруппируйте критерии по компетенциям. Например, критерии понял ли соискатель проблематику, учел ли крайние сценарии, решает ли его предложение задачу относятся к компетенции «Полнота и глубина проработки»;
— Результат выполнения тестового оцените по критериям от 1 до 5 баллов. Когда критериев 20, максимумом будет 100 баллов;
— Больше 80 баллов — отлично, 70–80 — можно доучиться в процессе, меньше 60 — есть риск несоответствия вакансии;
— К каждой оценке меньше 5 баллов добавляйте комментарий;
— Оценки и комментарии показывать соискателям не надо. На встрече расскажите, что понравилось в работе, а затем опишите те моменты, по которым есть комментарии (своими словами, можно более развёрнуто);
— Послушайте ответы, чтобы понять, как соискатель работает с обратной связью — тоже важный навык;
— При оценке в 70–80 баллов подскажите, что прокачать.

#hiring

Илона Арзуманян написала об онбординге новичков в команду.

— Онбординг нужен, чтобы погрузить во все аспекты работы как можно быстрее и не взорвать его мозг;
— Один документ, где всё описано, лучше отдельных ссылок в мессенджере или проговаривания большого объёма информации;
— Включите в него, что нужно сделать в первые дни: ссылки на программы, инструкции по настройке и получению доступов;
— Соберите ссылки на полезные материалы: редполитика, брендбук, гайды по проведению исследований, работе с дизайн-системой;
— Навигация по проектам поможет найти макет или сценарий, когда сотрудник ещё плохо знает принципы хранения макетов;
— Важно донести структуру компании: кто чем занимается в разных командах, к кому с какими вопросами обращаться;
— В каждой компании есть особенности взаимодействия между отделами. Опишите процесс работы от планирования до релиза. По каждому этапу укажите нужные ссылки, файлы, контакты коллег;
— Подробнее опишите этапы работы именно дизайнера: работа в таск-менеджере, получение (обсуждение и уточнение) задачи, исследование и анализ, работа с библиотекой паттернов, графикой, текстом, исследованиями и дизайн-системой, ревью с дизайн-командой, лидом, продактом и бизнес-заказчиками, ревью на соответствие дизайн-системе, передача макетов и дизайн-ревью;
— Также полезно донести, что вы ожидаете от сотрудника в ближайшие 3 месяца, но это больше относится к процессу прохождения испытательного срока.

#management

Три варианта дизайна? Почему не десять?

Одна из самых горячих тем для компаний (как исполнителей, так и заказчиков), работающих с дизайном, — это количество вариантов.

Традиционно в нашей отрасли клиентам предлагают три варианта дизайна. На мой взгляд, это огромная ошибка, тянущаяся из диких времён — 90-х и начала 2000-х. Почему я так думаю?

Во-первых, перебор вариантов — это самый неправильный подход. Это значит, что заказчик не понимает, что хочет. А исполнитель не понимает, что делает. Не очень перспективное сочетание. Сейчас подходы изменились, исследовательская и проектная база проектов позволяет сделать сразу то, что нужно.

Во-вторых, ни одна студия и ни один дизайнер не делает всерьёз три равнозначных варианта. Это надо просто честно признать. Обычно делается один нормальный вариант, второй — так себе, третий — чтобы просто был. Это знают все: и дизайнеры, и менеджеры, и сами клиенты.

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

Как должно быть?

Должен быть последовательный путь к решению. Если клиент хочет несколько вариантов, то они должны быть последовательными. Сделали один — показали, обсудили, поняли, что не так. На основе этой обратной связи — второй. Снова обсудили — третий точно попадет.При такой модели не попасть три раза подряд — практически невозможно.

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

С остальными 20-ю процентами разбираемся индивидуально. Если ошибка на нашей стороне — делаем новый полход за свой счет. Если ошибка на стороне клиента, то новая итерация за счет клиента. 

Реже делаем два варианта силами разных дизайнеров, но на одной платформе. Для каждого из дизайнеров концепт один и он в него вкладывается всерьез. Здесь бывают неожиданные эффекты, иногда клиенты хотят использовать оба направления (для разных направлений бизнеса обычно) и это осложняет проект.

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

Успех не в количестве вариантов, а в продуманном пути к ним.