Figma: гибкий и модульный дизайн-подход к типографике с помощью компонентов

Путь к улучшенной, умной и упрощенной архитектуре работы.

Проблема

Управление текстом является одной из главных проблем дизайнеров при создании адаптивного или гибкого пользовательского интерфейса. Подавляющее большинство компонентов, построенных на системе, создаются с использованием текстовых элементов.

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

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


Решение

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

Компоненты и Переопределения (Overrides) в Figma настолько мощные, что они требуют от вас более тонкого и лучшего понимания того, как вы организуете свою работу. Если вы будете следовать методологии Atomic Design, компоненты в Figma позволят вам резко сократить количество общих элементов, необходимых для выполнения задачи.


Процесс

Шаг 1: Root-компонент

В некоторых аспектах техника очень похожа на то, что называется CSS and fluid typographyкоторую можно встретить в Интернете в наши дни.

Итак, давайте начнем с создания нового Компонента текстового слоя, который будет выступать в качестве базовой единицы измерения (Root Unit), а все другие текстовые слои будут зависимы от нее. Я выбрал базу 16px /120%.

Компонент, созданный из текстового элемента


Два небольших требования:

Resize to Fit: просто не оставляйте пустое пространство вокруг краев фрейма компонента, чтобы избежать проблем с выравниванием в будущих экземплярах (Instances).

Rename: Переименовывайте внутренний текстовый слой в поле «Текст», так как при смене экземпляров с помощью меню выбора на панели свойств текстовое содержимое будет сохраняться. См. раздел «Swapping Nested Instances»

Переименованный компонент текста


Шаг 2. Настройка модульной шкалы

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

Используя модульный инструмент масштабирования, например modularscale.com, мы можем быстро генерировать ряд значений для объектов Figma. В нашем случае я выбрал 16px в качестве базовой единицы и 1,5 в качестве коэффициента (Простите, любители Золотого сечения…)


Теперь используем полученные значения для создания нескольких базовых текстовых объектов, зададим им ярко-красный цвет и затем сгруппируем. Для простоты я создал 4 размера для заголовков и один — для основного текста.


Шаг 3: Создаем Экземпляры (Instances)

Затем мы можем создать Instances, начиная с базового (Root) компонента. Просто перетащите его, удерживая клавишу Option/Alt, затем измените текст и размер фрейма как на картинке.

А теперь самое сложное… нам надо подогнать размер экземпляров под размеры текста, созданный нами ранее…

НО…. Мы не будем устанавливать размер шрифта через панель свойств, вместо этого мы используем Scale Tool (K).


Лучшее свойство Scale Tool в Figma это его способность пропорционально изменять абсолютно все свойства, такие как: обводка (strokes), направления масштабирования (constrains) и размеры, сохраняя при этом экземпляр/слой полностью редактируемым.

Итак… Время растягивать!


Примечание. Если бы мы выбрали размер с помощью панели «Свойства», это вызвало бы переопределение и установило бы независимое поведение для экземпляра.

Примечание 2. Конечный размер шрифта может содержать значения с запятой, не паникуйте, это допустимо, особенно при использовании css-функции calc().


Шаг 4: Растягиваем базовый элемент

Просто повторите шаг 3 для всех экземпляров и готово!

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

Важно: каждый раз изменяя размер базового компонента, обязательно используйте Resize to Fit на панели свойств, как показано в шаге 1 и картинке ниже в режиме Outline Mode (⌘ + Y) или Shift+Ctrl+3.


Шаг 5: Поиграем шрифтами!

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


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

В некот����рых случаях это, наоборот, необходимо — например, если вам нужно зафиксировать размер текста для определенных размеров экрана или сохранить только в заголовках. См. ниже на примере строку «Elon Musk».


Подытожим

Эта техника лишь верхушка айсберга, на что способны Компонентов в Figma. Более плавный, простой и удобный рабочий процесс для ваших проектов.

Сложные в использовании компоненты или 10-кратные дубликаты одного и того же элемента ради изменения цвета или типа выравнивания ушли в прошлое.

Образец файла проекта доступен бесплатно здесь!


Статью подготовила:  Kseniya Sazonova

Ссылка на источник

April 19, 2019
by Designdealer
2
1 142

Гештальт-принципы в дизайне интерфейсов

Как научиться мастерски управлять восприятием через визуальную коммуникацию


