Как создать дизайн, понятный для пользователя и разработчика
Привет! Меня зовут Ольга, я живу в Днепре и работаю дизайнером последние 6 лет, из них 4 — в Cadabra Studio. В рамках работы тут я приобрела немалый опыт в менторстве молодых дизайнеров, включая подготовку и проведение интернатуры.
Тему, которую я хотела бы рассмотреть, зачастую пропускают на всевозможных дизайн-курсах. Часто в спешной погоне за мыслью или просто по причине отсутствия правильной привычки дизайнеры не заморачиваются организацией работы должным образом и не уделяют должное внимание организации макета. Эта ошибка свойственна как молодым, так и опытным дизайнерам. Но дизайнер — это не художник, нельзя говорить «Я так вижу», работа должна быть организована, а решения — мотивированы.
Макет увидите не только вы, но и коллеги, которым могут передать ваш проект по ряду причин, разработчики, заказчик и другие люди. То, насколько грамотно вы подойдете к организации рабочего процесса, влияет на скорость работы над проектом, на взаимопонимание внутри команды и на вашу репутацию как специалиста.
В этой статье я хочу рассмотреть типичные ошибки при создании интерфейса, которые допускают многие дизайнеры, и дать рекомендации по грамотной организации макета. Все, о чем я буду говорить, основано на опыте, который получили дизайнеры Cadabra Studio на протяжении периода становления компании и во время работы над самыми разнообразными проектами.
Типичные ошибки. О чем все забывают
Пользователи
Пользователи — вот главный объект внимания дизайнера. Именно для них создается интерфейс. Сам дизайнер или заказчик не является конечным потребителем продукта. Почему-то об этом часто забывают. Конечно, до начала работы над проектом необходимо проводить исследования потенциальной аудитории, составлять портреты пользователей, User Story и многое другое, но в реальной жизни это зависит от бюджета заказчика, его участия в процессе и вашего дара убеждения. Также часто дизайнер упрямо держится за решение, которое нравится или удобно лично ему, а значит, считает он, и пользователям подойдет. Но нет, это совсем не факт.
Из жизни
Несколько лет назад у нас в Cadabra Studio проводилась дизайн-интернатура. В рамках этой интернатуры наши студенты выполняли ресерч для проекта. Идея этого проекта и заказчик были полностью выдуманы нами. На одном из этапов задачей ребят было опросить реальных людей, чтобы собрать статистику и определить портреты потенциальных пользователей. Одна из студенток постаралась и опросила не только тех, кто, на ее взгляд, походил на потенциальную аудиторию приложения, но и других людей. Мы были шокированы, получив неожиданные результаты опроса. Суть приложения заключалась в поиске попутчиков для совместных велопрогулок и создании маршрутов по городу/области в зависимости от физической подготовки людей, типов велосипедов и целей.
Придумывая это приложение, мы подразумевали, что целевая аудитория будет возрастом
Подобную ошибку иногда совершают заказчики, которые при определении аудитории и ее потребностей ориентируются только на себя.
Окружающие условия
Созданный продукт всегда будет использоваться в определенных условиях и месте. Необходимо заранее выяснить, как будет проходить взаимодействие пользователя и продукта, потому что от этого будет зависеть создание интерфейса. Важно понимать, будет ли человек сосредоточен на экране, работает он с ним на улице или в помещении. Особенно это касается продуктов, которые люди будут использовать для работы. Это так называемый ситуационный фактор.
Например, приложение-навигатор, которое используется на ходу или во время поездки в автомобиле за рулем, когда человек может лишь вскользь бросить взгляд на экран, явно должно иметь очень однозначный, четко читаемый интерфейс с крупными, жирными, недвусмысленными иконками и текстом, также должна быть предусмотрена возможность управления голосом.
Из жизни
Когда-то очень давно, когда наша компания только начинала работу, мы трудились над проектом системы видеонаблюдения для охранной организации. Мы были юны, неопытны и не уточнили все нюансы. В какой-то момент выяснилось, что мы с заказчиком понимали задачу совершенно по-разному. Основываясь на украинском опыте, мы представляли, что охранники чаще всего находятся в темных маленьких помещениях и внимательно бдят. Но в действительности конечные потребители этого продукта находились в огромном светлом помещении с кучей огромных экранов, как в аэропортах. К счастью, это выяснилось достаточно рано, чтобы мы успели изменить дизайн, но выводы для себя мы сделали.
Доступность
Всегда проверяйте ваш дизайн на контрастность, читабельность, наличие визуальной иерархии, адекватную типографику и доступность восприятия. Вообще, это работает для всех, а не только для пользователей с ограниченными возможностями, как можно подумать поначалу. С этим помогает работа по модульной сетке и созданная заранее библиотека стилей и правил проекта (стили заголовков и т. д.). Также существует множество программ, которые позволяют проверить, насколько ваш дизайн контрастен и как его видят люди с различными отклонениями цветовосприятия (например, приложение Color Oracle).
Сравните сами, какой список читается лучше — слева или справа.
Тестирование
Прежде всего речь о самотестировании в процессе создания дизайна. Если вы делаете дизайн сайта, откройте его в браузере и посмотрите, как он будет выглядеть. Делаете приложение — поставьте кликабельный прототип на телефон как приложение и оцените его со стороны пользователя. На самом деле поможет даже просто просмотр скрина как картинки с телефона. Дело в том, что разрешение, тип экрана, углы просмотра и другие аспекты могут довольно сильно влиять на восприятие. Вы можете посмотреть на экран и понять, что все должно быть сделано по-другому или что есть моменты, которые нужно подправить.
Идеально, если вы работаете не один и можете попросить кого-то из коллег посмотреть на экран свежим взглядом. Коллега, которого можно позвать «на секундочку» в любой момент, — это один из явных плюсов работы в студии, на мой взгляд :)
Если говорить о тестировании пользователями, то продукт необходимо проверять на реальных людях. Лучше делать это до основного релиза. Это снижает цену ошибки, если реальные пользователи не понимают какую-то часть User Flow и его необходимо переделать. В рамках проекта гораздо дешевле внести изменения на этапе дизайна, чем делать это после разработки и выпуска.
Для тестирования мы используем такие программы, как InVision/Marvel, Sketch Mirror / Figma Mirror, которые позволяют имитировать процесс использования продукта в реальных условиях, а также Fullscreen Mode и плагин Preview in browser для Sketch.
Проверка адекватности данных
Для многих это самый сложный момент, даже опытный дизайнер может допускать ошибки. Если честно, зачастую я не могу объяснить это ничем, кроме халатности.
Итак, прежде чем отдавать макет в разработку, убедитесь, что использованные в макете данные действительно будут работать. Проверьте допустимую длину текста, уточните максимально возможное число цифр в сумме, определитесь с форматом даты. Для каждой конкретной тематики продукта есть свои ограничения, и стоит сразу попросить пример реальных данных и согласовать ограничения еще на этапе обсуждения дизайна. Например, в моем текущем проекте есть конкретный формат номера страховки, состоящий из определенного количества букв и цифр. Зная его, я могу учитывать, какое пространство и в каком месте мне стоит оставить под него. Для разных стран, естественно, применяются разные форматы отображения дат, времени, единиц веса и расстояния/длины. Очень часто забывают о длине имени. Круто, конечно, когда ты Alex Smith, а не Alexander Pellewever и помещаешься везде, но так бывает не всегда.
Из жизни
Было очень забавно, когда мы делали один крупный медицинский проект вместе с разработчиками из другой компании и тестировщик абсолютно серьезно спросил нас: «А что будет, если в этом поле будет значение 1/8000 таблетки?» И это очень ответственный подход :)
Из жизни
Отрицательный пример: часто, смотря работы на Dribbble, я вижу, что многие не учитывают в портфолио все эти моменты. На мой взгляд, это такой же признак непрофессионализма, как и Lorem ipsum на презентационном экране. Вот, например, у бывшего топ-дизайнера одной из студий я увидела примерно такой экран в портфолио:
У меня возникает вопрос: что произойдет, если будет не понедельник, а среда, не март, а ноябрь?
Pixel Perfect
Дьявол кроется в мелочах, и это именно тот случай. Все элементы должны всегда иметь целые значения, никаких полупикселей. Это же касается и сложных составных иконок — в целом фигура может быть ровной, но вот внутри творится ерунда.
В макете, который вы отдаете в разработку, такого быть не должно. Составные иконки стоит превратить в слитые фигуры с целыми значениями.
Вы всегда можете проверить себя в режиме Pixel Preview. Также если у вас вышли элементы нецелого значения, то для Sketch я рекомендую использовать плагин Pixel Perfecter — зачастую он работает намного лучше родной функции.
Существование гайдлайнов
Гайдлайны — один из первых вопросов, которые задают на собеседованиях. Не стоит часами сидеть, страдать и выдумывать велосипед, усложняя интерфейс. В большинстве случаев уже есть определенные правила, применение которых упрощает жизнь пользователю, поскольку он понимает, чего ожидать в том или ином случае. Иногда отличные решения можно взять прямо из нативных приложений. В этом отношении мне особенно нравится Google Calendar, где многие процессы реализованы очень разумно.
Из жизни
В переданном мне чужом проекте я встретила потрясающую функцию, которая выглядела примерно так:
Интересно, как много ошибок совершалось бы при быстром заполнении формы. Что-то и без тестов подсказывает мне, что много.
Предотвращение ошибок
Недавно у нас проходил собеседование молодой дизайнер, который не смог назвать, какие бывают состояния полей ввода. Так вот, передавая проект, всегда нужно учитывать, какие ошибки могут быть сделаны и как они будут выглядеть. В целом я посоветовала бы учесть следующие моменты:
- Защита от дурака. Например, не ставьте кнопку «Удалить пост» рядом с кнопкой «Сохранить». Позаботьтесь о том, чтобы нельзя было уничтожить результаты работы пользователя случайным нажатием. В конце концов, у каждого из нас по клавиатуре может случайно пробежать кот и нажать что-то не то :)
- Возможность отменить совершенное действие. Яркий пример — Snackbar на Android. Когда вы закрываете вкладки в мобильной версии Chrome, он уточняет, действительно ли вы хотите их закрыть, и дает возможность отменить это действие в течение нескольких секунд.
- Помощь при вводе данных. Если пользователи могут совершить ошибку, они обязательно это сделают. Человек может очень долго неправильно набирать название улицы, не получать результат, а затем писать гневные сообщения в поддержку или просто покинуть сайт. Это решается очень просто: предложите пользователю правильные варианты. Иногда можно показать дополнительную подсказку. Классный и простой пример графической подсказки — когда показывают, где именно находится злополучный
CVV-код на карте (что очевидно для нас и совсем неочевидно для пожилых людей). - Проверка данных. Покажите, что увидит пользователь в случае, если, например, формат введенного номера телефона не соответствует стандарту или пользователь потерял какой-то символ в домене почты.
Из жизни
У меня есть хобби — играть и создавать игры для автоквеста. Сайт, через который происходит все взаимодействие и управление, имеет ужасный, старый и неудобный интерфейс. Когда ты пишешь игру и уже загрузил бо́льшую часть сценария (а это очень приличный кусок работы в человеко-часах: помним о плохом интерфейсе и отсутствии оптимизации), то на странице игры появляется и висит яркая, привлекательная и очень манящая кнопка «Удалить игру». Скажу честно, я каждый раз с большим трудом удерживаюсь от нажатия. Почему такая редко используемая функция выглядит как призыв к действию, непонятно.
Отсутствие элементарной грамотности
The last but not the least. Это то, что лично меня немного раздражает. Я сама не знаток языков и могу совершать ошибки или делать опечатки. Но, на мой взгляд, знать базовые слова и терминологию в рамках проекта вы должны. Это огромный, жирнейший минус, когда дизайнер показывает заказчику экран или презентует его как готовый, а заказчик поправляет ошибки в простых словах. Это очень непрофессионально. То, что могут простить в разговорной речи, непростительно в письменной. Постарайтесь пробежаться глазами по тексту, прежде чем заливать макет на презентацию.
Из жизни
Я уже упоминала проект, который достался мне от другого дизайнера. Он был посвящен договорам между инвесторами и заемщиками в сфере недвижимости. Соответственно, в проекте фигурировали не только обычные слова, но и более специфические названия (loan, borrower, lender, mortgage и т. д.). Вот часть того, что я обнаружила в этом проекте после другого дизайнера:
Думаю, комментарии излишни.
Макеты. Как сделать свою работу удобной
Чтобы всем жилось хорошо, исходники должны быть в порядке. Все следующие рекомендации основаны на нашем личном опыте и прописаны во внутренних правилах Cadabra Studio. Если у вас есть что добавить, советы по улучшению, пожалуйста, пишите в комментариях :)
Устранение беспорядка в макетах
По своему опыту могу сказать, что чем раньше ты начнешь все грамотно организовывать, тем легче будет тебе самому, разработчику и дизайнеру, который может прийти на смену. Поэтому необходимо:
- Привести все в порядок, как только утвержден хотя бы один экран.
Понятно, что в начале проекта, когда еще неясно, какой будет стиль, не до идеальной красоты в слоях. Но я советую начинать организовывать сразу, не позже первого одобрения от заказчика. - Не создавать хаос. Он будет расти как снежный ком.
Если вы вдруг решите навести порядок в конце проекта (а такое бывало и у меня), то потратите гораздо больше времени, потому что часть элементов уже использованы много раз и нужно многократно проделывать одно и то же действие. - Никогда не передавать заказчику/разработчику неупорядоченный файл.
Система имен
В каждой компании она может быть разная, но мы путем проб и ошибок вывели для себя следующую формулу:
Type — категория, к которой принадлежит компонент: bg (background), btn (button), icn (icons), img (image).
Location — экран или место, где появляется компонент (global — в нескольких).
Identifier — назначение компонента.
State — возможные состояния.
С такой структурой очень легко работать как дизайнерам, так и разработчикам. Нам удобно подменять элементы на другие состояния (и заодно отслеживать, все ли состояния есть), а разработчикам достаточно скопировать название.
Если разработчику по каким-то причинам не подходит наименование через слеши, то есть отличная функция от Zeplin, которая позволяет изменять в названиях уже готовых и залитых элементов слеши на подчеркивания, тире и т.д.
Что нельзя делать с иконками
Иконки — всегда больная тема, потому что все забывают привязаться к сетке, выровнять значения и т.д.
Поэтому нельзя:
- Добавлять к иконке обводку нецелого значения (0,345) для визуального баланса.
Скачал иконку с Flaticon для экономии времени, а она шейповая и не той толщины? «Ну-ка, докину-ка я обводку нужной толщины, чтобы не отличалась от остальных». Вот так делать нельзя, по крайней мере в финальном файле этого быть не должно. - Оставлять иконку обводкой при передаче файла.
Часто иконки составные, если отдать ее как есть в виде обводки, половина элементов не отобразится, а другая — поедет. Проверено. Поэтому переводим в шейп и сливаем воедино. - Оставлять иконку без контейнера.
Не забываем о зоне нажатия. Отступы считаются от контейнера. - Игнорировать состояния.
- Применять разную стилистику в одном проекте. Если вы используете аутлайновый стиль иконок, то не стоит добавлять шейповые.
- Игнорировать здравый смысл.
Из жизни
На тему здравого смысла есть еще один пример из того же моего «любимого» проекта. Как эта скрепка держит бумаги?
Возможная оптимизация процесса работы
Думаю, в 2019 году все уже все знают, но все же напомню, что сильно ускорит и упростит работу:
- Использование горячих клавиш.
- Создание и использование стилей и символов/компонентов. Советую делать это с самого начала проекта.
- Использование готовых проверенных библиотек и темплейтов. Например, Material Design имеет свою библиотеку, которую можно скачать, это же справедливо и для iOS.
- Функция Replace With (для Sketch) — она дает возможность подменять группы на символы. Удобно для наведения порядка.
- Плагины (если вы работаете в Sketch).
Контроль версий
Чтобы потом не было мучительно больно, стоит делать и хранить backup. С Abstract лично у нас как-то не сложилось, поэтому используем следующее:
- В облаке создается папка, к которой нет доступа у заказчика. В ней — папка «Архив» и последний актуальный исходник. Это нужно для того, чтобы ваши коллеги могли понять, куда смотреть в случае чего, а вы сами не путались. Никаких Final Final. Мы прописываем название проекта (или проект плюс раздел, если это отдельные файлы) и дату последних изменений в нем. По окончании проекта заливаете исходник для заказчика в отдельную папку.
- Все рабочие файлы должны находиться в своей папке в облаке. Обязательно! Иначе потом будут грустные истории о том, как кто-то пролил кофе на ноут и все пропало. Никто не застрахован, увы.
- Прежде чем удалять/изменять то, что не утвердил заказчик, нужно скопировать проделанную работу в архив. Это классика, когда просят вернуться к какой-то фиче, от которой решительно отказались два месяца назад.
- Убираем неактуальные экраны в InVision в архив. Когда проект долгий и идут длительные согласования дизайна, неизбежно накапливаются какие-то неактуальные экраны, которые будут всех запутывать. Не советую удалять их безвозвратно, но вот архив — отличная вещь.
Выводы
Я бы очень хотела, чтобы в мире стало больше хорошего дизайна, а между людьми было полное взаимопонимание. То, как мы делаем свою работу, влияет на коммуникацию и скорость создания проекта. Я бы не хотела, чтобы продолжалось недопонимание между дизайнерами и разработчиками, и я по себе знаю, каково это, когда достается начатый кем-то «опытным» проект в ужасном состоянии и приходится в нем копаться, чтобы найти истину. В процессе важные наработки и нюансы могут потеряться.
Работа дизайнера — это еще не конечная точка в разработке проекта, и мы, как никто другой, заинтересованы в том, чтобы проект воплотился в жизнь таким, каким мы его проектируем.
P.S. Если вы начинающий дизайнер, и вам понравилось — приходите к нам на интернатуру. Расскажем больше и научим всему, что знаем :)
