Дизайн-паттерны: как создавать понятные интерфейсы

Всем привет! Меня зовут Игорь Артюхов, я Lead Designer в NIX.

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

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

Кнопки

Начну с вопроса: попробуйте для себя решить, какая из приведенных на иллюстрации кнопок лучше?

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

Следующий вопрос: какая из этих двух пар кнопок Skip и Sign Up с разными акцентами в оформлении лучше?

Пожалуй, многие бы проголосовали за первую пару. Я раньше тоже сделал бы так. Но сейчас я думаю иначе. Давайте поставим себя на место пользователя и посмотрим, что от нас хотят этим интерфейсом. А хотят от нас получить какие-то данные во время регистрации — и на этом делают акцент. Но можно же пропустить этот этап. Хорошо ли это? Да, ведь многие не любят при регистрации на сайте передавать ему личные данные. Когда мы рисуем такую иерархию кнопок, то решаем за пользователя, какое действие приоритетнее. Но почему бы не дать ему возможность выбрать самостоятельно? Сегодня это становится все более распространенным подходом. Например, у Nike мы видим две одинаковые залитые кнопки: «Зарегистрироваться» и «Узнать подробнее».

Точно так же поступают в Apple с кнопками «Узнать больше» и «Купить». При этом последняя кнопка не какая-то большая и красная, будто громко говорящая «Купи, срочно купи!». Пользователю тоже дается право решить, что ему сейчас важнее.

И снова вопрос: представим кнопки Cancel и Save — какую из них ставить первой?

Сложно сказать, должен ли пользовать сначала видеть «Отмена» или лучше первой разместить «Сохранить». Допустим, я вызываю некое действие. Что приоритетнее: получить в интерфейсе кнопку для целевого действия или возможность посмотреть все варианты ответа и только затем принять решение? Дизайнеры часто выбирают второй вариант, но в действительности это неважно.

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

Мне же очень нравится, как это реализует Apple на MacOS. Если вам дается какая-нибудь необратимая задача (как удаление файлов из корзины), акцент идет на отмене действия. То есть пользователь точно должен понимать: то, что он сейчас удалит, уже нельзя будет восстановить.

Итак, при работе с кнопками сделайте следующие шаги:

  • Решите, какая перед вами стоит задача, то есть к какому действию созданные кнопки должны подталкивать пользователя.
  • Убедитесь, можно ли показать, что кнопка — это кнопка через контекст использования интерфейса или через ее состояния.
  • Определите, понятен ли текст на кнопках? Правда, это уже обширная тема для отдельной статьи. Но я бы рекомендовал все равно об этом помнить, поскольку этот фактор влияет на понимание пользователем кнопки.

Навигация

Тему навигации тоже начну с примера-вопроса. Представим навигационный блок на сайте и логотип (на слайде это кружок). Где лучше разместить последний: по центру навигации или с левой стороны от нее?

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

На эту тему есть интересный эксперимент исследовательского центра NNM Group. Пользователям поставили задачу купить в интернет-магазине некий товар. При этом в списке магазинов не было популярных, а только небольшие. Логотип у одних сайтов был сбоку от навигации, у других — по центру. Пользователи покупали товар, но не знали, что проверяется в ходе эксперимента. Спустя некоторое время у них спрашивали название компании, на сайте которой они покупали товар. Результат: когда логотип был слева, люди лучше запоминали и бренд, и название компании. Поэтому весьма высока вероятность, что размещение логотипа слева чуть лучше — особенно не для самых известных компаний. Хотя это, конечно, не мешает огромному количеству сайтов размещать логотип по центру навигационного блока.

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

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

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

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

В таком случае есть несколько решений. Можно создавать несколько уровней меню. Пример — сайт New York Times. Здесь есть горизонтальная навигация сразу на главной странице, а слева вверху — еще бургер. По нажатию на него открывается большое меню, внизу которого размещен раздел More с дополнительными разделами. Это оправдано тем, что New York Times — большой ресурс, и показать всю навигацию невозможно. Потому в горизонталь вынесли приоритетные вещи, но показали, что есть и другие части. Кнопка вызова меню стоит в левом верхнем углу. Такое расположение элемента увеличивает вероятность того, что пользователь заметит меню и кликнет, если его не устроит основная навигация.

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

Что касается правила Хика, то как раз его действительно стоит принимать в расчет. Возможно, вам удастся разбивать весь интерфейс так, чтобы пользователь сначала делал выбор из 7-9 категорий каталога, потом из следующих 7-9, еще из 7-9 — и так далее до финиша. Хотя усложнять и выстраивать иерархию на 10-20 уровней тоже не надо, вряд ли это удобно. Я бы сказал, что 5 разделений каталога — вполне допустимо.

