Русский
Русский
English
Статистика
Реклама

Проектирование взаимодействия

Перевод 20 психологических уловок в дизайне продуктов

31.08.2020 14:14:39 | Автор: admin

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



Несколько лет назад коллега из моей бывшей компании (BlaBlaCar) познакомил меня с игрой Mental Notes. Разрабатывая какую-либо функцию, мы вместе с несколькими менеджерами по продукту, дизайнерами и разработчиками делали поведенческий анализ, во время которого старались понять, как и какие принципы поведенческой психологии можно применить в проекте.

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

Для справки: представленные далее темы и их описания взяты из колоды карт Mental Notes.


Социальное доказательство


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

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

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


Приложение для медитации Petit BamBou

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


Страницы с ценами в мобильных приложениях The Athletic и MasterClass

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


Любопытство


Если человека подразнить интересной информацией, он захочет узнать больше!

Именно это делает фитнес-приложение Strava в своей функции Анализ темпа: вам дают предпросмотр того, как выглядит график, но не более того. Чтобы увидеть подробный анализ, нужно купить подписку Summit.


Анализ темпа в Strava триггер, побуждающий подписаться на премиум-версию

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


Веб-сайт Wall Street Journal

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


Узнать проще, чем вспомнить


Пережитое ранее легче узнать, чем вспомнить.

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

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


Система оценок Airbnb

Поэтому и страховой стартап Lemonade предлагает несколько предопределенных категорий дорогостоящих предметов.


Последний этап процесса запроса расценок в Lemonade

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


Приятные моменты


Мы вспоминаем и положительно реагируем на небольшие, неожиданные и веселые приятные моменты.

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


Скриншоты приложения Zenly

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


Если включить композицию из плейлистов Звездных войн на Spotify, то панель воспроизведения превратится в световой меч.


Привязка и приспосабливание


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

Например, при покупке ноутбука на сайте Apple.com вам предлагают множество вариантов (200 $ мощнее процессор, 100 $ лучше видеокарта, 400 $ больше объем диска, 299,99 $ предустановленный Final Cut Pro X, 199,99 $ Logic Pro X). Если брать по отдельности, то за всё получится внушительная сумма. Но вы уже сделали мысленный скачок и платите за ноутбук 2799 $, поэтому кажется, что каждая опция не так уж и дорого, верно?



Тот же подход применим, когда вы платите 150 $ за продукты на кассе, и вам предлагают пожертвовать на благотворительность 0,50 $ не такая уж и большая сумма относительно всего чека, верно?


Умеренные трудности


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

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




Эстетика как удобство использования


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

Привлекательные элементы воспринимаются нами как более удобные в использовании. Приложение-календарь Sunrise, купленное Microsoft в 2015 г. за более чем 100 млн долл., на тот момент было лучшим в своей категории на платформах iOS и Android: тысячи пользователей хвалили его за понятный и удобный интерфейс.



Но действительно ли возможности Sunrise такие уникальные? В приложении было несколько удобных функций например, интеграция с событиями в Facebook. Но ничего сверхнеобычного там не было в том числе ничего, что календари от Apple или Google не могли бы скопировать за пару недель.

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


Установление ценности


Мы ценим то, что стоит дороже.

Стоимость может выражаться и в деньгах, и во временных затратах.

В отношении денег можно привести множество не самых интуитивных примеров, когда компании повышали конверсию и (или) доход, просто подняв цены. В книге Не сходите с ума на работе Джейсон Фрайд и Дэвид Хайнемайер Хенссон рассказывают, что повышение начальной цены Basecamp с 29 $ до 99 $ в месяц позволило привлечь новых клиентов: иногда чем выше стоимость, тем более полезным кажется продукт.


Страница с ценами Basecamp

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


Боязнь потери


Мы не любим терять или упускать то, что уже имеем (даже если есть возможность получить больше).

Хороший пример этого психологического трюка часто можно увидеть при отмене подписки на некоторые сервисы. Например, если вы решите отменить тарифный план Adobe Creative Cloud, вы увидите следующее:


Процесс отмены подписки на Adobe Creative Cloud

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

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



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

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


