Дизайн
Angry
8667

Стандарты задротства: чек-листы UX-дизайна финсервисов и банков

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

В закладки
Аудио

«МТС Банк» обратился к нам с запросом сделать интернет-банк для бизнеса. У них уже был готовый UI Kit, поэтому от нас требовалось меньше по визуалу и больше по UX и проработке сценариев.

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

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

Три базовых принципа

1. Незначительных деталей не бывает

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

2. Минимум пространства для творчества

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

3. Дизайн — это не только экраны интерфейса, это любое касание с продуктом

Например, тексты ошибок, email, SMS, прерывания, валидация. Чаще всего их пишут разрабы или другие отделы. Разработчику проще самому доделать, чем тратить часы на коммуникацию и объяснение дизайнеру, где и что нужно доделать. Но это тоже часть опыта и тона продукта, который должен быть единым. Даже электронные письма лучше напишет продуктовый дизайнер с высокой компетенцией в текстах, чем маркетолог (с той же высокой компетенцией), который делает продающие рассылки.

Придумали метафору, которая отлично объясняет наш принцип построения лэйнов дизайна: «пользователь-задрот».

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

Главное правило для дизайнера: если пользователь может что-то сделать в сценарии и с чем-то столкнуться — он это сделает.

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

У UX-дизайнера 80% задачи занимает работа с данными — изучение текущих и построение структуры данных будущего сценария.

Входной информацией служат:

  • Аналитические данные. Информация о количестве кликов, переходов, ошибок, об использовании тех или иных функций или услуг. У каждого продукта и портрета пользователя аналитика отличается, но приоритеты обычно не меняются. Опираемся на наработанную базу статистических данных.
  • UX-исследования. За годы работы с финтех-компаниями провели сотни юзабилити-тестов и глубинных интервью. Знаем, как люди воспринимают тексты, какими терминами называют те или иные сущности, что важно на каждом шаге работы с каждой функциональностью. Всё это качественные инсайты, которых не получить из цифр.
  • Продуктовые метрики и транзакционные показатели. Это те самые вводные от бизнеса. У нас есть бэкграунд продуктовой разработки в «Модульбанке», «Точке» и ВТБ, поэтому цифры по всем продуктам и под каждый тип пользователя нам тоже известны. Они помогают приоритизировать бэклог, а в каждой задаче найти компромисс между «хотелками» пользователя и возможностями бизнеса.
  • Опыт конкурентов. Изучить, что и как у других — это святое. Полезно пройти опыт работы с сервисами конкурентов как пользователь, чтобы учесть их ошибки. Анализ того, как работают конкуренты — чуть ли не первое, что должен сделать дизайнер для погружения в сферу.

После сбора вводных приступаем к выполнению задачи. В проекте с «МТС Банком» было примерно 20 эпиков — больших задач, которые разбиваются на мелкие. Каждый эпик проходил через внутренний чеклист проектирования (а кроме него есть ещё чеклисты дизайна и работы с китом, текстов и типографики). Расскажем о девяти основных внутренних критериях проектирования.

1. Инфосхема или бизнес-процесс

Проектирование начинается с построения информационной схемы или бизнес-процесса по задаче. Дизайнер до 80% времени от задачи ещё до отрисовки сценариев тратит на изучение данных и продумывание информационной структуры. Исследования, цифры, аналитика, конкуренты, справочники, ресерч проблем в интернете — это всё информационное окружение дизайнера.

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

Бизнес-процесс проектируется для user story с разветвлённым сценарием и множеством альтернативных и негативных путей. Например, этапы открытия расчётного счёта. Каждый — это дерево с сотней ветвей, а для пользователя всё выглядит стройно и логично.

Объём сценария с этапами процесса открытия счёта

Инфосхема или бизнес-процесс включает в себя:

  • Вход и выход: страницы и места других сценариев, с которых начинается и которыми заканчивается текущий сценарий.

  • Наборы данных — конкретные элементы информации. Например, в выставлении счёта у блока данных «Товар или услуга» может быть количество, стоимость, название, единица измерения, сумма, НДС.
  • Ограничения или условия к элементам данных. Это те действия и условия, которые накладываются на каждый блок данных. Например, выставленный счёт не могут подписать более пяти пользователей. Номер счёта присваивается системой по порядку.
  • Логика — разветвление сценария в зависимости от выбора или условий.

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