Но что делать, если подкатегорий реально много, и разумно разделить их по 7-9 пунктов не получится? Тут помогут два простых приема. Первый — алфавитный порядок. Второй — понятная терминология. Это можно увидеть на примере Amazon. Посмотрите на их раздел домашнего декора с множеством подкатегорий, расставленных в алфавитном порядке. Пользователю так гораздо легче находить товары. Главное условие: чтобы было правильное и знакомое пользователю название. То есть не стоит использовать жаргон, сленг, профессиональную терминологию.

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

Схожим образом поступает Avic. У компании львиная доля продаж приходится на технику Apple. Поэтому нет смысла разбивать такие товары или прятать, а лучше достать из каталога и вынести на самый вверх, увеличив количество категорий на главной странице. Кажется, что пользователю будет тяжелее сделать выбор. Однако если основная часть продаж связана с Apple, логично сразу предоставить этот раздел.

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

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

Перед тем, как приступить к работе с навигацией, пройдитесь по таким пунктам:

  • Есть ли на сайте что-то, что нежелательно прятать? Если сервис большой, подумайте о выборе метода для упрощения жизни пользователя: алфавитный порядок, вынесение важных пунктов выше, создание сложных «хлебных крошек» и т.д.
  • Придумайте, как показывать, где пользователь находится сейчас и куда он может перейти. Это очень важно, поскольку для всех интерактивных элементов следует обязательно разрабатывать состояния: обычное, при наведении, активное, недоступное, в процессе загрузки.
  • Определите, будете ли вы закреплять меню сверху, и что в него будет входить. Например, на многоязычном сайте где-то сверху справа наверняка будет размещен переключатель языка. Но нужно ли оставить возможность смены языка, если пользователь уже начал скроллить страницу? Скорее всего, если он уже скроллит, то язык его устраивает. Поэтому можно убирать этот пункт из прилипающего вверху меню. Но это все индивидуально. Как и порядок, в котором будут представлены страницы. Везде свои приоритеты.

Аккордеон

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

Исследования показывают: пользователи понимают, когда имеют дело с аккордеоном, и большинство кликает на текст. Когда иконка справа, на нее кликают в 25% случаях, на текст — в 75%. То есть не нужно размещать иконку с правой стороны? Нет, она спокойно может стоять именно там. На самом деле не так важно, где мы ее разместим, главное — разместить и сделать ее достаточно большой, чтобы на нее было удобно нажимать.

Единственное — при клике на иконку весь процесс идет чуть дольше. Это связано с тем, что люди целятся, пытаются нажать точно в иконку. Поэтому такой элемент надо сделать достаточно большим, чтобы было удобно работать с ним. Я бы предложил даже увеличивать не саму иконку, а кликабельную область. Мне нравится проект «Дія», где иконки большие, как и сам аккордеон. Этот сайт для всех пользователей будет, как мне кажется, понятным и удобным. Здесь каждая ячейка кликабельна и фактически занимает всю ширину экрана.

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

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

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

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

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

Аккордеон — многофункциональный инструмент. Его можно использовать не только для раздела с часто задаваемыми вопросами, но и страницы чекаута. Упомянутый ранее Baymard утверждает: больше 30% интернет-магазинов в мире делает чекаут в виде аккордеона, а в США этот показатель еще выше — 56%.

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

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

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

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

Также аккордеоны незаменимы для дизайна сайта в мобильных интерфейсах. Они позволяют легко скрывать часть информации. На сайте The Guardian вся навигация настроена через такие блоки. Единственное, что мне не нравится: родительские категории не кликабельны. Если пользователь хочет посмотреть все новости спорта, у него нет такой возможности. Он может перейти только в подкатегории «Футбол», «Крикет», «Регби» и т.д. Но в The Guardian вынесли родительские категории на главную, и это вполне рабочий вариант решения такой задачи.

А вот в The Wall Street Journal пошли другим путем. Они не стали выносить категории на главную и все собрали в одном блоке. Но когда пользователь переходит в какую-то категорию, там есть раздел Main. Благодаря этому можно перейти в главную родительскую рубрику или уйти в какую-нибудь подкатегорию.