Контраст


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

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



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

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

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


Регулярные события


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

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




Последовательность действий


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

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

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


Процесс регистрации в N26 в 2018 г.

На веб-сайте они даже дают такую рекламу: Банковский счет в N26 за 8 минут.



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


Ограниченный выбор


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

В последние годы некоторые компании смогли сформировать свое ценностное предложение на упрощении количества предлагаемых вариантов.

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


Результаты поиска в приложении Virtuo

Если вам дается ограниченный выбор, вы с большей вероятностью примете решение.

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


Репутация


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

В качестве примеров продуктов, опирающихся на понятие репутации, можно назвать Reddit и StackOverflow: за публикации и комментарии пользователи либо зарабатывают репутацию (получая положительные голоса, значки, трофеи, медали), либо теряют ее (получая отрицательные голоса).



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


Авторитет


Мы предпочитаем следовать примеру и советам признанного авторитета.

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

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

AirHelp понимает эту проблему поэтому они добавляют в процесс запроса элементы, обосновывающие его авторитетность:

  • Они упоминают регламент EC261.
  • Они дают возможность пообщаться с человеком: Джейн ваш помощник в AirHelp.



Первая страница процесса оформления заявки на компенсацию на сайте AirHelp

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


Ограниченный доступ


Мы естественным образом хотим то, что считаем эксклюзивным или принадлежащим избранному обществу.

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



Приложение Inbox в итоге кануло в лету: компания Google закрыла его в 2019 г. Сервис предлагал пару новых (в сравнении с Gmail) функций, но ожидаемой революции в электронной почте он не произвел. Тем не менее, продвижение этого продукта на рынке было успешным. Подобный ажиотаж сейчас наблюдаются вокруг Superhuman и Clubhouse.

Еще один пример ограничения доступа сообщество дизайнеров Dribbble.


Главная страница Dribbble

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


Самовыражение


Мы ищем возможность выразить свою личность, свои чувства и мысли.

Это очень мощный принцип, который работает во всех возрастных группах.

Приложения, ориентированные на подростков, почти всегда дают возможность настроить профиль: изменить цвета, аватар, добавить классные аксессуары и т. д. Примеры Pokmon Go, Snap (с Bitmoji) и (совсем недавно) Stadium Live.


Настройка аватара в Stadium Live

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


Настраиваемые рамки для фото в профиле Facebook

Среди SaaS-инструментов также можно найти такие примеры: Trello дает пользователям возможность менять цвет и изображение фона, Slack предлагает множество тем для настройки интерфейса.

Использование принципа самовыражения укрепляет связь между продуктом и пользователями.


Дефицит


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

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



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

  • Забронировано 27 раз за последние 6 часов (эта фраза также применяет принцип социального доказательства).
  • Большой спрос: на сайте осталось всего 7 номеров!

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


Юмористический эффект


Поданная с юмором информация запоминается легче и радует пользователя.

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

Например, при поиске маршрута из пункта А в пункт Б иногда можно использовать функции Телепорт, Катапульта или Реактивный ранец и тогда Борис Джонсон переместится из А в Б менее чем за 5 секунд.


Предложение катапультировать Бориса Джонсона и правда звучит забавно.

Citymapper и платную подписку строит частично на таком юмористическом подходе.


Платная подписка Citymapper Citymapper CLUB

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


Непредсказуемые вознаграждения


Случайные вознаграждения сильные мотиваторы: они кажутся редкими и отличаются непредсказуемостью (а также реже противоречат внутренней мотивации).

Один из элементов, благодаря которым Snapchat завоевал пользователей, это трофеи.


Трофеи в Snapchat

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

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

Подробнее о непредсказуемых вознаграждениях и геймификации в этой колоде в целом пишет Mozza: Mobile Gamification How The Best Apps Nailed It (Waze, Duolingo, Tinder, Snapchat, LinkedIn, Zenly).



Надеюсь, вам понравились эти примеры! Может, и вы знаете примеры реализации психологических принципов в дизайне продукта? Расскажите о них!