Знаете, бывает смотришь на облако и видишь в нем какое-то животное или фигуру? А вы когда-нибудь задумывались, почему, при взгляде на кудрявые сгустки водяного пара, у нас возникают такие ассоциации? Все потому, что так работает мозг!

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

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

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

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


“Хороший дизайнер понимает, насколько важную роль в визуальном восприятии играет психология. Что происходит, когда взгляд зрителя падает на вашу дизайнерскую работу? Как отреагирует его мозг на сообщение, которое вы пытаетесь передать?”

Лаура Буше, стратег по бренд-контенту в Autodesk


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


Что такое Гештальт?

Гештальт (нем. форма, структура) — это группа принципов визуального восприятия, разработанных в 1920 годах немецкими психологами. Гештальт-принципы строятся на теории о том, что “организованное целое воспринимается как нечто большее, чем просто сумма его частей”.


Целое — это не просто сумма составляющих его частей

Курт Коффка


Гештальт-принципы пытаются описать, как люди воспринимают визуальные элементы в тех или иных условиях. Принципы строятся на четырех ключевых идеях:

Появление

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

Материализация

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

Мультистабильность

Люди могут по-разному воспринимать и интерпретировать неоднозначные объекты. Мозг будет перескакивать между возможными вариантами значения объекта. В результате один из вариантов возьмет верх, и станет сложнее видеть остальные.

Неизменность

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

А теперь давайте рассмотрим Гештальт-принципы, которые помогают нам в проектировании современных интерфейсов.

Близость

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

Как применить принцип Близости в UI дизайне?

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

Принцип близости гласит, что взаимосвязанные объекты должны располагаться близко друг к другу, а несвязанные — на расстоянии. В данном случае очень важную роль играет белое пространство: оно создает контраст, который направляет взгляд пользователя в нужном направлении. Белое пространство здорово усиливает визуальную иерархию и помогает задавать направление внимания. В результате такой лейаут проще читать и сканировать — а это помогает пользователям быстрее достигать своих целей и глубже погружаться в содержимое интерфейса.

В интерфейсе принцип близости можно применить практически везде: от навигации, карточек, галерей и баннеров до списков, основного текста и нумерации страниц.


Общая область

Это принцип напоминает принцип близости: элементы, расположенные в пределах одной области, воспринимаются как группа.

Как применить принцип Общей области в UI дизайне?

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

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

Хороший пример использования принципа Общей области в интерфейсе — это карточки: четко ограниченные прямоугольные области, в которых размещается взаимосвязанная информация. Еще хороший пример — баннеры и таблицы.


Схожесть

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

Как применить принцип Схожести в UI дизайне?

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

Есть несколько способов сделать элементы схожими: по цвету, размеру, форме, текстуре или ориентации. Н��которые из этих способов более эффективны: например, цвет является более определяющим фактором, чем размер — а размер важнее, чем форма. В рамках группы схожих объектов можно легко выделить какой-то один, если сделать его непохожим на остальные. Это называется “Аномалией” — и эту фишку можно использовать, чтобы создать контраст или увеличить визуальный вес. Это поможет привлечь внимание пользователя к определенному элементу (точке фокусировки) — при этом не нарушая сканируемость, понятность и плавность интерфейса.

Можно использовать принцип Схожести в навигации, ссылках, кнопках, заголовках, призывах к действию и т.д.


Замкнутость

Мы часто воспринимаем группу элементов как один узнаваемый объект или фигуру. Принцип Замкнутости также работает, когда объект неполный, или какие-то части не соединены между собой.

Как применить принцип Замкнутости в UI дизайне?

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

Принцип Замкнутости можно использовать в иконографике: простота помогает нам понятно и эффективно передавать смыслы.


Симметрия

Симметричные элементы (даже если они находятся на расстоянии) обычно воспринимаются как взаимосвязанные и создают ощущение целостности и порядка.


Как применить принцип Симметрии в UI дизайне?

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

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

Симметрию хорошо использовать при оформлении портфолио, галерей, продуктовых каталогов, описаний продукта, навигации, баннеров и других страниц, насыщенных контентом.


Продолжение

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

Как применить принцип Продолжения в UI дизайне?

Элементы, расположенные по линии, воспринимаются как сгруппированные. Чем плавнее линия, тем проще элементы складываются в единую фигуру: наш мозг любит идти по пути наименьшего сопротивления.

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


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


Общая судьба

Элементы, движущиеся в одном направлении, мы воспринимаем более взаимосвязанными, чем те, что движутся в разных направлениях или стоят на месте.