Подведем итоги по аккордеонам и выделим ряд вопросов для размышлений:

  • Всегда задумывайтесь в самом начале, а нужен ли аккордеон вообще? Все-таки клик — это «плата за информацию» пользователя. Порой без нее можно обойтись и предоставить все данные сразу.
  • Подумайте, какую иконку использовать. Она может быть любой, но главное — на нее должно быть удобно нажимать.
  • Где разместить иконку? Это во многом зависит от того, как все будет адаптироваться. Допустим, если у вас очень длинная строка, то лучше ставить иконку слева. Тогда при схлопывании аккордеона в узкий блок и переносе текста на следующую строку не нужно думать о «съезжании» иконки.
  • Решите, будут ли все блоки по умолчанию закрыты или же первый открыт. Это зависит от вашей задачи и целей пользователя.

Дата

Следующий важный аспект в теме дизайн-паттернов — выбор даты. По традиции начну со сравнения. Этот пример наверняка знаком пользователям iOS 14, которые устанавливали время будильника. Какой вариант лучше?

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

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

Думаю, сейчас важно упомянуть способы получения информации от пользователя. Всего их четыре: календарь, барабан (в большей мере это мобильное решение), обычное поле ввода input и выпадающий список. Рассмотрим примеры разных решений — все они касаются авиабилетов. Так, Wizz Air используют календарь, причем двойной, чтобы пользователь видел сразу два месяца.

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

Компания Qatar Airlines пошла еще дальше и поставила дату старта и дату возвращения. При этом старт — сегодня. Но если пользователь заходит на сайт условно в 23:58, нужен ли ему такой вариант? Вторая проблема: нет различия даты начала, конца и всех дней между. Все залито одним цветом. Если планируется долгая поездка, которая начинается в одном месте и заканчивается в другом, то пользователи хотят видеть «якоря». Они условно говорят людям, что начинаем отсюда и заканчиваем здесь. Так пользователь будет уверен, что даты проставлены правильно.

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

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

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

Далее идет поле ввода. Если мы даем возможность юзеру вводить дату с клавиатуры, то надо подумать о формате. Допустим, «12.10.2021» в разных странах могут воспринять по-разному: у кого-то это 12 октября, а у кого-то — 10 декабря. В случае с примером сайта для аренды машины в другой стране это особенно важно. Пользователь должен понимать, с каким форматом он имеет дело. Некоторые в таком случае рекомендуют предлагать пользователю писать текстом. Но тут возникает вопрос локализации: поймет ли система, если это не универсальный английский, а более нестандартный язык? Ведь пользователь может писать еще и с сокращениями. Поэтому надо подсказать пользователю, как это делать, или выбрать другое решение — поставить рядом иконку календаря. Так человек сможет выбрать способ ввода данных.

В выпадающих списках нет ничего плохого, если они небольшие — как с месяцами. Но со временем может получиться чересчур большой список. Как пример: сайт «Укрзалізниці». Здесь диапазоном выбора является час, и список состоит из 24 пунктов. Вероятно, тут лучше использовать комбинированный подход, когда пользователь может ввести несколько цифр и выбрать что-то из списка.

Именно такой подход применяется в Google-календаре. Если начать писать 16 в поле ввода, появятся подвязанные варианты: 16:00, 16:15, 16:30, 16:45 (согласно заданному в системе шагу в 15 минут).

Подведем итоги по календарям:

  • При внедрении календаря обязательно просчитывайте, в каком формате будет дата, не забывайте о локализации, языке и способе указания, где будет день, а где — месяц.
  • Учитывайте, что начало недели в разных странах может быть разным — не с понедельника, а с воскресенья. Поэтому подумайте, давать ли пользователю настройку отображения календаря в привычном ему виде.
  • Выясните, должно ли у полей быть какое-то значение по умолчанию, если оно будет понятно пользователям, или же оставить все пустым на старте.
  • Решите, нужно ли и можно ли показывать недоступные дни. В некоторых случаях тут могут быть технические ограничения. Обращусь к упомянутым выше примерам. Если у SkyUp может быть не так много рейсов, то у Qatar Airlines их на порядок больше. Из-за этого не всегда возможно вытащить информацию о рейсе в календарь до отправки пользователем запроса на сервер.
  • Определите, надо ли открывать автоматически следующий этап ввода. Например, у Wizz Air после заполнения даты отправления поле для даты окончания откроется автоматически, а у МАУ для второй даты нужно еще раз нажимать на поле.
  • Что предоставить пользователю сначала: дату или время? Допустим, вы хотите записаться на курсы английского языка. У вас есть определенные рабочие часы, и вы хотите попасть на занятия до или после них, день вам подходит любой. Встает вопрос, что первично: дать человеку ввести время, а потом показать доступные дни для заданного графика или делать как-то иначе? При этом появляется еще один вопрос: как показывать выбранные и недоступные дни или другие метки? К примеру, в Google-календаре все хорошо разделено цветовыми метками: события, государственные праздники, приглашения на ивенты и т.д. Но при таком сценарии надо подумать над возможностью создания легенды, которая опишет все созданные вами метки.

