Карта путешествий потребителя, оценка рынка и другие советы от менеджера по продукту «Альфа-банка» Екатерины Снегирёвой.
В закладки
Исследования пользователей стали уже обязательной частью продуктовой разработки. Многие пробуют делать глубинные интервью, онлайн-опросы, а некоторые даже выходят «в поля» за инсайтами, но не все после этого начинают использовать накопленную информацию.
Проблемы пользователей разбиваются на user stories, складываются в бэклог, и фактически случайным образом принимается решение о том, что действительно важно и стоит разрабатывать, чтобы сделать качественные улучшения в продукте.
Пользовательская история (user story) - главный артефакт в гибкой разработке, поскольку представляет собой контейнер, служащий переносу потока ценностей к пользователю. А смысл гибкой разработки как раз и состоит в быстрой доставке ценного результата пользователю.
При этом рабочий поток, в котором эта история работает, выглядит так: Определить полезную историю - реализовать и оттестировать в рамках короткой итерации - продемонстрировать или доставить её пользователю - получить обратную связь - усвоить информацию - повторить в цикле.
Бэклог (backlog) - это полный список всех работ, stories.
Кажется, есть скоринговые таблички для оценки приоритетности задачи, но они часто «персонализированы». Я могу поставить коэффициенты сама и накинуть важности именно тем user stories, которые мне нравятся больше.
Скоринговая табличка (scoring) - это приоритизация пользовательских историй с целью отдать в работу самое полезное для пользователя. Большие сложные задачи, как правило, получают невысокие коэффициенты в скоринговой таблице как труднореализуемые и дорогие в разработке, что мотивирует менеджера продукта искать решения получше.
Можно положиться только на груминг и, ссылаясь на оценку команды, принимать решение о том, что сделать сначала, а что сделать потом. Здесь есть риск: можно сделать быстрые микроулучшения, их будет много, но велика вероятность, что большой пользы пользователям вы этим не принесете. Важно уметь себя сдерживать.
Груминг (grooming) - это период, когда команда может рассмотреть будущие истории и вместе с владельцем продукта что-то добавить, чтобы зафиксировать направления проектирования или решить архитектурные вопросы.
Немного market validation, research и усовершенствованный CJM здорово помогают оценить происходящее, увидеть полную картину вокруг и расставить приоритеты.
Market validation
В сущности оценка рынка - это попытка сравнить наличие тех или иных функциональностей в продуктах прямых конкурентов и оценить их уровень развитости и покрытия. У этого инструмента нет четких правил, и не обязательно быть McKinsey, чтобы сделать сравнительный анализ по выбранным признакам.
Во время разработки менеджер и команда погружаются в решение узконаправленных проблем, чтобы отстроить продукт под своих пользователей и бесперебойно поставлять им ценности.
Оценка рынка помогает не углубиться слишком сильно в одну проблему, прокапывая её и оттачивая решение до совершенства. Зачастую намного больше пользы от проработанного минимального решения, которое выпущено в производство и уже даёт быстрые данные, чем от полугодовой фичи, которую вы пишете и пишете из спринта в спринт, в то время как реальный мир (то есть конкурентный) движется дальше: выпускает небольшие решения, тестирует и развивает те, что дали наибольшие результаты по выставленным KPI.
Следите за своими конкурентами, продолжая двигаться согласно своему курсу. Чтобы построить таблицу с оценкой рынка, обратите внимание на следующие вопросы:
- Кто ещё работает над аналогичными продуктами или решениями?
- Что уже сделано и на каком уровне?
- Какие проблемы могут закрывать эти функциональности?
- Насколько эти решения могут удовлетворить потребности пользователей?
- Есть ли что-то похожее у вас?
Сравните от трёх до пяти прямых конкурентов и пару нишевых - тех, у кого, по вашему мнению, можно поискать интересные решения. Составьте таблицу валидации функциональностей с коэффициентами проработки или наличия, на ваш взгляд, необходимых в продукте вещей.
Если вы нашли интересные моменты, которые кажутся вам важными - добавляйте их в таблицу, здесь четких правил нет. Это инструмент вашего исследования, составьте его под себя. При валидации рынка важно держать в уме свою целевую аудиторию и те задачи, которые пользователи решают именно вашим продуктом.
Однако если одной из задач бизнеса является обновление целевой аудитории или захват более платежеспособной, то это допустимо. Также стройте гипотезы по конкурентам с более дорогими услугами или решениями, смотрите на их функциональность и позиционирование.
Кстати, если волевым решением стать внимательным «маркет-валидатором» и стабильно отслеживать и фиксировать обновления конкурентов, можно понять, на решение каких задач сейчас направлен бизнес и какой value stream выбрала та или иная компания-конкурент.
В одном из недавних обсуждений я столкнулся, как мне показалось, с одним распространенным мнением касательно отношений между пользователями и разработчиками. По большой части это касается ответственности первых и вторых, а если быть еще точнее - оформления форм и взаимодействия пользователей с этими формами.
Так уж вышло, что многие из нас не только пользователи, но и разработчики тех или иных продуктов. Так или иначе многим из нас приходится оказываться не только со стороны пользователя формы, но и со стороны, с которой эта форма разработана. Мне кажется некоторые недооценивают влияние своих решений на пользователей и на последствия, которые могут быть в итоге.
giner показал мне ролик, который я рекомендую просмотреть всем. www.snob.ru/selected/entry/5445 в этом ролике доступно и на примерах объясняется и доказывается почему разработчик на этапе проектирования формы принимает за пользователя решения, как это работает и почему это вообще происходит. Кому лень смотреть - перескажу основное в двух словах. В различных странах разное количество людей участвует в программе донорства органов. Серьезное ведь дело. Страны близки по культуре, соседствуют и вроде как отношение в них к этим вещам должно быть примерно одинаковым. Но статистика показывает, что в одних странах в программе согласны участвовать 10-15%, а в других странах - 90-100% людей. В ролике показано, что это зависит не от менталитета, а от формулировки в медицинском формуляре. В одной форме написано «я отказываюсь от участия в программе» и там надо ставить галочку, а в другой форме написано «я согласен участвовать в программе». В большинстве случаев человек вообще не ставит галку. Не меняет состояния, не принимает решения. Там есть и другие примеры. Вообще очень интересный материал, рекомендую просмотреть.
Тоже самое происходит и с нашими формами. Да, можно призывать пользователей быть разумными, вчитываться и осознанно принимать решения, но это не работает. Вероятнее всего пользователь просто все сделает по умолчанию, т.е. сделает так как решили вы . Именно нами, как разработчиками определяется как поведет себя пользователь, даже несмотря на то, что у него будет выбор. Да, не всегда, но в огромном количестве случаев (если опираться за исследователя из ролика - от 80 до 100%). Исходя из этого я утверждаю, что да, разработчик несет ответственность за выбор пользователя, так как очень часто этот выбор управляется именно разработчиком.
Очень важно, чтобы поведение по умолчанию было наименее опасным, наносило наименьший вред. В нормальных условиях на дорожке не должно быть бревна, люки должны быть закрыты, у лестницы есть перила. Да, желающий упасть в люк откроет его и кинется в него вниз головой, но этого не должно происходить по умолчанию. А само по себе «по умолчанию» происходит очень часто, когда поле не обязательное. Или, например, чекбокс - он и установленный и не установленный - уже определяет поведение. Единственным вариантом выбора, когда разработчик на него не влияет мне кажется два radiobutton-на, ни один из которых не установлен, но установка любого из них обязательна. Вот тогда человек будет обязан сделать выбор и тогда можно считать, что его выбор никак не был предопределен.
Так же, как многие водители ругают пешеходов, а переходы ругают водителей, а потом купив машину и сев за руль (или же выйдя из машины) у многих открываются глаза на то, что они делают и их отношение к происходящему меняется - меняется отношение и у бывших пользователей - нынешних разработчиков. Но также как и у автомобилистов - многие продолжают за рулем ругать пешеходов, а переходя дорогу - проклинать водителей. Был удивлен реакции хабровчан, которые сами, наверняка, совсем недавно ругались на установленную по умолчанию галку «подписаться на рассылку», а теперь доказывают, что это хорошо и правильно и они были сами виноваты.
Давайте посмотрим на хабр. Серьезное сообщество, порог входа, ценность аккаунта и так далее. Что нужно для того, чтобы написать топик? Целая система выстроена для того, чтобы человек прочитал требования! Можно же было просто поместить все это в правилах и банить всех, кто их не соблюдает. Но правила никто не читает, а вот такой механизм - работает. Это естественно, хоть и не приятно. Ожидать, что пользователь прочитает все ваши правила, если его специально не пинать - опрометчиво. Таков естественный порядок. Ожидать, что именно в вашем случае он будет нарушен и пользователь станет читать комментарии в форме и изучит правила - опрометчиво. Полагаться на то, что пользователь прочитает и будет соблюдать - все равно, что полагаться на то, что дождь пойдет снизу вверх.
Если каждый из нас задумается над тем, что заложенные им значения по умолчанию сильно влияют на поведение пользователей и осознает, что много решений на самом деле принимаются нами, разработчиками - проблем станет меньше, недовольства со стороны пользователей станет меньше, а использование наших продуктов станет проще.
Независимо от того, сознательно вы направляете пользователя или нет - вы его направляете. Лучше это делать сознательно и в правильном направлении.
Эффективность и гибкость информационной технологии во многом зависят от характеристик интерфейса, системы поддержки принятия решений. Интерфейс определяет: язык пользователя; язык сообщений компьютера, организующий диалог на экране дисплея; знания пользователя.
Язык пользователя - это те действия, которые пользователь производит в отношении системы путем использования возможностей клавиатуры, электронных карандашей, пишущих на экране, джойстика, «мыши», команд, подаваемых голосом и т.п. Наиболее простой формой языка пользователя является создание форм входных и выходных документов. Получив входную форму (документ), пользователь заполняет его необходимыми данными и вводит в компьютер. Система поддержки принятия решений производит необходимый анализ и выдает результаты в виде выходного документа установленной формы.
Язык сообщений - это то, что пользователь видит на экране дисплея (символы, графика, цвет), данные, полученные на принтере, звуковые выходные сигналы и т.п. Важным измерителем эффективности используемого интерфейса является выбранная форма диалога между пользователем и системой. В настоящее время наиболее распространены следующие формы диалога: запросно-ответный режим, командный режим, режим меню, режим заполнения пропусков в выражениях, предлагаемых компьютером. Каждая форма в зависимости от типа задачи, особенностей пользователя и принимаемого решения может иметь свои достоинства и недостатки. Долгое время единственной реализацией языка сообщений был отпечатанный или выведенный на экран дисплея отчет или сообщение. Теперь появилась новая возможность представления выходных данных - машинная графика. Она дает возможность создавать на экране и бумаге цветные графические изображения в трехмерном виде. Использование машинной графики, значительно повышающее наглядность и интерпретируемость выходных данных, становится все более популярным в информационной технологии поддержки принятия решений.
Знания пользователя - это то, что пользователь должен знать, работая с системой. К ним относятся не только план действий, находящийся в голове у пользователя, но и учебники, инструкции, справочные данные, выдаваемые компьютером.
Совершенствование интерфейса, системы поддержки принятия решений, определяется успехами в развитии каждого из трех указанных компонентов. Интерфейс должен обладать следующими возможностями:
манипулировать различными формами диалога, изменяя их в процессе принятия решения по выбору пользователя;
передавать данные системе различными способами;
получать данные от различных устройств системы в различном формате;
гибко поддерживать (оказывать помощь по запросу, подсказывать) знания пользователя.
2.2.3 Информационная технология экспертных систем
Наибольший прогресс среди компьютерных информационныхсистем отмечен в области разработки экспертных систем. Экспертные системы дают возможность менеджеру или специалисту получать консультации экспертов по любым проблемам, о которых этими системами накоплены знания.
Решение специальных задач требует специальных знаний. Однако не каждая компания может себе позволить держать в своем штате экспертов по всем связанным с ее работой проблемам или даже приглашать их каждый раз, когда проблема возникла. Главная идея использования технологии экспертных систем заключается в том, чтобы получить от эксперта его знания и, загрузив их в память компьютера, использовать всякий раз, когда в этом возникнет необходимость. Все это делает возможным использовать технологию экспертных систем в качестве советующих систем.
Сходство информационных технологий, используемых в экспертных системах и системах поддержки принятия решений, состоит в том, что обе они обеспечивают высокий уровень поддержки принятия решений. Однако имеются три существенных различия.
Первое связано с тем, что решение проблемы в рамках систем поддержки принятия решений отражает уровень её понимания пользователем и его возможности получить и осмыслить решение. Технология экспертных систем, наоборот, предлагает пользователю принять решение, превосходящее его возможности.
Второе отличие указанных технологий выражается в способности экспертных систем пояснять свои рассуждения в процессе получения решения. Очень часто эти пояснения оказываются более важными для пользователя, чем само решение.
Третье отличие связано с использованием нового компонента информационной технологии - знаний.
Основными компонентами информационной технологии, используемой в экспертной системе, являются: интерфейс пользователя, база знаний, интерпретатор, модуль создания системы.
Менеджер (специалист) использует интерфейс для ввода информации и команд в экспертную систему и получения выходной информации из нее. Команды включают в себя параметры, направляющие процесс обработки знаний. Информация обычно выдается в форме значений, присваиваемых определенным переменным.
Технология экспертных систем предусматривает возможность получать в качестве выходной информации не только решение, но и необходимые объяснения.
Различают два вида объяснений:
объяснения, выдаваемые по запросам. Пользователь в любой момент может потребовать от экспертной системы объяснения своих действий;
объяснения полученного решения проблемы. После получения решения пользователь может потребовать объяснений того, как оно было получено. Система должна пояснить каждый шаг своих рассуждений, ведущих к решению задачи. Хотя технология работы с экспертной системой не является простой, пользовательский интерфейс этих систем является дружественным и обычно не вызывает трудностей при ведении диалога.
База знаний содержит факты, описывающие проблемную область, а также логическую взаимосвязь этих фактов. Центральное место в базе знаний принадлежит правилам. Правило определяет, что следует делать в данной конкретной ситуации, и состоит из двух частей: условия, которое может выполняться или нет, и действия, которое следует произвести, если условие выполняется.
Все используемые в экспертной системе правила образуют систему правил, которая даже для сравнительно простой системы может содержать несколько тысяч правил.
Интерпретатор - часть экспертной системы, производящая в определенном порядке обработку знаний (мышление), находящихся в базе знаний. Технология работы интерпретатора сводится к последовательному рассмотрению совокупности правил (правило за правилом). Если условие, содержащееся в правиле, соблюдается, выполняется определенное действие, и пользователю предоставляется вариант решения его проблемы.
Кроме того, во многих экспертных системах вводятся дополнительные блоки: база данных, блок расчета, блок ввода и корректировки данных. Блок расчета необходим в ситуациях, связанных с принятием управленческих решений. При этом важную роль играет база данных, где содержатся плановые, физические, расчетные, отчетные и другие постоянные или оперативные показатели. Блок ввода и корректировки данных используется для оперативного и своевременного отражения текущих изменений в базе данных.
Модуль создания системы - служит для создания набора (иерархии) правил. Существуют два подхода, которые могут быть положены в основу модуля создания системы: использование алгоритмических языков программирования и использование оболочек экспертных систем.
Оболочка экспертных систем представляет собой готовую программную среду, которая может быть приспособлена к решению определенной проблемы путем создания соответствующей базы знаний. В большинстве случаев использование оболочек позволяет создавать экспертные системы быстрее и легче в сравнении с программированием.
Системы поддержки принятия решений или СППР - это компьютерная система, которая путем сбора и анализа большого количества информации может влиять на процесс принятия решений организационного плана. Интерактивные системы позволяют руководителям получить полезную информацию из первоисточников, проанализировать ее, а также выявить существующие модели для решения определенных задач.
Система поддержки решений СППР решает две основные задачи:
1. выбор наилучшего решения из множества возможных (оптимизация);
2. упорядочение возможных решений по предпочтительности (ранжирование).
В обеих задачах первым и наиболее принципиальным моментом является выбор совокупности критериев, на основе которых в дальнейшем будут оцениваться, и сопоставляться возможные решения (альтернативы). Система СППР помогает пользователю сделать такой выбор.
Для анализа и выработок предложений в СППР используются разные методы. Это могут быть: информационный поиск, интеллектуальный анализ данных, поиск знаний в базах данных, рассуждение на основе прецедентов, имитационное моделирование, эволюционные вычисления и генетические алгоритмы, нейронные сети, ситуационный анализ, когнитивное моделирование и др. Некоторые из этих методов были разработаны в рамках искусственного интеллекта. Если в основе работы СППР лежат методы искусственного интеллекта, то говорят об интеллектуальной СППР, или ИСППР .
Близкие к СППР классы систем - это экспертные системы и автоматизированные системы управления. Модель управления и управления данными действуют, в основном, незаметно и варьируются от простой модели до сложной комплексной модели планирования, основанной на математическом программировании.
Наиболее широкой сферой практического применения СППР являются планирование и прогнозирование для различных видов управленческой деятельности.
Системы поддержки принятия решений:
· предполагают гибкость пользователей, адаптируемость и быструю реакцию;
· допускают, чтобы пользователи управляли входом и выходом;
· оперируют с небольшой помощью профессиональных программистов или без нее;
· обеспечивают поддержку для решений и проблем, которые не могут быть определены заранее;
· используют сложный анализ и инструментальные средства моделирования.
СППР имеют большую аналитическую мощность, чем другие системы: они построены с рядом моделей, чтобы анализировать данные. Системы СППР интерактивны; пользователь может изменять предположения и включать новые данные.
Процесс принятия решений в СППР, включает четыре стадии:
1) распознавание или осмысление - состоит из идентификации и понимания проблем, встречающихся в организации: почему проблемы возникают, где и с каким результатом. Традиционные управляющие информационные системы (УИС), которые поставляют широкое многообразие детальной информации, могут помогать опознавать проблемы, особенно если системы сообщают об исключениях;
2) проект или продумывание - в течение принятия решений лицо, принимающее решение, продумывает возможные варианты решения проблем. Малые системы СППР идеальны в этой стадии принятия решений, потому что они оперируют на простых моделях, могут быть быстро развиты и работать с ограниченными данными;
3) выбор - заключается в подборе решений среди альтернатив. Здесь изготовитель решений мог бы нуждаться в большой системе СППР, чтобы использовать более обширные данные относительно ряда альтернатив и комплексные аналитические модели, чтобы объяснить все затраты, следствия и возможности;
4) реализация - в течение выполнения решения менеджеры могут использовать систему сообщения, которая поставляет обычные доклады относительно прогресса определенного решения. Системы поддержки выполнения могут быть от полномасштабной управляющей информационной системы до меньших систем, таких, как программное обеспечение планирования проекта, использующего микрокомпьютеры.
Рассмотрим основные классификации СППР.
По взаимодействию с пользователем выделяют три вида СППР:
· пассивные помогают в процессе принятия решений, но не могут выдвинуть конкретного предложения;
· активные, непосредственно, участвуют в разработке правильного решения;
· кооперативные предполагают взаимодействие СППР с пользователем.
Выдвинутое системой предложение пользователь может доработать, усовершенствовать, а затем отправить обратно в систему для проверки. После этого предложение вновь представляется пользователю, и так до тех пор, пока он не одобрит решение.
По способу поддержки различают:
· модельно-ориентированные СППР, используют в работе доступ к статистическим, финансовым или иным моделям;
· СППР, основанные на коммуникациях, поддерживают работу двух и более пользователей, занимающихся общей задачей;
· СППР, ориентированные на данные, имеют доступ к временным рядам организации. Они используют в работе не только внутренние, но и внешние данные;
· СППР, ориентированные на документы, манипулируют неструктурированной информацией, заключенной в различных электронных форматах;
· СППР, ориентированные на знания, предоставляют специализированные решения проблем, основанные на фактах.
По сфере использования выделяют общесистемные и настольные СППР. Общесистемные работают с большими системами хранения данных и применяются многими пользователями. Настольные являются небольшими системами и подходят для управления с персонального компьютера одного пользователя .
Вы помните старые видеоигры 20 летней давности и насколько весело было в них играть? Управление было таким простым, что вы могли научиться играть всего за несколько секунд. Например, в Super Mario было всего три движения: влево, вправо и прыжок.
Старые добрые времена 🙂
Для сравнения, средства управления современных игр для консолей и ПК предлагают слишком много опций и комбинаций. Эти элементы управления, увеличивают количество вариантов, которые пользователь может выбрать в определенной ситуации.
Современная MMORPG (ее намного сложнее освоить, чем старые игры) Наличие такого множества вариантов усложняет обучение управлением в игре и требует много времени.
Закон Хика предсказывает, что время и усилия, необходимые для принятия решения, увеличиваются с количеством вариантов.
Или Закон Хика-Хаймана , названный в честь британского и американского психологов Уильяма Эдмунда Хика и Рэя Хаймана , определяет время , необходимое человеку для принятия решения, исходя из возможных вариантов, которые он имеет: увеличение числа вариантов выбора будет логарифмически увеличивать время принятия решения.
Таким образом, время, необходимое пользователю для завершения своей задачи, увеличивается с количеством доступных вариантов. Мы можем сократить это до формулы: Меньше значит Быстрее (легче запомнить )
Когда использовать закон Хика?
Используйте закон Хика, когда время реакции имеет решающее значение. Это относится к любому простому решению с несколькими вариантами. Это особенно важно в средах системы управления.
Если ядерный реактор будет перегреваться, вы не захотите, чтобы оператор искал инструкцию. Когда все идет не так, и срабатывают сигналы тревоги, пользователи должны иметь возможность принимать быстрые решения. Когда пользователи находятся в стрессовой ситуации, у них туннельное зрение. Это может привести к довольно неприятным последствиям.
Когда пользователи находятся в стрессовой ситуации, наличие одного варианта выбора действует, как свет в туннеле. Когда время реакции критично, сведите варианты выбора до минимума. Это ускорит принятие решений.
Как насчет обычных продуктов и повседневных ситуаций?
Закон Хика может быть использован для сужения больших объемов информации без перегрузки пользователя.
Когда вам нужно упростить сложный процесс, используйте закон Хика. Представьте конкретные части этого процесса в конкретный момент на экране.
Примером может служить процесс покупки в онлайн-магазине. Вместо того, чтобы показывать все сразу, вы можете разделить процесс на несколько экранов. Покажите экран с информацией о корзине покупок, а затем другой с информацией о доставке, затем создание дополнительной учетной записи и так далее.
Покупка на Amazon за один клик – отличный пример применения закона Хика и KISS-принципа. Уменьшение количества опций на экране делает интерфейс более удобным для пользователя. Также более вероятно, что пользователь достигнет цели и не запутается.
Важно не переусердствовать с упрощением! Разделение выбора на слишком большое количество мелких кусков, также может привести к тому, что пользователь покинет сайт до того, как достигнет цель.
Способ начать работу с законом Хика
Тест «Сортировка карт» – отличный способ узнать какие категории информации имеют больше смысла для ваших пользователей. Вы можете использовать старомодные бумажные карточки или цифровые инструменты для удаленной сортировки карт. Такие инструменты, как Optimal Workshop или аналогичные, могут быть очень эффективными и помогут получить практически полезные результаты.
Когда не использовать закон Хика?
Не менее важно знать, когда не использовать его. Закон Хика не применяется к комплексному принятию решений. Например, если решения требуют обширного чтения, исследования или расширенного обсуждения. Закон Хика не сможет предсказать время необходимое на принятие решения.
Например, выбирая ужин в дорогом ресторане или выбирая на сайте AirBnB, где провести каникулы на следующей неделе.
Сделать подобный выбор сложно. Перед принятием окончательного решения пользователям необходимо учитывать и взвесить множество вариантов. В этих случаях закон Хика не подходит. Он применим только к простым и быстрым решениям в соответствующем контексте.
Практическое использование закона Хика
Когда время ответа имеет решающее значение, сохраните небольшое количество вариантов. От одного до пяти – хорошее эмпирическое правило, проверенное временем.
Люди странные создания. Мы любим говорить, что мы хотим, как можно больше вариантов. Когда мы их получаем … мы смущаемся и не можем принять решение.
Разве вы не хотите использовать все эти кнопки? Наличие слишком большого количества вариантов одинаковой важности может привести к параличу анализа. Да, это разочаровывает. Не лучший пользовательский опыт.
Напротив, система с меньшим количеством более понятных параметров часто оценивается пользователями, как система с лучшим пользовательским опытом.
Сложность скрыта, когда это необходимо Выделение одного из вариантов – еще один способ использования Закона Хика. Выделите несколько важных опций среди загроможденного пользовательского интерфейса, чтобы ускорить время отклика.
В контексте принятия решений цель – сокращение отвлекающих факторов. Большое количество вариантов выбора отвлекает пользователя. Это приводит к медленному времени отклика.
Закон Хика влияет на мой дизайн?
Вот несколько способов узнать, влияет ли применение этого принципа на ваш дизайн. Мы всегда должны смотреть на показатели, чтобы убедиться, что наши дизайнерские решения имеют эффект.
Посмотрите время , проведенное пользователем на сайте
Вы должны попасть в зону наилучшего восприятия. С одной стороны, если пользователь провел слишком мало времени на сайте, возможно, он ушел, не приняв решение. С другой стороны, если пользователь проводит слишком много времени на сайте, он, вероятно, отвлёкся от своей цели.
Сосредоточьтесь на оптимизации дизайна, чтобы предоставить пользователю правильное количество вариантов для удержания внимания пользователя. Помогите пользователю сделать выбор и сэкономьте его время.
Количество просмотров страницы также может быть индикатором того, насколько эффективно вы использовали закон Хика. Если навигация слишком сложная, количество просмотров страницы, вероятно, будет ниже, чем, если бы она была простой.
Тем не менее, избегайте создания глубокой навигации, которая требует 2-3 выбора для каждого уровня и продолжается до 10 уровней. Это увеличит время выполнения задачи, что увеличит вероятность того, что пользователи покинут сайт преждевременно.
Мысли в заключение
Время пользователя драгоценно! Время = Жизнь. Не допускайте принятия плохих дизайнерских решений, чтобы не украсть жизнь у ваших пользователей. Никто не обязан оставаться или использовать ваш продукт. (особенно когда есть альтернативы )
Познакомьтесь с пользователем, взаимодействуйте с ним. Направляйте пользователя к своей цели, выделяя варианты, которые его волнуют в этом контексте. Это позволит оптимизировать процесс принятия решений и ускорить выполнение задачи. В конце концов, обе стороны будут счастливы.
Призыв к действию
Спасибо за внимание! Пишите мне в