Как применить принцип Общей судьбы в UI дизайне?

Неважно, как далеко друг от друга располагаются объекты и насколько они разные — если они вместе движутся или изменяются, мы воспринимаем их как взаимосвязанные. Этот эффект работает даже когда нет явного движения, а есть только намек на движение: например, визуально показано направление.

Когда элементы синхронизированы: движутся одновременно, в одном направлении и с одинаковой скоростью, принцип Общей судьбы работает сильнее. Он помогает нам сгруппировать элементы и связать действия с результатами. Нарушение синхронного движения сразу привлекает внимание пользователя и направляет его на определенный элемент или функцию. А еще таким образом можно связывать разные состояния и группы объектов.

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


Заключение

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


Статью подготовила:  Nancy Pong

Ссылка на источник

April 16, 2019
by Designdealer
1
2 432

Figma компонент и организация экземпляров на примере Userpic


Качественная дизайн-система в Фигме всегда учитывает возможные состояния определенных компонентов. Если до появления Global Styles вариант был лишь один — всегда создавать новый компонент для каждого состояния (например текстовое поле может быть default, а может быть focused), то после внедрения стилей многие UI-элементы удалось унифицировать лишь до одного в своей категории, а разнообразие создавать экземплярами, присоединяя лишь новые стили и цвета.


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


Userpic

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

  • без загруженной фотографии
  • с инициалами вместо фотографии
  • с индикатором состояния “онлайн / оффлайн”
  • с бейджиком нотификаций
  • содержащий иконку дополнительного действия
  • содержащий несколько лиц для прототипирования
  • использован в разной размерности на разных экранах без отсоединения


Очевидно, что в хорошей Figma системе для hi-end прототипирования мы хотим получить все эти состояния быстро и удобно. Вдобавок мы хотим оставаться с минимумом необходимых компонентов. Поэтому возникает вопрос: хранить все состояния в виде скрытых слоёв в мастере или каждое состояние должно быть объявлено самостоятельным компонентом?


Создание компонента из экземпляра

Этот способ сохранил свои преимущества и после прихода Global Styles. Переключение экземпляра оптимально в том случае, когда в нем достаточно много отличий от родительского компонента. Например другой цвет, толщина обводки, тень, изображение и так далее. Например, состояния инпутов быстрее переключать через экземпляры. Особенно в большом проекте со множеством страниц. А, например, иконку внутрь кнопки лучше вложить на уровне мастера и отключить. Так гораздо быстрее скопипастить кнопку из соседнего артборда и просто сделать Visible слой с иконкой.


Pros: позволяет быстро перключать состояния экземпляров со множеством отличий

Cons: заведомо большее число компонентов, требуется время на их организацию


Скрытые слои внутри master-компонента


В наши дни Фигма отлично справляется с сотнями экземпляров, которые содержат 5-10 скрытых групп со десятками слоев и разбросаны по множеству страниц. Так что не переживайте за производительность, хотя когда-то давно 10 таких страниц буквально вешали проект. Ведь в случае использования этого метода всего-навсего в мастер-компонент Userpic, помимо фотки, нужно будет запихать и сразу же спрятать:

  • слой или группу с векторными объектами для пустого юзерпика
  • текстовый слой для инициалов, центрированный
  • бейджик нотификаций, в правый верхний угол
  • индикатор состояния онлайн/оффлайн, в нижний
  • иконку в центр компонента или угол, для мобильных сценариев (например призыв редактировать фото, удалить)
  • несколько изображений лиц (в iOS design toolkit сделано 5 мужских, 5 женских и всё сгруппировано)
  • каждому элементу расставить Constraints, чтобы Userpic можно было использовать в нескольких размерах
  • что еще я забыл? :)


Pros: быстрое получение нужного состояния экземпляра, путем переключения видимсти слоёв

Cons: если переключать 3+ слоя и вдобавок присоединять новые стили, действий становится слишком много


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


Меньше лишних действий

Создавая новое правило, вы возможно улучшаете свой алгоритм. Я остановился на таком для себя: если создание нового состояния требует 3 или более переключения слоев в “Видимый”, то лучше предопределять это состояние в отдельный компонент, который сначала был экземпляром. Помните, что потребуется потратить время на организацию, проверить нейминг каждого слоя (чтобы текстовые элементы не теряли контент при перключении), констрейны, порядок следования… и много чего еще!


Статью подготовил: Роман Камушкин

