7 вещей про дизайн в больших компаниях, которые полезно знать разработчику и продакт-оунеру
В больших компаниях часто бывает, что разработка и редактура живёт отдельно от дизайна. Дизайнер нарисовал, согласовал и отдал. Потом заказчик открывает и удивляется — он же вроде не это согласовывал? В процессе разработки продукт стал отличаться от согласованного варианта. И чтобы вернуться к начальному дизайну, приходится в спешке всё переделывать, затягивая сроки.
В билайне, где я работал ведущим дизайнером, несколько лет назад мы начали внедрять улучшения, которые помогли наладить взаимодействие дизайнеров и фронтенд-разработчиков. Оказалось, что время на разработку значительно сокращается, если фронтенд-разработчик внимательно относится к основным правилам дизайна, редактуры и понимает, как устроена работа по созданию макета.
Сначала я немного расскажу про работу дизайнера и про методики проверки макетов.
0. Как работает дизайнер
В большинстве случаев дизайн, который попадает на вёрстку, уже согласован. Было перерыто много страниц бизнес-требований и проведено несколько встреч с заказчиком.
Скорее всего, ещё было много подходов-согласований с арт-директором или лидом дизайнеров. Обычно очень много. Поэтому любая правка на этапе разработки должна быть обсуждена и согласована снова.
Когда у нас есть несколько вариантов ещё не свёрстанного дизайна и мы не понимаем, какой вариант будет лучше работать — мы проводим юзабилити-тесты на кликабельных прототипах.
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:
Более подробно про типографические правила можно прочитать в этой статье.
Вот и всё
Надеюсь, я помог кому-то узнать больше про дизайн, и знакомство с этими небольшими правилами поможет участникам процесса наладить взаимодействие и в целом ускорит процесс разработки продукта.
С удовольствием прочитаю ваши комментарии и примеры из жизни на эту тему
Так это ты тот #%*&##% из-за которого любой заход на сайт Билайна собровождается непроизвольной матерщиной буквально на каждом шаге.
Я тебя ненавижу. И твоего сменщика тоже.
вот вы и встретились)))
Возможно это был я) Надеюсь сменщик будет повнимательнее
Ну, какой же?
Подробнее про этот АБ-тест я рассказал в этом видео на 3 минуте. Про методику АБ-тестов хорошо написано в этой статье.Дядя, почему ты такой мудак?
Удалил ссылку на видел, там действительно ответа нет. А какой вы думаете?
Смотря какие цели
Цель — покупка SIM-карты: заказ доставки или самовывоз
Так ответ-то какой в итоге? :)
У вас для A/B тестов свой самописный движок или вы сервис какой-либо используете?
Движок свой, аналитика только чужая
Билайн - это вечные костыли..
Здравствуйте! Пользуетесь нашими услугами? Есть нарекания? Напишите нам об этом подробно в лс, пожалуйста, с уточнением номера/адреса подключения (если у вас наш домашний интернет).
у меня билайн как вторая резервная сим-карта в телефоне и на неё не приходят смс. как решить?
Напишите нам в личные сообщения номер и полные ФИО на кого оформлен. Мы проверим по какой причине не работают смс.