Если вас заинтересовали Mental Notes и соответствующая карточная колода, то, к сожалению, заказать ее уже нельзя. Но похожую информационную подборку можно найти здесь: плакат Persuasive Patterns Poster от UI Patterns.

Если вам понравилась эта статья и вас интересует применение психологии в дизайне продуктов, я рекомендую зайти на отличную страницу Growth.design The Psychology of Design, где составлен еще более длинный список (101 пункт!) когнитивных искажений и принципов, влияющих на удобство пользования.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее
Подробнее..

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

02.10.2020 12:06:25 | Автор: admin

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

Возможности человеческой памяти ограничены

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

У человека два вида памяти.

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

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

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

Рабочая память малоемкая и неустойчивая. Специалист по когнитивной психологии Джордж Миллер в 1956г. в книге о волшебном числе 7 предположил, что средний человек может удерживать в краткосрочной памяти около 7объектов (плюс-минус 2).

Если дизайн разработан таким образом, что пользователю в рабочей памяти требуется в течение более чем 7секунд держать более 3объектов или 1объект в течение более чем 70секунд, то будут появляться ошибки: информация в рабочей памяти очень легко теряется.

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

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

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

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

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

Факторы, влияющие на работу памяти

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

Перечислю некоторые факторы, которые влияют на рабочую память:

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

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

Какое изображение запомнить легче: левое или правое?Какое изображение запомнить легче: левое или правое?
  • Повторение. Повторение объектов может приводить к ошибочному воспоминанию в рабочей памяти. Например, если нужно запомнить число 5774, вы можете запомнить его как 5744.

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

  • Прерывание. Прерывание мешает вносить информацию в рабочую память особенно когда внимание нарушается во время работы с информацией.

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

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

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

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

Подходы в дизайне интерфейса, облегчающие работу памяти

Мы уже выяснили, что рабочая память хранит мало и недолго, а у долговременной памяти много слабых мест и на первых этапах запоминания она ненадежна. Дизайнер должен помочь пользователю запомнить важную информацию до момента, когда она понадобится. Нельзя требовать запоминать состояние системы или выполненное действие. Вот некоторые подходы, которые помогут снизить нагрузку на рабочую память пользователей (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге):

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

Примеры отображения предыдущих поисковых запросов в Google Картах и Pinterest.Примеры отображения предыдущих поисковых запросов в Google Картах и Pinterest.
  • Визуальное эхо. Пользователь с легкостью может повторно просмотреть визуальный материал. Поэтому, давая звуковой контент, необходимо также делать визуальное эхо, передающее то же сообщение: визуальный материал можно легко повторно просмотреть, а звуковой нет.

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

Автор Vishnu Prasad, источник https://dribbble.com/shots/9866905-Final-steps-in-OnboardingАвтор Vishnu Prasad, источник https://dribbble.com/shots/9866905-Final-steps-in-Onboarding
  • Буквы вместо цифр. Обычно буквы человеку запомнить проще, чем цифры. Поэтому, например, рабочий номер телефона лучше записывать не как 467-968-2378, а как 467-YOU-BEST.

  • Снижение путаницы в рабочей памяти. Чтобы снизить путаницу, можно обеспечить пространственное разделение. Например, при проектировании интерфейса его можно разбить на части таким образом мы даем мозгу зацепку для различения сигналов и снижения путаницы между объектами.

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

Чтобы дизайн помогал работе долговременной памяти, нужно в первую очередь избегать разработки систем, которые повышают нагрузку на память этого вида. Для этого можно применять следующие подходы (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге) как вы увидите, именно так работают многие интерактивные системы.

  • Поощряйте пользователей использовать информацию регулярно. Частое воспоминание повышает силу информации в долговременной памяти.

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

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