Ссылка на источник

March 4, 2019
by Designdealer
0
29

Как спроектировать правильный экран-заглушку

Сейчас все большее внимание уделяется смысловой части интерфейсов, UX-дизайнеры продумывают все, вплоть до надписей на кнопках. В Apple, Google, Microsoft, Dropbox и других крупных компаниях уже появились отдельные специалисты — UX-писатели, следящие не столько за грамотностью формулировок, сколько за смысловой частью и логикой повествования.

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

Примеры неправильно спроектированных экранов


AliExpress (iOS) показывает пустую страницу, если в «Избранном» нет товаров. И непонятно: то ли это я не выбрал товары, либо приложение ещё не загрузило данные.

«Яндекс.Еда» (iOS) ограничилось при поиске фразой «Ничего не найдено». Хотя можно было бы показывать рестораны поблизости или варианты кухонь мира, чтобы пользователь мог дальше продолжить поиск. 

«Спасибо от Сбербанка. Путешествия» (веб) тоже не использует UX-подход проектированию заглушек. И даже спрятал текст «Поиск не дал результата» под фильтр, где его сложно заметить.


Представьте, что вы открываете только что скачанное мобильного приложение с ресторанами, заходите в «Избранное», а вместо контента видите пустой экран. Какая ваша первая мысль? Наверное, «Оу, что-то сломалось?» или «Что за ерунду они написали?». А на самом деле причина в том, что в раздел «Избранное» вы просто ещё не успели добавить любимые рестораны.


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

Якоб Нильсен (эвристика «Информационность о состоянии системы)

Пользователь всегда должен чётко понимать, на какой странице он находится и что он видит. А если не видит, то почему. И стандартными фразами вроде «Нет данных», так любимых консервативными айтишниками, тут не отделаться.


Здесь возможны следующие варианты

  1. Что-то сломалось.
  2. Контент должен создать сам пользователь.
  3. Контент должны добавить другие пользователи системы.
  4. Пустые результаты поиска.


Посмотрим, что можно с этим сделать

Что-то сломалось

Примеры правильно спроектированных экранов, где правильно отработаны ошибки


«Яндекс.Транспорт» (iOS) показывает сообщение о потере соединения, чтобы пользователь понимал, что он не сможет сейчас построить маршрут. 

DocDoc (iOS) также выводит сообщение об ошибке, предлагает повторить попытку соединения, а картинка снижает градус недовольства. 

Аналогично поступает и приложение «Яндекс.Расписания» (iOS) при неудачной попытке загрузить расписание. 

«Рокетбанк» (iOS) объясняет пользователям, что без интернета невозможен доступ к данным, и предлагает два пути решения проблемы.


Как бы качественно ни был написан продукт, баги будут всегда. Это нужно принять как факт. И постараться продумать все возможные причины их появления. Может, пропал интернет, может, завис сервер, а может, разработчик забыл закрыть переменную.

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


Контент должен создать сам пользователь

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


«Сбербанк» (iOS) показывает текст, призывающий совершить действие, картинку и кнопку, чтобы пользователь сразу смог начать диалог. 

Aviasales (iOS), запрашивая разрешение на уведомления, рассказывает об их ценности для пользователя и картинкой снимает напряжение. 

SmartMed (iOS) рассказывает, о чём этот раздел, и предлагает его наполнить.

Lamoda (iOS) также объясняет, почему экран пуст, и предлагает перейти в каталог для выбора товаров.


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

Чтобы у пользователя не было негативных эмоций, когда он увидит пустой экран, нужно его успокоить и вернуть ему чувство контроля над ситуацией. Для этого нужно объяснить, что именно он отвечает за наполнение этой страницы. И сразу же предложить ему действие.

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



Контент должны добавить другие пользователи системы

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


RemsMed (iOS) объясняет, почему на экране нет контента и что врач должен сначала составить вопросы для пользователя-пациента. В этом случае нет возможности предложить действие, но у пользователя есть понимание ситуации. 

Сервис «Google Документы» (веб) не даёт увидеть документ, если у тебя нет прав, и сразу предлагает запросить доступ.


Бывают случаи, когда контент зависит от других участников. Возьмём, к примеру, сервисы, где нужно получить инвайт, чтобы присоединиться к группе или проекту. В таком случае пользователь увидит экран, блокирующий его дальнейшие действия. И будет неправильно просто написать «У вас нет прав!». 

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


Пустые результаты поиска

