{"id":13505,"url":"\/distributions\/13505\/click?bit=1&hash=ca3734639136826288c9056e5c8fa03a05e87c4060ae84df200f2c90f5262470","title":"\u0412\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a? \u0410 \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u0442\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432 \u0438\u0441\u043a\u0443\u0441\u0441\u0442\u0432\u0435 \u043a\u043e\u0434\u0430?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f5f0e11f-fefd-52f5-8712-82164a59b7ce","isPaidAndBannersEnabled":false}
Дизайн
KOSTYLNAYA

Одинаковые компоненты — разная специализация

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

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

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

Разработчикам важен нейминг инстансов [слоев] в Figma

Одно дело, когда поля значатся везде как «input», другое — когда каждое поле названо соответствующим и понятным образом. У каждого типа полей свой функционал, свое предназначение. Таким образом, мы продумываем и показываем, какой тип нужно использовать в том или ином случае. Важно помнить, что дизайнер — это еще и аналитик, который грамотно предоставляет разработчику необходимые инструменты.

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

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

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

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

Вывод

Компоненты могут выглядеть визуально одинаково, но иметь разное предназначение.

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

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

Таким образом, если я «достаю из широких штанин» Autocomplete [поле для контекстного поиска], он отображается на макете соответственно. Тогда разработчик, провалившись в определенную форму, сможет понять, какое конкретно поле ввода нужно использовать.

Смотрите и читайте другие мои материалы на youtube и в telegram.

0
4 комментария
Roman Trifonov
Первый тип отвечает за смену контента внутри одного блока, второй — за навигацию между страницами, третий — это якоря, которые помогают пользователю оперативно перемещаться по странице:

Ясно. Эвристик Нильсена не читали.

Users should not have to wonder whether different words, situations, or actions mean the same thing.
Ответить
Развернуть ветку
KOSTYLNAYA
Автор

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

Ответить
Развернуть ветку
Roman Trifonov

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

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

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

Ответить
Развернуть ветку
KOSTYLNAYA
Автор

Внес небольшое уточнение в статью

Ответить
Развернуть ветку
Читать все 4 комментария
null