2. Нулевые, минимальные и максимальные состояния

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

  • Как будет выглядеть элемент и страница, если в поле суммы ввести один рубль (min)? А если ввести 10 цифр с копейками (max)? Вопрос помогает не забыть написать соответствующие тексты ошибок.
  • Что увидит пользователь на главном экране мобильного банка, если название компании превышает 20 слов (max)? Если дизайнер не предусмотрел возможность сокращения, то пользователь увидит название на половине экрана. А что если у человека пять компаний и они начинаются с одних и тех же слов до сокращения? Стоит задуматься с точки зрения пользовательского опыта и об этом.
  • Какой будет страница истории документов, если в ней до сих пор не создано ни одного документа (zero)? Если дизайнер не продумал это состояние списка, пользователь увидит пустую страницу. А мог бы, например, вовсе её не увидеть или прочитать текст о том, для чего эта страница и как сюда попадут документы.

3. Альтернативные и негативные сценарии

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

4. Продумываем все входы и выходы

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

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

  • с главной страницы из меню;
  • из списка частых действий;
  • из истории документов и счетов в случае, если повторяет или делает счета на основе уже созданных.

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

Объём экранов, входы и выходы в задаче выставления счёта

5. Ошибки, прерывания и ограничения

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

  • Можно не ввести номер расчётного счёта.
  • Можно ввести его не полностью.
  • Можно ошибиться цифрой.
  • А можно ввести правильно, но где-то на стороне банка сломается алгоритм, который его проверяет.

Кроме того, в любой момент у пользователя может пропасть соединение с интернетом: что тогда произойдёт? Он просто потеряет настроенную выписку или заполненный платёж? Ему придётся вводить всю информацию заново? Это тоже нужно продумать.

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

  • Выписку можно отправить только на пять почтовых адресов за раз.
  • В выставленный счёт добавить только трёх подписывающих пользователей.
  • В назначение платежа можно ввести только 210 символов, ещё сколько-то останется на НДС.
  • У файлов есть форматы, размер и максимальное количество при загрузке в чат.

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

6. Типы пользователей

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

Например, при выставлении счёта:

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

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

Изменение статуса одного объекта приходит в разных текстах двум разным пользователям

7. Пишем тексты по всем каналам

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

  • Внутренние — то, что находится непосредственно в интерфейсе приложения: история действий, события в ленте, снеки, пуши, уведомления в чате.
  • Внешние — то, что «делает» продукт вовне и что пользователь получает от продукта через другие апы: SMS, email, мессенджеры.
  • Офлайновый — когда клиент взаимодействует с сотрудником сервиса вживую или по телефону. Здесь мы можем спроектировать процесс и данные, проходящие через колл-центр, но скрипты, конечно, будут писать профи в этой сфере. Где-то можно отрисовать карточки с промокодами, которые будут выдаваться при встрече. В любом случае, если не забывать, что у сервиса есть офлайновая часть процесса, продуктовый дизайнер придумает возможности, которые зацепят человека и сделают восприятие ещё круче.
Когда забронирован счёт, пользователю придёт короткое СМС об изменении статуса, письмо с реквизитами на почту и инструкция о том, что делать дальше и как можно использовать счёт уже сейчас.

8. UX-тексты в интерфейсе

Их ещё называют microcopy. Текст — это самый главный язык общения с пользователем. У нас интерфейсные тексты пишут UX-дизайнеры, и мы тратим немало ресурсов, чтобы обучить этому.

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

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

А вот пример перегруженного текста: «Комиссия составляет 230 ₽». Зачем слово «составляет»? «Комиссия — 230 ₽». И короче, и смысл не потерян.

Подробно о чеклистах по текстам в интерфейсе мы уже писали статью.

Написали про блокировки счетов и FAQ, как использовать карту ИП. Исследовали эти процессы и знаем все боли и страхи. А значит, можем на языке предпринимателя объяснить, как уберечься от беды

9. Спецификация к каждому экрану

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

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

Что описываем в комментариях к сценариям:

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

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

Почему нам это нравится

Наши критерии качества завышены, потому что основаны на западном подходе и понятии «дизайна», которое значит не просто сделать красиво в десятке уникальных экранов. А значит, что нужно продумать и спроектировать все варианты развития событий и написать всю коммуникацию и ToV. У нас этих экранов в 3–15 раз больше.

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

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

Это кейс «МТС Банка» на Behance — можете нас поддержать и подписаться, скоро выложим ещё два интересных объёмных проекта.

Проектируем финтех-сервисы
{ "author_name": "Angry", "author_type": "editor", "tags": [], "comments": 37, "likes": 47, "favorites": 315, "is_advertisement": false, "subsite_label": "design", "id": 120231, "is_wide": true, "is_ugc": false, "date": "Wed, 15 Apr 2020 07:54:07 +0300", "is_special": false }
Объявление на vc.ru
0
37 комментариев
Популярные
По порядку
Написать комментарий...
21

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

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

Ответить
3

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

Ответить
1

Еще и на английском. Батюшки. Интерфейс так интерфейс.

Ответить
0

