Как мы принимаем и защищаем решения в дизайне сайта

Как мы принимаем и защищаем решения в дизайне сайта

Почему этот блок находится здесь?

Почему кнопка именно такого размера?

Почему на первом экране нет ещё пяти преимуществ?

Почему на мобильной версии элементы расположены иначе?

И почему нельзя просто сделать так, как попросил заказчик?

Для нас хороший дизайн сайта начинается не с ответа:

«Потому что так красиво».

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

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

Именно поэтому мы не просто показываем макет.

Мы его защищаем.

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

Защита решения для нас — это диалог, в котором у каждой существенной идеи должна быть причина.

{здесь вставить изображение: «Бизнес-задача → пользовательский сценарий → решение → целевое действие»}

Весь процесс разработки сайта — от интервью до запуска — мы описали отдельно в статье «Как мы работаем над сайтом: от интервью до запуска».
{ссылка на /blog/kak-my-rabotaem-nad-sajtom}

Дизайн начинается не с дизайна

Когда мы заканчиваем исследовательский этап, мы не переходим сразу к полноценному визуальному макету.

Сначала делаем концепт.

В нашем процессе это чёрно-белый прототип, в котором уже проработаны:

• структура;
• расположение секций;
• CTA;
• пользовательские сценарии;
• CJM для отдельных сегментов аудитории.

То есть сначала появляется логика будущего сайта.

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

Что пользователь должен увидеть?

В какой последовательности?

Какие вопросы нужно закрыть до целевого действия?

Как разные сегменты аудитории будут двигаться по сайту?

Для нас это важнее, чем начинать проект с выбора оттенка синего.

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

{здесь вставить изображение: пример ч/б прототипа с подписями «CJM», «CTA», «возражение», «целевое действие»}

Почему до этого этапа мы предпочитаем интервью универсальным анкетам и жёсткому техническому заданию, разбираем в статье «Почему мы не используем брифы и жёсткое ТЗ для разработки сайта».
{ссылка на /blog/pochemu-my-ne-ispolzuem-brify-i-zhestkoe-tz}

Сначала задача, потом конкретное дизайнерское решение

Представим ситуацию.

Заказчик смотрит макет и говорит:

«Сделайте эту кнопку больше и красной».

Самый простой вариант — открыть Figma и сделать её больше и красной.

Но мы сначала спросим:

«Зачем?»

Допустим, ответ:

«Мне кажется, пользователь её не заметит».

Теперь есть задача, с которой можно работать.

Заказчика беспокоит не конкретный размер кнопки.

Его беспокоит заметность целевого действия.

И дальше мы уже можем обсуждать, действительно ли проблема существует и каким способом её лучше решить.

Возможно, кнопку действительно нужно увеличить.

Возможно, проблема в расположении.

Возможно, вокруг слишком много визуального шума.

Возможно, нужно иначе выстроить секцию.

То есть мы стараемся отделить наблюдаемую проблему от готового способа её решения.

Для нас это одна из ключевых частей работы студии.

Клиент не обязан самостоятельно проектировать интерфейс.

Он может сказать:

«Здесь непонятно».

«Я бы не понял, куда нажимать».

«Наши клиенты прежде всего спрашивают цену».

«Этот блок неправильно описывает наш продукт».

Все эти замечания дают нам информацию о проблеме.

А уже наша задача — предложить способ её решить.

Иногда такой разговор напоминает метод Сократа

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

Например:

— Сделайте кнопку больше.

— Зачем?

— Чтобы её было лучше видно.

— Сейчас она недостаточно заметна?

— Да.

— Что именно заставляет так думать?

И дальше разговор постепенно переходит с размера элемента на реальную задачу интерфейса.

Мы не используем вопросы ради спора.

И не пытаемся заставить заказчика признать, что он неправ.

Цель — понять, что именно человек хочет улучшить.

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

«Сделайте больше» может означать:

«Я не вижу целевого действия».

«Добавьте текст» — «мне кажется, клиенту недостаточно информации».

«Перенесите этот блок наверх» — «для нашей аудитории это главный аргумент при покупке».

Если сразу выполнить инструкцию, можно исправить симптом и не решить исходную задачу.

Мы не считаем «мне не нравится» запрещённой обратной связью

Дизайн нельзя полностью отделить от субъективного восприятия.

Поэтому фраза:

«Мне не нравится»

сама по себе не является чем-то недопустимым.

Для нас важнее понять контекст.

Что именно не нравится?

Почему?

На каком этапе проекта это прозвучало?

Это отдельный элемент или вся концепция?

Изменение затрагивает один экран или требует переработки уже согласованных решений?

Есть большая разница между замечанием на этапе концепта и предложением полностью изменить направление в конце разработки.

Поэтому субъективную обратную связь мы не запрещаем и не высмеиваем.

