×

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

Привет! Меня зовут Ольга, я живу в Днепре и работаю дизайнером последние 6 лет, из них 4 — в Cadabra Studio. В рамках работы тут я приобрела немалый опыт в менторстве молодых дизайнеров, включая подготовку и проведение интернатуры.

Тему, которую я хотела бы рассмотреть, зачастую пропускают на всевозможных дизайн-курсах. Часто в спешной погоне за мыслью или просто по причине отсутствия правильной привычки дизайнеры не заморачиваются организацией работы должным образом и не уделяют должное внимание организации макета. Эта ошибка свойственна как молодым, так и опытным дизайнерам. Но дизайнер — это не художник, нельзя говорить «Я так вижу», работа должна быть организована, а решения — мотивированы.

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

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

Типичные ошибки. О чем все забывают

Пользователи

Пользователи — вот главный объект внимания дизайнера. Именно для них создается интерфейс. Сам дизайнер или заказчик не является конечным потребителем продукта. Почему-то об этом часто забывают. Конечно, до начала работы над проектом необходимо проводить исследования потенциальной аудитории, составлять портреты пользователей, User Story и многое другое, но в реальной жизни это зависит от бюджета заказчика, его участия в процессе и вашего дара убеждения. Также часто дизайнер упрямо держится за решение, которое нравится или удобно лично ему, а значит, считает он, и пользователям подойдет. Но нет, это совсем не факт.

Из жизни

Несколько лет назад у нас в Cadabra Studio проводилась дизайн-интернатура. В рамках этой интернатуры наши студенты выполняли ресерч для проекта. Идея этого проекта и заказчик были полностью выдуманы нами. На одном из этапов задачей ребят было опросить реальных людей, чтобы собрать статистику и определить портреты потенциальных пользователей. Одна из студенток постаралась и опросила не только тех, кто, на ее взгляд, походил на потенциальную аудиторию приложения, но и других людей. Мы были шокированы, получив неожиданные результаты опроса. Суть приложения заключалась в поиске попутчиков для совместных велопрогулок и создании маршрутов по городу/области в зависимости от физической подготовки людей, типов велосипедов и целей.

Придумывая это приложение, мы подразумевали, что целевая аудитория будет возрастом 25–35 лет, то есть это люди, у которых чаще всего уже есть свой велосипед, желание активно проводить свое свободное время и искать новые компании. Но по результатам обширного опроса Карины мы получили совсем другую картину. Та аудитория, о которой мы думали, и так достаточно избалована развлечениями в городе, у них довольно широкий круг общения, и они были не слишком заинтересованы в подобном приложении. А вот люди 40–50 лет проявили огромный интерес и даже спрашивали, когда же выйдет такое приложение. Для них было более актуальным найти новых знакомых и компанию, которая хочет активно проводить выходные. Соответственно, интерфейс нужно было проектировать уже с учетом этих данных.

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

Окружающие условия

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

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

Из жизни

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

Доступность