Ну для справедливости стоит заметить, они пишут что использовали готовый UI-Kit МТС. Они его не разрабатывали, но вмешаться в него конечно стоило, потому что это видимо тот случай когда фирменный стиль убивает привычные паттерны юзабилити. 

Но больше вопросов вызывают подача информации. 

Ответить
0

Обновился ещё и дизайн приложения, UIX настолько so not frendly, что им пришлось писать отдельный мануал "что где искать"... 😆

Ответить
8

 А на деле обычный интерфейс

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

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

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

inb4: я у них работаю и оправдываю и оправдываю хипстеров от дизайна которые занимаются "просто здравым смыслом" вместо рисования логотипов и визуальных шедевров

Ответить
4

Преподноситься как 9 чудо света. А на деле обычный интерфейс. Вот были время...2000 год и интерфейс диабло 2. А тут 2020.

Ответить
4

Это точно. Применение здравого смысла преподнесено как академическое откровение )))

Ответить
2

Ну если для вас это видится как академическое откровение — что ж, материал и правда хороший, спасибо :)

Ответить
0

Если вы сарказм не понимаете, то тогда пожалуйста ))

Ответить
3

 Незначительных деталей не бывает

 Знаем, как люди воспринимают тексты, какими терминами называют те или иные сущности

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

То есть вместо ux тестирования и проработки реальных кейсов ребята потратили время на гипотетическую полировку вообще всего на базе собственного экспертного мнения?

Особенно мне нравится выравнивание сумм по левому краю, красота (нет).

Извините, но тут плохо все.

Ответить
0

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

Ответить
2

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

По вопросу выравнивания чисел — источников достаточно. Например:
Justification of Numeric Data. Justify columns of numeric data with respect to a fixed decimal point; if there is no decimal point, then numbers should be right-justified

Smith S. L., Mosier J. N. (1986) Guidelines for Designing User Interface Software (ESD-TR-86-278), Bedford: The MITRE Corporation
http://www.idemployee.id.tue.nl/g.w.m.rauterberg/lecturenotes/DA308/MITRE(1986)smith-mosier.pdf  

Ответить
0

ну не принимаете и не принимаете ))

Ответить
1

Так то он прав.
И еще (блок где сравнение Min/Max):
— Max обрезанный фрагмент, где мало что можно понять о вариантах этого сценария. В блоке min ни одного счета, в блоке max — 2 и все (остальное идентично или обрезано) сценарий выглядит не раскрытым.
— В Min есть dropdown "за все время" и он выглядит активным, хотя выбирать там не из чего (операций то нет). 
Там же справа: Потрачено 0 из 500 000 (за март) и 0 из 10 000 за сегодня. 490 000 рублей куда то пропало. 
Блок с визуализацией данных (потрачено/остаток) показан в блоке Min, но не показан в Max. Почему там "за Март" не понятно. Это текущий месяц или пользователь может выбрать? Если он может выбирать, тогда это должно быть согласовано с фильтром по дате.
Отдельный момент — визуализация gauge chart, крайне сомнительное решение (это подтверждено множеством исследований), не говоря уже о том, сколько места оно занимает (особенно в mobile).
— В Max снова не очевидный dropdown, где стоит "за все время" хотя ниже видно, что отображаются транзакции за "Сегодня, 11 Марта".
— В Max (следующий экран) — "последние счета" справа. Почему не "текущие" или "недавние", впрочем там даже фильтра нет и возможности поиска, хотя это очевидный функционал для практически любой таблицы с историей чего либо.
— В блоке Min (последние счета). Там нет абсолютно ничего. То что нарисован пустой экран с надписью "здесь появится" это не решение для empty state. Там может быть например какая то полезная информация. 
Не понятно почему, "закрыть карту", чуть ли не самая заметная ссылка на экране. Я конечно не знаком с исследованиями, возможно пользователи MTC банка закрывают карты каждый день по несколько раз. 

Ответить
0

Суммы как раз слева и должны быть, чаще всего поиск операции начинается с суммы и поиска пары «сумма+контрагент»

Ответить
0

Имелось ввиду другое. Как выравниваются сами суммы. Если используются копейки, то выравнивать числа более грамотно по правому краю, если копейки округляются, то можно по левому. И еще, разряды в числах стоит разделять с помощью thin space (это элементарно делается в вебе). 

Без описания слева от ошибки с количеством символов не понять, что проблема именно в этом и нужно сократить описание назначения платежа. Ничего не мешало написать по человечески а не "219/210" если уж говорить о microcopy. Да и в целом почему именно этот пример и почему само назначение платежа ограничено именно 210 символами? У меня как у читателя статьи это вызывает вопросы, почему не 240? У пользователя это тоже  будет вызывать вопросы и раздражение, особенно если он часто заполняет эту форму (да каждый день может быть заполняет, и каждый раз думает о том, как бы в поле "назначение платежа" все влезло). Разбираться с этими деталями это и есть UX дизайн, а вывод красных чисел при ошибке в форме это стандартный функционал любых форм с автовалидацией. 