Помните: дизайн-паттерны должны решать задачи пользователя

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Описание вырванное из контекста не имеет смысла, вы зря потратили время на написание статьи

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

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

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

Не знаю, як у UI-design, а в програмуванні словосполучення «дизайн-патерни» жорстко застовпили під 23 патерни проектування від Gang of Four.
Те, що ви називаєте «дизайн патерни», швидше за все, правильно називати Interaction Design Patterns або Usability Design Patterns, щоб не вводити в оману інших.

в програмуванні словосполучення «дизайн-патерни» жорстко застовпили під 23 патерни проектування від Gang of Four.

котре правильно називати Software Design Patterns. І пішли вони від патернів дизайну в архітектурі (The Timeless Way of Building). Тому коли ти з своїм софтом збоку примазався до дизайнерів — то хоч не май наглості на них наїздити.

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

Дякую за чудову і корисну статтю!

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

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

Щодо другого варіанту cancel і save, то він має місце тільки якщо місце для кнопок розділено порівно для обох кнопок, як в iOS. А якщо це показано як на малюнку то це мега не зручно, ти через раз пропускаєш кнопку save і не свідомо вибираєш cancel бо він знаходиться в інтуїтивному місці.

Мне нравится проект «Дія»

Собственно, дальше можно не читать

Пс: спасибо, посмеялся

Ну я же про дизайн) а ведь он получил одну из самых престижных премий Reddot

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

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

Це не кнопка
Це прямокутник зі скругленики кутами

Кнопкою він стає, коли з ним можна взаємодіяти

Существует правило трех кликов: пользователь должен доходить до нужной информации в три клика.
Однако этому нет подтверждений

лол-кек

Исследования показывают: пользователи понимают, когда имеют дело с аккордеоном, и большинство кликает на текст. Когда иконка справа, на нее кликают в 25% случаях, на текст — в 75%. То есть не нужно размещать иконку с правой стороны? Нет, она спокойно может стоять именно там. На самом деле не так важно, где мы ее разместим, главное — разместить и сделать ее достаточно большой, чтобы на нее было удобно нажимать.

Замість того щоб закцентувати увагу, що треба всю область зробити клікабельною, ви не зрозуміло нащо розказуєте про іконку (яку самі називаєте не важливою)

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

Другий варіант я вперше побачив на андроіді з кастомізацією HTC
Як на них матюкався
В ОС є стандартний меню для вибору датичасу — використовуйте його або дайте людині руками написати дату повністю числами і точками

Теперь поговорим о барабане. Через такой элемент можно вводить практически любую информацию

Замість натискання 3-4 клавіш — треба крутити барабан
При чому ви фіг з третього разу потрапите на цифру, що вам треба

Помните

Робіть A/B
Знаходьте живих користувачів, сідайте їм за спину і дивіться к вони працюють з тим г, що вам видав дизайнер

1. Тут задача на фантазию)
2. www.nngroup.com/videos/3-click-rule
3. Наличие иконки важно, поэтому на ней акцент. Не важно только где мы ее разместим
4. Это стандартные поля для выбора даты на iOS, они кстати с недавним обновлением первый вариант убрали с будильника и вернули второй. Видимо много жалоб было.
5. Субъективно
6. 100% согласен

1. Якщо ми все ще про UX — то ні. Менше алегорій — більше рефлексів
Ідеально — одна кнопка, яка сама себе нажимає

2. Я виділив болдом протиріччя в тексті. Якщо б називали це байкою чт в лапки взяли, то я б не мав притензій
btw, юзери не людять ходити по строннім посиланням ще більше xD
А так норм відос

3. А я казав про перпендикулярну річ, коли клікабельною роблять тільки іконку — і це десь на рівні 3×3 px кнопки закривання реклами

4. Завжди співчуваю власникам апла

5. Об’єктивно краще ввести цифри ніж крутити барабан і забути для чого це робиться
Навіть горизонтальний (плаский) диск, який зараз в андроіді програє вводу цифр

Вот еще паттерн табло (или как он у вас называется?) meduza.io

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