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

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

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

Тарифы на сайте билайна
Тарифы на сайте билайна

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

0. Как работает дизайнер

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

Исходный файл с требованиями может быть большой
Исходный файл с требованиями может быть большой

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

Часть макетов для редизайна раздела тарифов 2019
Часть макетов для редизайна раздела тарифов 2019

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

1. Про юзабилити-исследования

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

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

График зависимости процента выявленных проблем от количества респондентов
График зависимости процента выявленных проблем от количества респондентов

2. ∞ решений

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

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

Респонденты переставали скроллить, достигая пунктирной линии 
Респонденты переставали скроллить, достигая пунктирной линии 

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

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

Выбрать единственный вариант из бесконечности и убедить всех, что он лучший

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

3. Про АБ-тесты

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

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

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

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

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

Не так важны клики по кнопке заказа, как количество выкупленных заказов

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

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

Какой вариант будет работать лучше?
Какой вариант будет работать лучше?

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

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

4. Дизайн-система

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

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

Фрагмент Сторибука с компонентами
Фрагмент Сторибука с компонентами

5. Дизайн-ревью

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

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

Начало одного из дизайн-ревью тарифов
Начало одного из дизайн-ревью тарифов

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

Так можно поделить страницу на блоки
Так можно поделить страницу на блоки

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

6. Теория близости

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

Объекты, расположенные рядом, кажутся связанными

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

Строки слиплись
Строки слиплись

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

Строки развалились
Строки развалились

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

А тут всё более-менее
А тут всё более-менее

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

7. Редактура и текст

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

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

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

Переносим предлоги на следующую строку
Переносим предлоги на следующую строку

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

 

Дефисы и тире

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

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

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

–

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

—

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

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

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

Вот и всё

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

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

55
14 комментариев

В билайне, где я работал ведущим дизайнеромТак это ты тот #%*&##% из-за которого любой заход на сайт Билайна собровождается непроизвольной матерщиной буквально на каждом шаге.
Я тебя ненавижу. И твоего сменщика тоже.

3
Ответить

вот вы и встретились)))

4
Ответить

Возможно это был я) Надеюсь сменщик будет повнимательнее

Ответить

Какой вариант будет работать лучше?

Ну, какой же?

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

Дядя, почему ты такой мудак?

1
Ответить

Удалил ссылку на видел, там действительно ответа нет. А какой вы думаете?

Ответить

У вас для A/B тестов свой самописный движок или вы сервис какой-либо используете?

1
Ответить

Движок свой, аналитика только чужая

Ответить