Мы просто стараемся превратить её в более полезный разговор.

Например:

«Что именно здесь вызывает сомнение?»

«Вы считаете это решение неподходящим для ваших клиентов или оно не нравится лично вам?»

«Какую проблему вы хотите исправить?»

Чем точнее сформулирована причина, тем выше шанс найти хороший вариант.

«Я показал жене, ей не понравился синий»

Есть и другая крайность.

Представим аргумент:

«Я посоветовался с женой, она сказала, что синий будет смотреться некрасиво».

Такую обратную связь мы можем услышать.

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

И дело не в том, что мнение жены собственника «неправильное».

Проблема в другом.

Сайт создаётся не для неё.

Как и не для нас.

И даже не для самого собственника бизнеса.

Он создаётся для клиентов компании.

Поэтому главное для нас — не вопрос:

«Всем ли нравится этот синий?»

А вопрос:

«Работает ли решение для аудитории и задачи проекта?»

Если за субъективной реакцией находится реальная проблема — разбираем её.

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

Чем мы вообще можем обосновать дизайн

Мы не считаем, что каждую дизайнерскую идею можно доказать формулой.

Но у существенных решений должна быть аргументация.

В работе мы опираемся на:

• UX-принципы;
• конкурентный анализ;
• доступную веб-аналитику;
• собственный опыт.

Иногда используем известные нам исследования, если они напрямую относятся к решению.

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

При этом исследование само по себе не является для нас магической печатью:

«Так правильно всегда».

Любое решение нужно рассматривать в контексте конкретного проекта.

Поэтому общий принцип выглядит скорее так:

задача → доступные данные и контекст → решение → объяснение.

Не:

«Так сейчас модно».

И не:

«Нам просто так больше нравится».

Мы анализируем конкурентов, но не копируем их

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

Это помогает понять контекст рынка.

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

Анализ нужен, чтобы разобраться:

• какие аргументы уже используются в нише;
• как компании объясняют продукт;
• как строят путь пользователя;
• где повторяются одни и те же решения;
• какие потенциальные проблемы можно увидеть.

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

То есть конкурентный анализ для нас — источник контекста, а не каталог готовых макетов.

Главная граница: клиент знает свой бизнес лучше нас

Есть очень важное ограничение нашей экспертности.

Мы не работаем в компании заказчика годами.

Не разговариваем каждый день с его клиентами.

Не знаем всех внутренних процессов.

Не прожили историю продукта.

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

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

Собственник говорит:

«Нет. Наши клиенты делают наоборот».

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

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

Такие ситуации у нас были.

Нас могли остановить прямо во время объяснения:

«Нет, вы не так поняли».

И после разговора выяснялось, что действительно не так.

Это не поражение дизайнера.

Это нормальная работа над проектом.

Но клиент не обязан лучше нас знать UX и веб-разработку

Обратная сторона той же логики:

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

Поэтому мы стараемся не смешивать две области.

Вопрос:

«Наши клиенты никогда не используют такую терминологию»

— относится к знанию бизнеса и аудитории.

Вопрос:

«Сделайте все кнопки в два раза больше»

— уже относится к конкретной реализации интерфейса.

Первое мы должны воспринимать особенно внимательно.

Второе — обсудить и при необходимости предложить другое решение.

Именно поэтому нормальная работа между студией и заказчиком для нас строится не как отношения:

«заказчик сказал → подрядчик выполнил».

Это сотрудничество людей с разной экспертизой.

Клиент понимает свой бизнес.

Мы понимаем свою профессиональную область.

Хорошее решение появляется на пересечении этих знаний.

Мы защищаем концепцию до тех пор, пока считаем её правильной

Если мы уверены, что предлагаем более сильное решение, наша задача — объяснить его.

Иногда одного комментария достаточно.

Иногда нужно отдельно созвониться.

Иногда разложить логику по пользовательским сценариям.

Иногда вернуться к данным, конкурентам или исходным требованиям.

Мы не хотим отказываться от концепции после первого:

«Давайте сделаем по-другому».

Потому что тогда возникает вопрос: зачем заказчик вообще платит студии за экспертизу?

Если любое наше решение исчезает сразу после первой субъективной правки, никакой защиты концепции фактически нет.

Но защита не должна превращаться и в борьбу за авторство.

Если аргументы клиента сильнее — решение меняется.

А что если мы так и не договорились

Последнее слово остаётся за заказчиком.

Если мы объяснили позицию, показали риски и предложили альтернативы, но клиент всё равно хочет конкретное решение, мы можем его реализовать.

Мы выполним свои обязательства.

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

Это важная граница.

Защищать экспертизу — не значит отбирать у клиента право принимать финальное решение.

В конечном счёте это его бизнес и его продукт.

Наша ответственность — не молчать, если считаем конкретное решение слабым.