Примеры правильно спроектированных экранов с пустым результатом поиска


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

«Беру» при пустых результатах поиска показывает каталог товаров, чтобы помочь пользователю.

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


Возможно, пользователь ошибся при вводе, а может, у вас в базе нет данных, подходящих под запрос пользователя. Но в любом случае, одинокая строка «Данных не найдено» — это недружелюбное поведение системы. Если пользователь ошибся в букве, не надо за это его наказывать. 

Используйте «у��ный» поиск и на программном уровне исправьте ошибку. Или хотя бы добавьте милую картинку. Если система не может подобрать контент под запрос пользователя — напишите об этом и предложите аналогичные продукты.

В любом случае важно, чтобы пользователь чувствовал, что он владеет ситуацией. Иначе у него начнёт копиться негатив.


Не останавливайте путь пользователя

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

Вот как обычно выглядит путь пользователя:

Схема приложения, где страницы без контента являются тупиком в движении пользователя


И здесь пустая страница является тупиком в движении пользователя. А можно его направить на следующее действие.


Советы по проектированию правильной страницы-заглушки

Объясните ситуацию

Самое главное — расскажите пользователю, почему нет контента. Избегайте длинных формулировок. Не пишите очевидные вещи и не используйте технические термины. Представьте, что пользователь не знает, как работают приложение, сервера, интернет.


Предложите действие

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

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


Добавьте картинку

Аккуратная милая графика разрядит обстановку и понизит градус недовольства. А ещё с помощью картинки будет проще запоминать текст, потому что к нему прибавится визуальный образ. Используйте фирменные иллюстрации или котиков. 

Всё зависит от конкретной ситуации. Но картинка не должна перетягивать на себя все внимание. Не забывайте о действии. А если добавите ещё и анимацию, то сами влюбитесь в этот экран.


Будьте краткими

Пример правильно построенного текста, который начинается с цели


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


Всегда начинайте с цели

Пример правильно построенного текста, который начинается с цели


Сначала назовите цель, а уже потом опишите, какими действиями её достичь.


Будьте ближе к пользователю

Пример привычного для пользователя написания даты


Люди не используют дату, говоря о вчерашнем дне — они говорят «вчера». Применяйте тот же принцип в интерфейсе. Используйте существительные вместо числительных. Если в календаре на сегодня нет планов, так и напишите: «На сегодня еще нет планов», а не «13.02.2019 ничего нет». Так пользователю не придётся вспоминать, какое сегодня число. Но не забывайте учитывать часовые пояса и местное время пользователя.


Добавьте юмор

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


Упрощайте конструкции

Пример текста без лишних глаголов


Избегайте глаголы, если они не несут смысловой нагрузки.


Используйте соответствующий платформе язык

Термины, которые мы используем в описании десктопного приложения, могут не подходить к мобильным. Например, в случае с iOS-приложением мы говорим не «кликнуть», а «нажать» на иконку. (В английском click и tap). И наоборот.


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

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

А если вы ещё сомневаетесь, нужно ли вам заморачиваться с текстами, посмотрите, как одна маленькая фраза увеличила конверсию на 17%:

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


Во время конференции Google I/O 2017 Мэгги Стэнфил рассказала, как новый подход к написанию текста на интерфейсе улучшил их показатели.


Мы обнаружили, что на этапе поиска жилья кнопка Book a Room как будто к чему-то обязывает. Поэтому мы поменяли её на Check availability — и оказалось, что именно этого хотят пользователи, когда просматривают отели. Они всё ещё рассматривают варианты, и они хотят узнать, на какие даты жильё свободно и сколько оно будет стоить.

Мэгги Стэнфил (Senior UX Writer в Google)


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

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

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



Статью подготовил Игорь Васильев

Ссылка на источник

February 25, 2019
by Designdealer
0
384

Шрифты в адаптивном дизайне: как организовать работу

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

Проблема 1: разнообразие текстовых стилей

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

Обычно такой гайдлайн выглядит примерно так.

В чем тут проблема? Для параграфов дизайнер придумывает имена — bodyText, mainText, smallParagraph, factoidRedCenter, navigationLinks. Со временем количество таких стилей возрастает, следить за ними становится сложнее.

Бывает, что для очередного нового элемента придумывается стиль, который используется один раз на весь сайт, но занимает целую строку в гайде. Часто случается и наоборот: выбрав новый стиль для элемента, дизайнер не вносит его в гайд.

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


