7 вещей про дизайн в больших компаниях, которые полезно знать разработчику и продакт-оунеру

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

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

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

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

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

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

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

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

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

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

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

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

В тот раз я сделал плавающую кнопку, а серую зону закрасил градиентом от белого, чтобы сгладить разрыв. Но я всё равно не был уверен в этом решении на 100%.

Чтобы быть уверенным на 100%, мы проводим АБ-тесты на уже готовом продукте. Разрабатываем 2 или 3 варианта дизайна одного блока или сценария, которые показываем реальным посетителям исследуемой страницы. А после смотрим, какой вариант сработал лучше.

Главные правила АБ

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

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

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

Возьмём один из наших АBC-тестов

У нас был блок с 3 популярными тарифами на главной странице сайта. Мы сделали 3 варианта дизайна и показывали их разным пользователям (для наглядности я совместил их на одном скриншоте ниже). Попробуйте угадать, при каком варианте количество покупок SIM-карт было наибольшим.

Про методику АБ-тестов хорошо написано в этой статье.

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

Пожалуй, самая главная вещь для эффективной разработки — переход на компоненты, создание дизайн-системы и токенов. Про это написано много хороших статей. Но, разработав дизайн приложения PetSet, могу сказать, что при создании MVP (минимально жизнеспособного продукта) небольшого приложения достаточно использовать набор символов в Figma. А вот в дальнейшем, если приложение выстрелит, можно начинать создавать систему.

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

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

Кажется просто, особенно при наличии компонентов и дизайн-системы. Однако, мне приходилось проводить серии таких ревью, когда количество найденных отличий постепенно уменьшалось и сводилось к 2–3. После третьей итерации, как правило, остаются некритичные отличия, которыми можно заняться потом. Правда, рекомендую следить, чтобы это «потом» всё-же когда-нибудь наступило).

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

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

Чтобы дизайн-ревью, а с ним и разработка, занимали меньше времени, фронтенд-разработчику желательно знать этот простой принцип дизайна:

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

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

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

Почитать про теорию близости подробнее можно у Бюро Горбунова.

Некоторые знания типографики фронтенд-разработчиком могут также сократить время на ревью.

Висячие предлоги

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

Чтобы сделать неразрывный пробел в HTML, можно использовать специальный символ:

Дефисы и тире

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

‐ Дефис. Используется для разделения составных слов: кто-нибудь. Ставится без кода, просто вводом с клавиатуры.

– Короткое тире. Используется для обозначения диапазонов 2024–2028. В HTML:

— Длинное тире — и это оно:

− И менее используемый минус: 2 − 2 = 0:

Более подробно про типографические правила можно прочитать в этой статье.

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

С удовольствием прочитаю ваши комментарии и примеры из жизни на эту тему

Мой беханс