Примеры из Google и Instagram.Примеры из Google и Instagram.
  • Развивайте полезные привычки. Разрабатывая интерфейс, мы учитываем его контекст, повторяемое использование функций и вознаграждаем пользователей, с тем чтобы закрепить нужное поведение и пресечь нежелательное.

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

  • Единообразная работа в рамках системы и с другими приложениями. Чем единообразнее работа разных функций и действия с объектами разных типов, тем меньше пользователю нужно запоминать. В интерфейсе со множеством исключений и низким уровнем единообразия между функциями и объектами различных типов пользователю приходится хранить в долговременной памяти особенности каждой функции и каждого типа объектов, а также правильный контекст использования. Необходимость запоминания большого количества информации затрудняет изучение таких интерфейсов. (Джонсон, 2014; подробнее в книге.)

Дизайн должен соответствовать знакомой пользователю ментальной и концептуальной модели. Простой пример: круглые переключатели позволяют выбрать один вариант, флажки в квадрате несколько. Источник https://www.justinmind.com/blog/mental-models/

Литература:

John D Lee, Christopher D. Wickens, Yili Liu, Linda Ng Boyle (2017). Designing for People: An Introduction to Human Factors Engineering 3rd Edition.

Джефф Джонсон (2014). Умный дизайн. Простые приемы разработки пользовательских интерфейсов.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимаетсялокализацией игрприложений и сайтовна 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаемрекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Перевод Тёмные паттерны в знакомых приложениях

25.03.2021 16:19:55 | Автор: admin

Не путать с тёмным режимом!

Шумиха вокруг Социальной дилеммы заставила многих осознать силу технологий и их влияние на всех нас. Для UX-дизайнеров использование нечестных уловок на цифровых платформах не новость: мы называем такие хитрости тёмными паттернами.

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

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

Замаскированная реклама в YouTube

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

Автор (правообладатель): YouTube. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): YouTube. Условия лицензии и защиты авторского права: добросовестное использование.

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

Тараканья ловушка (Spotify)

Тараканья ловушка такой дизайн, который упрощает попадание в определенную ситуацию, но затрудняет выход из нее (например, оформление подписки).

Помните, как создается аккаунт Spotify? Вряд ли: вы наверняка использовали OAuth и сразу же вошли через аккаунт Facebook. А если нет заполнили небольшую форму, указали регистрационные данные и всё. А как удалить аккаунт Spotify? Если вы пытались это проделать, наверняка помните, что пришлось постараться.

На веб-странице Spotify легко понять, как войти или зарегистрироваться. На панели навигации есть понятные кнопки и еще выделенная кнопка в центре экрана.

Автор (правообладатель): Spotify. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Spotify. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Spotify. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Spotify. Условия лицензии и защиты авторского права: добросовестное использование.

Если нажать кнопку входа, вы обнаружите, что для использования Spotify не нужно создавать аккаунт можно войти через аккаунт Facebook, Apple или Google. Просто и удобно, правда?

А вот удалить аккаунт Spotify то еще испытание. Нужно всего лишь выполнить следующее:

  1. Перейти на страницу support.spotify.com/us/contact-spotify-support/.

  2. Нажать Войти справа вверху и ввести свои учетные данные.

  3. Нажать пункт Подписка.

  4. Выбрать вариант Я хочу удалить аккаунт.

  5. Нажать Удалить аккаунт.

Автор (правообладатель): Spotify. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Spotify. Условия лицензии и защиты авторского права: добросовестное использование.

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

Заманить и подменить (Reddit)

Заманить и подменить: вы хотите сделать одно, но вместо этого выполняете другое, нежелательное действие.

Автор (правообладатель): Reddit. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Reddit. Условия лицензии и защиты авторского права: добросовестное использование.

Листая ленту Reddit, можно раскрывать изображения, нажимая на них. Однако в ленте Reddit есть множество рекламных записей, и если пользователь нажимает на картинку такой записи, вместо стандартного поведения (развертывание изображения) открывается какой-нибудь рекламный веб-сайт.

Тараканья ловушка (Instagram)

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

Выдержка из справочной документации InstagramВыдержка из справочной документации Instagram

Принудительное продолжение (Skillshare)

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

Автор (правообладатель): Skillshare. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Skillshare. Условия лицензии и защиты авторского права: добросовестное использование.

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

Подтверждение с укором (Wish)

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

Автор (правообладатель): Wish. Условия лицензии и защиты авторского права: добросовестное использование.Автор (правообладатель): Wish. Условия лицензии и защиты авторского права: добросовестное использование.

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