Решение: базовые текстовые стили

В html по умолчанию прописаны теги для иерархии из 6 заголовков. Для них заведены специальные теги — от <h1> до <h6>. Так было со второй версии html (1995 год), но при этом не была придумана иерархия для параграфов. Для текста есть только один тег — <p>.

Мы решили, что так не годится, и внутри себя придумали базовые стили для текста. Основной текст — p1. Помельче — p2. Еще мельче — p3. Ну вы поняли, да? Количество не ограничено.

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

Любой из этих стилей применяется к разным элементам. Например, стиль р2 ставится и в фактоид, и в узкую колонку, и как ссылка в футере.

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


Проблема 2: шрифты в адаптивном дизайне

Современные сайты адаптивны. Они создаются с расчётом не на одно разрешение экрана, а на брейкпоинты — 1920, 1366, 320. На каждом брейкпоинте происходит «перескок» от одной композиции экрана к другой.

В зависимости от задач мы используем от 3 до 6 таких «перескоков». Текстовые стили меняются от брейкпоинта к брейкпоинту. Уследить за всеми стилями, особенно если они не подведены к базовым, нелегко.

Дизайнерам нужно поддерживать гайд по текстовым стилям в актуальном состоянии в процессе адаптирования макетов под разные брейкпоинты. Любой неопределенный стиль в макете создает проблемы — на одном адаптированном макете он стал 16/24, на другом 14/22 — стили начинают «плясать».

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


Решение: таблица адаптивности текстовых стилей

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

Когда дизайнер рисует адаптивные макеты, встает вопрос о пропорциях в типографике. Например, если на десктопе размер шрифта 20, а интерлиньяж 28, то на мобилке размер шрифта ставится 14, а интерлиньяж выбирается рандомно — может 16, а может и 20.

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

Чтобы оптимизировать этот процесс, мы создали простенький скрипт, который вычисляет ratio — соотношения размера шрифта и интерлиньяжа. С этим инструментом ясно, что десктопный параграф размером 20/28 на мобилке будет 14/20.

Наш собственный инструмент для вычисления соотношений — https://readymag.com/kelnik/960360/


Так мы проходимся по всем стилям и выбираем соотношения для каждого брейкпоинта.


Как со стилями работают фронтендеры

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

Последним значением в строке идет массив с ratio — то самое соотношение кегля и интерлиньяжа. Если ratio не меняется от брейкпоинта к брейкпоинту, то удобно поставить просто число. Зная размер кегля и ratio, которое выбрал дизайнер, мы можем автоматически вычислить line-height.

Потом применяется миксин:

.b-block {

 @include font-size(‘p1’);

}

Если дизайнер придумает новый текстовый стиль, фронтендеру будет несложно добавить новое правило в такую таблицу.

Если дизайнер изменит уже использующийся стиль, то фронтендер просто изменит цифру в таблице — это пара пустяков.


Как со стилями работают дизайнеры

Мы работаем в Скетче и, откровенно говоря, работа с текстовыми стилями там организована на троечку.

Плюс: легко создать и применять иерархию стилей.

Минусы:

— инструмент для обзора/организации стилей примитивный,

— для любой декорации шрифта (вес, цвет, наклон, выравнивание) нужно создавать свой стиль.

Из-за особенностей Скетча таблица текстовых стилей разрастается.

К работе с такой таблицей нужно приноровиться. С помощью нескольких плагинов редактирование таблицы можно оптимизировать до приемлемого состояния.

Зато использовать в работе уже настроенные текстовые стили одно удовольствие.

Вид изнутри: как устроена работа с настроенными текстовыми стилями в Скетче


Плюсы и минусы базовых стилей и таблицы шрифтов

Если вы работаете над макетом в одиночку, проект разовый, и сайт не адаптивный, наш подход, скорее всего, вам не подойдёт. Но если в проекте много стилей и участников, а работа растянута по времени, таблица шрифтов существенно облегчает дело.

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

Подход далеко не идеальный. Для передачи макетов в вёрстку мы используем связку Скетч-Авокод, и есть большая проблема: в Авокод не передаются названия стилей. Для фронтендеров любой текст в Авокоде — просто набор css, а какой именно стиль — неизвестно. Фронтендер вычисляет нужный стиль из пропорции размера шрифта и интерлиньяжа.

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


Статью подготовил дизайнер Егор Горохов

Ссылка на источник

January 31, 2019
by Designdealer
0
470
Show more