Это к тому, что "Незначительных деталей не бывает"

Ответить
0

240 символов это нормативное требование к форме платежного поручения и бухгалтер это знает, ну и в целом это уже стандарт обозначения количества символов в поле

Ответить
0

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

Ответить
1

новый ИП в онлайн-банках скорее всего уверенный пользователь ПК и знает, что вот эти серенькие цифорки в углу, уменьшающиеся в момент печати символов - ограничение количества символов) у Angry достаточно богатый опыт, чтобы судить о пользователях

Ответить
–1

уверенный пользователь ПК

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

Даже если так, это не повод выдавать встроенный дефолтный функционал автовалидации формы за свое UX-решение. 

Ответить
0

Вы когда-нибудь делали платеж в интернет-банке ООО или ИП?) 210 символов это больше двух строк в ворде 12 кеглем и в назначении платежа столько не нужно. Обычное назначение это "оплата по счету номер, от даты. НДС не облагается"

Ответить
–1

Напомню вопрос был в том, что в качестве примера детальной проработки UX (в этом случае об ограничениях) в статье приводиться: а) дефолтный функционал б) этот дефолтный функционал не проработан. А вы отвечаете что то типа "да и не надо ничего делать, все пользователи и так все знают"

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

Ответить
1

Вопрос практикующим UX/UI дизайнерам: объясните пожалуйста, как такой элемент интерфейса мог родиться в дизайн-отделе Яндекса? Он находится тут — https://yandex.ru/jobs/vacancies/design

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

Почему нельзя сделать обычный выпадающий список (с выбранным значением по умолчанию "Любой", а рядом (сверху/слева) указать его название "Сервис"? Т.е. во всех этих списках выбор УЖЕ сделан, но пользователь его даже не видит. Слом мозга.

Ведь это кто-то задизайнил, утвердил...

Ответить
4

Если вместо «Сервис» написать «Любой», то поле ни о чем не будет говорить (любое что?). А если сверху лейблы подписать, то будет так «Город/Любой», «Сервис/Любой» «Уровень/Любой». 

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

Ответить
0

Вы так говорите, будто именно такое меню это единственное возможное решение. Кстати, вся страница даже не responsive 

Ответить
1

Конечно, не единственное, но в данном случае претензия необоснованная.

Ответить
0

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

Ответить
2

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

Ответить
1

Как же я обожаю всю эту водичку с диаграммами, миллионом юзер ресерчей и так далее. Все кругом специалисты высшего уровня, а потом лепят какое-нибудь вырвиглазное говно. У меня сейчас был "случай" на работе в январе, когда меня наняли вместе с другими людьми наследовать проект от очень дорогих и крутых консультантов, которые провели этот самый проект через инкубационную фазу. У них там работало много-много инженеров, продактов и дизайнеров, были постоянные юзер ресерчи, они даже сами целой командой летали на Бали (из Сингапура) делать эти ресерчи прям на улицах (тревел продукт) и все было жуть как круто! За 9 месяцев такой вот "профессиональной" разработки им отгрузили в районе 15 миллионов баксов.

А потом мы, будучи новой командой, приняли проект, и выяснили что всё что они сделали оказалось говном собачьим. Вот буквально по всем фронтам было перегруженное и неюзабельное дерьмище, но самые большие дыры были именно по части UX. В итоге вся их работа и 15 лямов ушли в помойку, ибо мы начали переписывать всё с нуля. Так что теперь у меня аллергия на все эти тексты и фразочки про "нам надо провести UX исследования, сделать юзер-сторис, еще кучу всякой хероты, миллион диаграмм и в конце мы вам нарисуем несколько макетов сомнительного качества".

Вместо тысячи слов лучше увидеть своими глазами - https://app.pelago.com.sg/
Там, внимание, ОБЯЗАТЕЛЬНА регистрация и логин. Это b2c продукт если что, аля Booking для бронирования аттракционов и прочего. Надеюсь, когда-нибудь я узнаю что произошло во время разработки этой катастрофы...

Ответить
1

Здесь только про web или про mobile тоже? Если тоже, то там треш

Ответить
0

здесь только на примере веба

Ответить
1

Как всегда круто! Сколько времени ушло с готовым китом?

Ответить
0

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

Бесплатный совет дизайнерам: осторожнее с юмором — не все такие «остроумные».

Ответить
0

Спасибо за статью! И подход у вас правильный. 

Ответить
0

спасибо за поддержку :)

Ответить

Прямой эфир