Предотвращение сравнения цен (AliExpress)

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

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

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

Скрытые затраты (Broadway.com)

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

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

Об авторе

Мариана Варгас UX-специалист и певица из Лиссабона (Португалия). С ней можно связаться через LinkedIn.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Чего ждать при работе с API 5 (не)обычных проблем при интеграции приложений

24.10.2020 12:06:33 | Автор: admin

Где-то на просторах мультивселенной

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

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

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

Проблема #1: external_id курильщика

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

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

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

Проблема #2: нет разделения моделей для запросов и ответов

Иногда в документации к API описываются модели, которые используются и в запросах к серверу, и в ответах я называю такие модели Jack of all trades (мастер на все руки). Ничего страшного в этом вроде нет, ровно до тех пор, пока у нас не появляются объекты вроде{ foo:value1, bar:value2 }, где поле foo заполняется в моделях запроса, а bar - в ответах сервера. Но это уже выясняется эмпирически в процессе интеграции.

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

Проблема #3: избыточная защита в неожиданных местах

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

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

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

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

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

А вы часто встречаете реализацию защиты от MITM-атаки при обработке коллбека?

Проблема #4: изменение типа в зависимости от параметров

{transaction: {id:1}}

{transaction: [{id:1}]}

Как вам метод, который в зависимости от параметра в запросе будет возвращать в одном из полей ответа либо объект, либо массив, содержащий в себе один элемент?

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

Особенно неприятно то, что, при работе с JSON, например, через библиотеку Newtonsoft Json.NET вы будете получать высокоуровневую ошибку десериализации поля, а дальше долго и вдумчиво всматриваться в два одинаковых объекта, пока глаз не заметит пресловутую пару квадратных скобок

Проблема #5: делегированная безопасность

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

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

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

Заключение: как всё исправить

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

Поэтому возникает вопрос, а всегда ли мы при создании API думаем о его конечных пользователях? Чтобы сделать интерфейс по-настоящему удобным, стоит учитывать ряд моментов:

  • Внутренняя кухня приложения не должна влиять на интеграцию. Обеспечение уникальности в течение интервала ~N явно как-то связано с ненужными внешнему пользователю особенностями системы. Функции external_id должны быть одинаковыми на протяжение всего времени жизни сущности в системе.

  • Контекст моделей запросов и ответов нужно разделять. Может показаться, что это сильно избыточно. Однако в конечном итоге, максимальная прозрачность в вопросе использования моделей даёт плюсы не только потребителям API, но и разработчикам.

  • Выбирайте подходящие методы защиты. Реализуя защиту от какой-либо атаки задумайтесь, действительно ли этот вектор атаки актуален в реализуемом вами сценарии.

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

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

А какие трудности при работе над интеграционными проектами встречались вам? Делитесь описанием и своими решениями/советами в комментариях сделаем материал полезнее.

Подробнее..

Как работать с ошибками бизнес-логики через HTTP

09.03.2021 20:23:18 | Автор: admin

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры "дергают" бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

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

1: HTTP статусы

Если почитать апологетов REST, то для кодов ошибок надо использовать HTTP статусы, а текст ошибки отдавать в теле или в специальном заголовке. Например:

Success:

HTTP 200 GET /v1/user/1Body: { name: 'Вася' }

Error:

HTTP 404 GET /v1/user/1Body: 'Не найден пользователь'

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

Http статусы предназначались для описания ошибок при передаче данных, а про логику вашего приложения никто не думал. Статусов явно не хватает для описания всего разнообразия ошибок в вашем проекте, да они и не были для этого предназначены. И тут начинается натягивание "совы на глобус": все начинают спорить, какой статус ошибки дать в том или ином случае. Пример: Есть API для task manager. Какой статус надо вернуть в случае, если пользователь хочет взять задачу, а ее уже взял в работу другой пользователь? Ссылка на http статусы. И таких проблемных примеров можно придумать много.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

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

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

HTTP 400 PUT /v1/task/1 { status: 'doing' }Body: { error_code: '12', error_message: 'Задача уже взята другим исполнителем' } 

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