Всегда проверяйте ваш дизайн на контрастность, читабельность, наличие визуальной иерархии, адекватную типографику и доступность восприятия. Вообще, это работает для всех, а не только для пользователей с ограниченными возможностями, как можно подумать поначалу. С этим помогает работа по модульной сетке и созданная заранее библиотека стилей и правил проекта (стили заголовков и т. д.). Также существует множество программ, которые позволяют проверить, насколько ваш дизайн контрастен и как его видят люди с различными отклонениями цветовосприятия (например, приложение 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, где многие процессы реализованы очень разумно.

Из жизни

В переданном мне чужом проекте я встретила потрясающую функцию, которая выглядела примерно так:

Интересно, как много ошибок совершалось бы при быстром заполнении формы. Что-то и без тестов подсказывает мне, что много.

Предотвращение ошибок

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

  1. Защита от дурака. Например, не ставьте кнопку «Удалить пост» рядом с кнопкой «Сохранить». Позаботьтесь о том, чтобы нельзя было уничтожить результаты работы пользователя случайным нажатием. В конце концов, у каждого из нас по клавиатуре может случайно пробежать кот и нажать что-то не то :)
  2. Возможность отменить совершенное действие. Яркий пример — Snackbar на Android. Когда вы закрываете вкладки в мобильной версии Chrome, он уточняет, действительно ли вы хотите их закрыть, и дает возможность отменить это действие в течение нескольких секунд.
  3. Помощь при вводе данных. Если пользователи могут совершить ошибку, они обязательно это сделают. Человек может очень долго неправильно набирать название улицы, не получать результат, а затем писать гневные сообщения в поддержку или просто покинуть сайт. Это решается очень просто: предложите пользователю правильные варианты. Иногда можно показать дополнительную подсказку. Классный и простой пример графической подсказки — когда показывают, где именно находится злополучный CVV-код на карте (что очевидно для нас и совсем неочевидно для пожилых людей).
  4. Проверка данных. Покажите, что увидит пользователь в случае, если, например, формат введенного номера телефона не соответствует стандарту или пользователь потерял какой-то символ в домене почты.

Из жизни

У меня есть хобби — играть и создавать игры для автоквеста. Сайт, через который происходит все взаимодействие и управление, имеет ужасный, старый и неудобный интерфейс. Когда ты пишешь игру и уже загрузил бо́льшую часть сценария (а это очень приличный кусок работы в человеко-часах: помним о плохом интерфейсе и отсутствии оптимизации), то на странице игры появляется и висит яркая, привлекательная и очень манящая кнопка «Удалить игру». Скажу честно, я каждый раз с большим трудом удерживаюсь от нажатия. Почему такая редко используемая функция выглядит как призыв к действию, непонятно.

Отсутствие элементарной грамотности

The last but not the least. Это то, что лично меня немного раздражает. Я сама не знаток языков и могу совершать ошибки или делать опечатки. Но, на мой взгляд, знать базовые слова и терминологию в рамках проекта вы должны. Это огромный, жирнейший минус, когда дизайнер показывает заказчику экран или презентует его как готовый, а заказчик поправляет ошибки в простых словах. Это очень непрофессионально. То, что могут простить в разговорной речи, непростительно в письменной. Постарайтесь пробежаться глазами по тексту, прежде чем заливать макет на презентацию.

Из жизни

Я уже упоминала проект, который достался мне от другого дизайнера. Он был посвящен договорам между инвесторами и заемщиками в сфере недвижимости. Соответственно, в проекте фигурировали не только обычные слова, но и более специфические названия (loan, borrower, lender, mortgage и т. д.). Вот часть того, что я обнаружила в этом проекте после другого дизайнера:

Думаю, комментарии излишни.

Макеты. Как сделать свою работу удобной

Чтобы всем жилось хорошо, исходники должны быть в порядке. Все следующие рекомендации основаны на нашем личном опыте и прописаны во внутренних правилах Cadabra Studio. Если у вас есть что добавить, советы по улучшению, пожалуйста, пишите в комментариях :)

Устранение беспорядка в макетах

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

  1. Привести все в порядок, как только утвержден хотя бы один экран.
    Понятно, что в начале проекта, когда еще неясно, какой будет стиль, не до идеальной красоты в слоях. Но я советую начинать организовывать сразу, не позже первого одобрения от заказчика.
  2. Не создавать хаос. Он будет расти как снежный ком.
    Если вы вдруг решите навести порядок в конце проекта (а такое бывало и у меня), то потратите гораздо больше времени, потому что часть элементов уже использованы много раз и нужно многократно проделывать одно и то же действие.
  3. Никогда не передавать заказчику/разработчику неупорядоченный файл.
Наша арт-директор говорит, что оторвет руки, если увидит такое. И да, она может :)

Система имен

В каждой компании она может быть разная, но мы путем проб и ошибок вывели для себя следующую формулу:

Type — категория, к которой принадлежит компонент: bg (background), btn (button), icn (icons), img (image).
Location — экран или место, где появляется компонент (global — в нескольких).
Identifier — назначение компонента.
State — возможные состояния.

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

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

Что нельзя делать с иконками

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

Поэтому нельзя:

  1. Добавлять к иконке обводку нецелого значения (0,345) для визуального баланса.
    Скачал иконку с Flaticon для экономии времени, а она шейповая и не той толщины? «Ну-ка, докину-ка я обводку нужной толщины, чтобы не отличалась от остальных». Вот так делать нельзя, по крайней мере в финальном файле этого быть не должно.
  2. Оставлять иконку обводкой при передаче файла.
    Часто иконки составные, если отдать ее как есть в виде обводки, половина элементов не отобразится, а другая — поедет. Проверено. Поэтому переводим в шейп и сливаем воедино.
  3. Оставлять иконку без контейнера.
    Не забываем о зоне нажатия. Отступы считаются от контейнера.
  4. Игнорировать состояния.
  5. Применять разную стилистику в одном проекте.
  6. Если вы используете аутлайновый стиль иконок, то не стоит добавлять шейповые.
  7. Игнорировать здравый смысл.

Из жизни

На тему здравого смысла есть еще один пример из того же моего «любимого» проекта. Как эта скрепка держит бумаги?

Возможная оптимизация процесса работы

Думаю, в 2019 году все уже все знают, но все же напомню, что сильно ускорит и упростит работу:

  1. Использование горячих клавиш.
  2. Создание и использование стилей и символов/компонентов. Советую делать это с самого начала проекта.
  3. Использование готовых проверенных библиотек и темплейтов. Например, Material Design имеет свою библиотеку, которую можно скачать, это же справедливо и для iOS.
  4. Функция Replace With (для Sketch) — она дает возможность подменять группы на символы. Удобно для наведения порядка.
  5. Плагины (если вы работаете в Sketch).

Контроль версий

Чтобы потом не было мучительно больно, стоит делать и хранить backup. С Abstract лично у нас как-то не сложилось, поэтому используем следующее:

  1. В облаке создается папка, к которой нет доступа у заказчика. В ней — папка «Архив» и последний актуальный исходник. Это нужно для того, чтобы ваши коллеги могли понять, куда смотреть в случае чего, а вы сами не путались. Никаких Final Final. Мы прописываем название проекта (или проект плюс раздел, если это отдельные файлы) и дату последних изменений в нем. По окончании проекта заливаете исходник для заказчика в отдельную папку.
  2. Все рабочие файлы должны находиться в своей папке в облаке. Обязательно! Иначе потом будут грустные истории о том, как кто-то пролил кофе на ноут и все пропало. Никто не застрахован, увы.
  3. Прежде чем удалять/изменять то, что не утвердил заказчик, нужно скопировать проделанную работу в архив. Это классика, когда просят вернуться к какой-то фиче, от которой решительно отказались два месяца назад.
  4. Убираем неактуальные экраны в InVision в архив. Когда проект долгий и идут длительные согласования дизайна, неизбежно накапливаются какие-то неактуальные экраны, которые будут всех запутывать. Не советую удалять их безвозвратно, но вот архив — отличная вещь.

Выводы

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

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

P.S. Если вы начинающий дизайнер, и вам понравилось — приходите к нам на интернатуру. Расскажем больше и научим всему, что знаем :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




12 коментарів

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

Почему здравый смысл и наличие вкуса решили назвать «Доступностью»?))

потому что «accessibility» — устоявшийся термин

Так это изначально для людей с определенной потребностью (ограниченными возможностями, например)

Адаптивный дизайн и семантическая вёрстка это тоже «Доступность»))
Вот более аргументированно написано telegraf.design/...​v-dostupnogo-veb-dizajna

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

Фигасе! Это наверное можно читать как «отличная статья» если вечно недовольный завсегдатай написал интересно :)

Спасибо, за хорошую статью!

Підписатись на коментарі