Почему нельзя защищать дизайн словами «я дизайнер, мне виднее»

Это такой же слабый аргумент, как:

«Я заказчик, я плачу деньги».

Статус стороны ещё не доказывает правильность конкретного решения.

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

Поэтому мы стараемся объяснять не авторитетом, а логикой.

Например:

«Для этого сегмента сначала нужно закрыть конкретное возражение, поэтому блок находится выше».

Или:

«Здесь CTA появляется после информации, которая необходима пользователю перед следующим действием».

Так решение можно обсуждать.

С аргументом «мне виднее» обсуждать нечего.

Почему мы сначала защищаем чёрно-белый прототип

Это одна из причин, почему концепт у нас появляется до полноценного дизайна.

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

«Нравится цвет».

«Не нравится шрифт».

«А можно побольше фотографию?»

«Давайте здесь что-нибудь ярче».

Но на раннем этапе важнее понять:

правильно ли вообще построена страница.

Поэтому сначала мы работаем с чёрно-белыми блоками.

Есть структура.

Есть содержание.

Есть CTA.

Есть CJM.

Есть сценарий пользователя.

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

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

Правка и пересмотр концепции — разные вещи

После презентации заказчик может предложить изменения.

Это нормально.

Но нужно учитывать масштаб.

Поменять отдельную формулировку — одно.

Изменить палитру — другое.

Переставить несколько секций — третье.

А полностью отказаться от уже согласованной структуры после перехода к следующему этапу — совсем другая задача.

Поэтому мы оцениваем не только сам комментарий, но и его влияние на:

• объём проекта;
• сроки;
• бюджет;
• уже выполненные этапы.

Если изменение не влияет существенно на scope, обычно это обычная правка.

Если появляются новые интеграции, новый функционал или требуется существенная переработка согласованного этапа — это уже изменение требований.

Подробнее эту границу мы разбираем в статье «Правки при разработке сайта: почему мы не просто делаем всё, что просит заказчик».
{ссылка на /blog/pravki-pri-razrabotke-sajta}

Защита решения не заканчивается на презентации

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

Поэтому после дизайна и разработки мы тестируем сайт.

Проверяем:

• адаптивность;
• работу в браузерах;
• формы;
• интеграции;
• пользовательские сценарии;
• accessibility;
• производительность.

Используем ручные проверки и автоматизированные сценарии.

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

То есть не просто проверяем:

«работает ли кнопка?»

Но и:

«понятно ли вообще пользователю, что её нужно нажать?»

Если есть возможность, заказчик также может подключать к проверке свою команду или клиентов.

Подробнее — в статье «Как мы тестируем сайт перед запуском».
{ссылка на /blog/kak-my-testiruem-sajt-pered-zapuskom}

Нам не нужно победить заказчика в споре

Это, пожалуй, главный принцип всей защиты решений.

Цель встречи — не доказать:

«Студия была права».

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

Нам важнее другое ощущение:

«Мою задачу поняли и нашли решение лучше».

Иногда лучше окажется наш вариант.

Иногда — идея клиента.

Иногда после спора появится третье решение, которого изначально не предлагала ни одна сторона.

И последнее зачастую самое ценное.

Потому что тогда диалог действительно улучшил продукт.

Сайт создаётся не для дизайнера и не для собственника

Есть простой ориентир, который помогает возвращать разговор в рабочую плоскость.

Для кого вообще делается сайт?

Не для нашего портфолио.

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

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

Сайт создаётся для бизнеса и его клиентов.

Поэтому при проектировании мы смотрим на:

• оффер;
• UX;
• расположение блоков;
• боли и страхи аудитории;
• возражения;
• сегменты ЦА;
• CJM;
• целевые действия.

Именно через эту призму мы оцениваем большую часть решений.

Не:

«Красиво или некрасиво?»

А:

«Помогает ли это человеку двигаться по нужному сценарию?»

Что в итоге покупает заказчик

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

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

Наша задача — разобраться в его бизнесе, сформировать решение и нести за него профессиональную ответственность.

В том числе:

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

Поэтому заказчик получает не только макеты.

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

Эту позицию подробнее раскрываем в статье «Что на самом деле покупает бизнес, заказывая сайт у студии».
{ссылка на /blog/chto-pokupaet-biznes-zakazyvaya-sajt-u-studii}

Есть задача по сайту? Начнём с понимания бизнеса

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

Нам важнее понять продукт, аудиторию, продажи и задачу сайта.

После этого мы предложим концепцию и объясним, почему считаем её подходящей.

А если вы будете с ней не согласны — обсудим.

Потому что хороший результат для нас — не отсутствие правок и не безусловное согласие заказчика.

Хороший результат — когда у каждого существенного решения есть понятная причина.

{здесь вставить CTA}

Обсудить проект с Sadovnikov.digital

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

[Записаться на интервью]