if (status === 200) {  // Success} else if (status === 500) {  // some code} else if (status === 400) {  if (body.error_code === 1) {    // some code  } else if (body.error_code === 2) {    // some code  } else {    // some code  }} else if (status === 404) {  // some code} else {  // some code}

Из-за этого ветвление клиентского кода начинает стремительно расти: множество http статусов и множество кодов в самом сообщении. Для каждого ошибочного http статуса необходимо проверить наличие кодов ошибок в теле сообщения. От комбинаторного взрыва начинает конкретно пухнуть башка! А значит обработку ошибок скорее всего сведут к сообщению типа Произошла ошибка или к молчаливому некорректному поведению.

Многие системы мониторинга сервисов привязываются к http статусам, но это не помогает в мониторинге, если статусы используются для описания ошибок бизнес логики. Например, у нас резкий всплеск ошибок 429 на графике. Это началась DDOS атака, или кто-то из разработчиков выбрал неудачный статус?

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

2: На все 200

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

Вариант 1:

Success:HTTP 200 GET /v1/user/1Body: { ok: true, data: { name: 'Вася' } }Error:HTTP 200 GET /v1/user/1Body: { ok: false, error: { code: 1, msg: 'Не найден пользователь' } }

Вариант 2:

Success:HTTP 200 GET /v1/user/1Body: { data: { name: 'Вася' }, error: null }Error:HTTP 200 GET /v1/user/1Body: { data: null, error: { code: 1, msg: 'Не найден пользователь' } }

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

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

module.exports = {  NOT_FOUND: 1,  VALIDATION: 2, // .}module.exports = {  NOT_FOUND: NOT_AUTHORIZED,  VALIDATION: VALIDATION, // .}

Клиентские разработчики просто основываясь на кодах ошибок могут создать классы/типы ошибок и притом не бояться, что сервер вернет один и тот же код для разных типов ошибок (из-за бедности http статусов).

Обработка ошибок становится менее ветвящейся, множество http статусов превратились в два: 200 и все остальные (ошибки транспорта).

if (status === 200) {  if (body.error) {    var error = body.error;    if (error.code === 1) {      // some code    } else if (error.code === 2) {      // some code    } else {      // some code    }  } else {    // Success  }} else {  // transport erros}

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

Но неудобства тоже есть:

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

  • При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

  • Мониторинг теперь точно будет срабатывать только на ошибки транспорта, а не бизнес-логики, но для мониторинга логики надо будет дописывать парсинг тела сообщения.

В некоторых случаях данный подход вырождается в RPC, то есть по сути вообще отказываются от использования url и шлют все на один url методом POST, а в теле сообщения передают все параметры. Мне кажется это не правильным, ведь url это прекрасный именованный namespace, зачем от этого отказываться, не понятно?! Кроме того, RPC создает проблемы:

  • нельзя кэшировать по http GET запросы, так как замешали чтение и запись в один метод POST

  • нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

  • имеются проблемы с документированием swagger и ApiDoc не подходят, а удобных аналогов я не нашел

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

3: Смешанный

Возьмем лучшее от двух миров. Мы выберем один http статус, например, 400 или 422 для всех ошибок бизнес-логики, а в теле ответа будем указывать код ошибки или строковую константу. Например:

Success:

HTTP 200 /v1/user/1Body: { name: 'Вася' }

Error:

HTTP 400 /v1/user/1Body: { error: { code: 1, msg: 'Не найден пользователь' } }

Коды:

  • 200 успех

  • 400 ошибка бизнес логики

  • остальное ошибки в транспорте

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

if (status === 200) {  // Success} else if (status === 400) {  if (body.error.code === 1) {    // some code  } else if (body.error.code === 2) {    // some code  } else {    // some code  }} else {  // transport erros}

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска стрельбы некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

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

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

P.S. Иногда ошибки любят передавать массивом

{ error: [{ code: 1, msg: 'Не найден пользователь' }] }

Но это актуально в основном в двух случаях:

  • Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

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

В противном случае нет особого смысла закладываться сразу на массив ошибок, потому что базовая валидация данных должна происходить на клиенте, зато код упрощается как на сервере, так и на клиенте. А user-experience хакеров, лезущих напрямую в наше API, не должен нас волновать?HTTP

Подробнее..

Из песочницы Улучшение UX мобильного приложения на реальном примере

05.10.2020 02:05:55 | Автор: admin

Введение


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

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

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

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

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

Этап 1. Подготовка и планирование деятельности


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

Структурирование хаоса и прорисовка карты боя


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

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



Например, пункт 0.4.1 Перевозчики (Интервью с пользователями). Я создам отдельную папку, куда положу следующие документы:

  • Список контактных лиц и их реквизиты
  • Список вопросов и ответов
  • Фотографии и прочие материалы, полученные в процессе опроса

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



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

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

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

Приоритезация задач


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

У Mindjet есть удобная функция просмотра приоритета задач, вид показать иконки.



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



Контроль сроков и прошивка календаря


Если Вы работаете в заказной разработке и ваша работа фиксируется сроками договора. А точнее дополнительного соглашения, то Вы можете перенести сроки из этого ДС в ментальную карту, простым щелчком Add Tast info. Тогда вы и проектный менеджер будете понимать, что и когда должно быть выполнено. Просто нажмите в разделе Обзор кнопку Показать диаграмму Ганта и ура.



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

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

Этап 2. Глубоководное погружение в мир пользователя


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

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

Работа в реальных условиях была организована в двух видах.

  • Работа в обстановке приближенной к реальной на тестовых данных
  • Работа полностью в реальной обстановке с реальными данными

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

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







Работа с водителем на реальном рейсе. Реальные данные и реальная ежедневная работа настоящих мужиков.

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





Встретившись с командой мусоровоза, я сразу обозначил свое присутствие и цель Мужики, с приложением Вам придется все равно пользоваться. Это требования к перевозчикам, а не мои хотелки. Они должны передавать данные в муниципалитет. Я здесь, чтобы упростить вам работу. Сейчас приложение не идеально и с вашей помощью мы будет его дорабатывать. Поможете?. Разумеется получил утвердительный ответ. И мы поехали выполнять их повседневные задачи.







Мне было интересно все, что как-то участвует в работе водителя. Что я зрительно фиксировал.

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

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

Отличные мужики попались. Работают как пчёлы. У них мотивация быстрее свой маршрут очистил быстрее домой пойдешь. Поэтому, все их действия оптимизированы и доведены до автоматизма. Водитель даже приложением не пользуется, он знает все точки наизусть, что и когда убирать. А это около 40-60 адресов.

Этап 3 Анализ данных и выводы


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

Все данные я собрал в одном месте и залил на облако. Пока все было свежо в памяти, сформировал бэклог на доработки приложения, обновил CJM.

Инсайты, которые удалось получить


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

  • Все основные водители знают маршрут по памяти. И знают, что и когда вывозится. А это до 40-60 адресов.
  • Все подменные водители (выходят в случае болезни основного) не знают нюансов и деталей маршрута. Где-то надо заранее позвонить и взять ключ от ворот, у кого-то подъезд невозможен на загруженной машине по склону (пробуксовывает) на грунтовой дороге и нужно катить контейнер до машины.
  • У водителя мусоровоза есть помощники, которые производят подкат баков. Они потенциально тоже могут работать с приложением и делать отчеты по КП, которые находятся на территории частных домов при мешковом сборе.
  • Водители мусоровозов самые продуктивные люди в мире. А если у них есть помощники то это самая продуктивная команда.
  • У них есть фиксированный объем работ обслуженные КП. За сколько часов успел, за столько успел. Сделал работы раньше иди домой. Поэтому все действия максимально эффективны и автоматизированы.
  • При наличии помощников водитель не выходит из кабины и отчет делает по монитору заднего вида.
  • Все водители пользуются видом отображения КП список, т.к. картой неудобно пользоваться. А список выстроен на основе бумажного графика, которым они ранее пользовались.

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

Ну и вообще, декларируйте то, что делаете.



Заключение


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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru