Эвристика #2: Match between system and the real world
#summary
1. Интерфейс должен разговаривать на языке пользователя. Никакого жаргона. Всё должно быть естественно и логично именно для пользователей.
2. Термины, понятия, иконки и картинки, которые понятны нам, могут быть не понятны пользователям.
3. Расположение элементов управления должно быть интуитивно понятным для пользователя.
Например, элементы управления плитой расположены так, что пользователь интуитивно и мгновенно понимает где какая конфорка включается.
4. Важно, чтобы пользователю не нужно было гуглить определения слов из интерфейса.
5. Наше понимание слов не равно пониманию этих же слов пользователями.
6. Качественные исследования пользователей помогают понять «язык», на котором они говорят и как они вообще думают.
7. В общем, должно быть некое совпадение интерфейса с реальным миром.
#ux #ui
#summary
1. Интерфейс должен разговаривать на языке пользователя. Никакого жаргона. Всё должно быть естественно и логично именно для пользователей.
2. Термины, понятия, иконки и картинки, которые понятны нам, могут быть не понятны пользователям.
3. Расположение элементов управления должно быть интуитивно понятным для пользователя.
Например, элементы управления плитой расположены так, что пользователь интуитивно и мгновенно понимает где какая конфорка включается.
4. Важно, чтобы пользователю не нужно было гуглить определения слов из интерфейса.
5. Наше понимание слов не равно пониманию этих же слов пользователями.
6. Качественные исследования пользователей помогают понять «язык», на котором они говорят и как они вообще думают.
7. В общем, должно быть некое совпадение интерфейса с реальным миром.
#ux #ui
Эвристика #3: User control and freedom
1. Пользователи часто совершают ошибочные действия в интерфейсах. Важно предоставить им «аварийный выход» из нежелательного действия, чтобы им не пришлось проходить весь путь заново.
2. Возможность вернуться на шаг назад или отменить действие даёт пользователям чувство контроля, свободы и уверенности в интерфейсе.
3. Благодаря таким «аварийным выходам» пользователи не запутаются и не будут испытывать разочарование.
4. Пример 3-й эвристики: кнопки «назад», «отменить» или «закрыть». Аналог таблички «Выход» в физических пространствах.
5. Короче, учитываем такие кнопки и делаем их максимально заметными, чтобы пользователи легко смогли их найти в нужный момент.
#ux #ui
1. Пользователи часто совершают ошибочные действия в интерфейсах. Важно предоставить им «аварийный выход» из нежелательного действия, чтобы им не пришлось проходить весь путь заново.
2. Возможность вернуться на шаг назад или отменить действие даёт пользователям чувство контроля, свободы и уверенности в интерфейсе.
3. Благодаря таким «аварийным выходам» пользователи не запутаются и не будут испытывать разочарование.
4. Пример 3-й эвристики: кнопки «назад», «отменить» или «закрыть». Аналог таблички «Выход» в физических пространствах.
5. Короче, учитываем такие кнопки и делаем их максимально заметными, чтобы пользователи легко смогли их найти в нужный момент.
#ux #ui
Эвристика #4: Consistency and standards
1. Пользователи не должны догадываться - означают ли разные слова, ситуации и действия одно то же. Интерфейс должен быть консистентным (согласованным). В этом помогают сложившиеся на рынке стандарты.
2. Пользователи проводят много времени в интерфейсах других продуктов, не только в нашем. Эти интерфейсы формируют у них привычные ожидания. Поэтому, неконсистентный интерфейс, который не учитывает стандарты, вызывает когнитивную нагрузку, потому что заставляет учиться новому.
3. Пример 4-й эвристики: стойки регистрации в отелях находятся на входе, потому что это ожидаемо и привычно для клиентов.
4. Бывает два типа консистентности: внутренняя и внешняя.
5. Поддержка консистентности в рамках одного продукта или семейства продуктов - это внутренняя консистентность.
6. Соблюдение сложившихся на рынке стандартов - это внешняя консистентность.
——
Если есть что добавить по четвёртой эвристике - можно это сделать в комментариях.
#ux #ui
1. Пользователи не должны догадываться - означают ли разные слова, ситуации и действия одно то же. Интерфейс должен быть консистентным (согласованным). В этом помогают сложившиеся на рынке стандарты.
2. Пользователи проводят много времени в интерфейсах других продуктов, не только в нашем. Эти интерфейсы формируют у них привычные ожидания. Поэтому, неконсистентный интерфейс, который не учитывает стандарты, вызывает когнитивную нагрузку, потому что заставляет учиться новому.
3. Пример 4-й эвристики: стойки регистрации в отелях находятся на входе, потому что это ожидаемо и привычно для клиентов.
4. Бывает два типа консистентности: внутренняя и внешняя.
5. Поддержка консистентности в рамках одного продукта или семейства продуктов - это внутренняя консистентность.
6. Соблюдение сложившихся на рынке стандартов - это внешняя консистентность.
——
Если есть что добавить по четвёртой эвристике - можно это сделать в комментариях.
#ux #ui
Эвристика #5: Error prevention
1. Предупреждать об ошибках - это хорошо, но лучшие интерфейсы предотвращают их возникновение.
2. Интерфейс должен либо устранять причины возникшей ошибки, либо предлагать подтверждать действия перед выполнением.
3. Бывают 2 вида ошибок: промахи и ошибочные действия..
4. Промахи - случайные ошибки, вызванные из-за невнимательности. Случайно тыкнул не туда, не специально.
5. Ошибочные действия - неслучайные ошибки, вызванные несовпадением дизайна с ментальной моделью пользователя. Сознательно ткнул на кнопку, думал будет «так», а оказалось совсем не то действие.
6. Пример 5-й эвристики: ограждения на извилистых дорогах предотвращают падение водителей со скал.
7. Приоритет: сначала предотвращаем дорогостоящие ошибки, а потом мелкие разочарования.
8. Предотвращаем промахи через помогающие ограничения.
9. Ошибочные действия предотвращаем через предупреждения и возможность отменить действие.
——
5 эвристик разобрали. Осталось ещё пять. 😌
#ux #ui
1. Предупреждать об ошибках - это хорошо, но лучшие интерфейсы предотвращают их возникновение.
2. Интерфейс должен либо устранять причины возникшей ошибки, либо предлагать подтверждать действия перед выполнением.
3. Бывают 2 вида ошибок: промахи и ошибочные действия..
4. Промахи - случайные ошибки, вызванные из-за невнимательности. Случайно тыкнул не туда, не специально.
5. Ошибочные действия - неслучайные ошибки, вызванные несовпадением дизайна с ментальной моделью пользователя. Сознательно ткнул на кнопку, думал будет «так», а оказалось совсем не то действие.
6. Пример 5-й эвристики: ограждения на извилистых дорогах предотвращают падение водителей со скал.
7. Приоритет: сначала предотвращаем дорогостоящие ошибки, а потом мелкие разочарования.
8. Предотвращаем промахи через помогающие ограничения.
9. Ошибочные действия предотвращаем через предупреждения и возможность отменить действие.
——
5 эвристик разобрали. Осталось ещё пять. 😌
#ux #ui
Эвристика #6: Recognition rather than recall
Узнавать легче чем запоминать.
1. Важно снижать нагрузку на память пользователя в интерфейсе. Хорошо видимые элементы, подсказки в нужный момент.
2. Интерфейс не должен заставлять пользователя запоминать инфу, чтобы воспользоваться ей где-то дальше.
3. Краткосрочная память человека ограничена. Интерфейсы, помогающие узнавать, а не вспоминать, снижают когнитивную нагрузку.
4. Например, нам легче узнать столицу страны чем вспомнить. Легче ответить на вопрос «Лиссабон столица Португалии?» чем «Что столица Португалии?»
Поэтому:
5. Делаем интерфейс таким, чтобы люди он помогал узнавать инфу, а не вспоминать.
6. Лучше давать подсказки в нужный момент, в нужном контексте, чем предложить почитать длинную инструкцию.
7. Стараемся избегать инфы, которую пользователь должен запомнить.
#ux #ui
Узнавать легче чем запоминать.
1. Важно снижать нагрузку на память пользователя в интерфейсе. Хорошо видимые элементы, подсказки в нужный момент.
2. Интерфейс не должен заставлять пользователя запоминать инфу, чтобы воспользоваться ей где-то дальше.
3. Краткосрочная память человека ограничена. Интерфейсы, помогающие узнавать, а не вспоминать, снижают когнитивную нагрузку.
4. Например, нам легче узнать столицу страны чем вспомнить. Легче ответить на вопрос «Лиссабон столица Португалии?» чем «Что столица Португалии?»
Поэтому:
5. Делаем интерфейс таким, чтобы люди он помогал узнавать инфу, а не вспоминать.
6. Лучше давать подсказки в нужный момент, в нужном контексте, чем предложить почитать длинную инструкцию.
7. Стараемся избегать инфы, которую пользователь должен запомнить.
#ux #ui
Эвристика #7: Flexibility and efficiency of use
Гибкость и эффективность использования
1. Возможность настраивать повторяющиеся действия в интерфейсе. Интерфейс с быстрыми действиями (shortcuts), скрытыми от новичков, может ускорить взаимодействие опытных пользователей и одновременно быть удобным для новых.
2. Возможность выбора нескольких способов решить задачу - гибкость интерфейса.
3. Например, приложение с картой местности показывает всем обычный маршрут до точки, но местные жители могут видеть более короткие пути.
Или появляющиеся со временем ярлыки «Работа», «Дом» в картах и навигаторе.
4. Делаем быстрые сочетания клавиш, ярлыки и жесты для сенсорных экранов.
5. Персонализируем - чтобы у каждого пользователя был свой индивидуальный интерфейс, адаптированный под него.
6. Позволяем пользователям кастомно настраивать работу интерфейса под себя.
#ux #ui
Гибкость и эффективность использования
1. Возможность настраивать повторяющиеся действия в интерфейсе. Интерфейс с быстрыми действиями (shortcuts), скрытыми от новичков, может ускорить взаимодействие опытных пользователей и одновременно быть удобным для новых.
2. Возможность выбора нескольких способов решить задачу - гибкость интерфейса.
3. Например, приложение с картой местности показывает всем обычный маршрут до точки, но местные жители могут видеть более короткие пути.
Или появляющиеся со временем ярлыки «Работа», «Дом» в картах и навигаторе.
4. Делаем быстрые сочетания клавиш, ярлыки и жесты для сенсорных экранов.
5. Персонализируем - чтобы у каждого пользователя был свой индивидуальный интерфейс, адаптированный под него.
6. Позволяем пользователям кастомно настраивать работу интерфейса под себя.
#ux #ui
Эвристика #8: Aesthetic and minimalist design
Эстетика и минимализм
1. В интерфейсе не должно быть инфы и элементов, которые нерелевантны или редко используются.
2. Каждый такой нерелевантный элемент конкурирует за внимание с другими, но важными элементами, и делает их менее заметными.
3. Контент интерфейса и его дизайн должны фокусировать на самом главном.
4. Все визуальные элементы интерфейса должны обслуживать главную задачу пользователя.
5. Пример несоблюдения эвристики - чайник, который украшен кучей нефункциональных декоративных элементов, с неудобной ручкой и дурацким горлышком, который тяжело мыть.
#ux #ui
Эстетика и минимализм
1. В интерфейсе не должно быть инфы и элементов, которые нерелевантны или редко используются.
2. Каждый такой нерелевантный элемент конкурирует за внимание с другими, но важными элементами, и делает их менее заметными.
3. Контент интерфейса и его дизайн должны фокусировать на самом главном.
4. Все визуальные элементы интерфейса должны обслуживать главную задачу пользователя.
5. Пример несоблюдения эвристики - чайник, который украшен кучей нефункциональных декоративных элементов, с неудобной ручкой и дурацким горлышком, который тяжело мыть.
#ux #ui
Эвристика #9: Help users recognize, diagnose, and recover from errors
Помощь в распознавании, диагностике и откату ошибок.
1. Сообщения об ошибках должны быть на понятном человеческом языке. Не надо показывать страшные коды ошибок и писать на техническом жаргоне.
2. Сообщение об ошибке должно давать понимание проблемы. И подсказывать решение, например, предлагать сочетание клавиш или кнопку.
3. Так же, эти сообщения должны сопровождаться визуальными элементами, которые помогают пользователям быстро распознавать ошибки.
4. Пример этой эвристики - дорожные знаки, которые говорят водителям, что они едут в неправильном направлении и призывают его остановиться.
5. Можно акцентировать внимание в сообщениях об ошибках через простое выделение жирным или красным текстом.
#ux #ui
Помощь в распознавании, диагностике и откату ошибок.
1. Сообщения об ошибках должны быть на понятном человеческом языке. Не надо показывать страшные коды ошибок и писать на техническом жаргоне.
2. Сообщение об ошибке должно давать понимание проблемы. И подсказывать решение, например, предлагать сочетание клавиш или кнопку.
3. Так же, эти сообщения должны сопровождаться визуальными элементами, которые помогают пользователям быстро распознавать ошибки.
4. Пример этой эвристики - дорожные знаки, которые говорят водителям, что они едут в неправильном направлении и призывают его остановиться.
5. Можно акцентировать внимание в сообщениях об ошибках через простое выделение жирным или красным текстом.
#ux #ui
И наконец-то последняя эвристика #10: Help and documentation
Справка и документация
1. Идеально, когда интерфейс не требует дополнительных разъяснений и справка с докой вообще не нужны.
2. Но часто справка и дока нужны, чтобы помочь пользователям завершить свои задачки.
3. Справка и документация должны быть краткими, лаконичными и понятными. В них должно быть легко что-то найти и они должны помогать пользователям решать их проблемы. В идеале - предлагать конкретные шаги решения.
4. Пример эвристики - информационные киоски в аэропортах. Они легко узнаваемы и позволяют быстро получить ответ на любой вопрос.
5. В идеале, когда справка или дока появляются в нужное время, в нужном месте. Так сказать «в контексте» - когда это необходимо.
#ux #ui
Справка и документация
1. Идеально, когда интерфейс не требует дополнительных разъяснений и справка с докой вообще не нужны.
2. Но часто справка и дока нужны, чтобы помочь пользователям завершить свои задачки.
3. Справка и документация должны быть краткими, лаконичными и понятными. В них должно быть легко что-то найти и они должны помогать пользователям решать их проблемы. В идеале - предлагать конкретные шаги решения.
4. Пример эвристики - информационные киоски в аэропортах. Они легко узнаваемы и позволяют быстро получить ответ на любой вопрос.
5. В идеале, когда справка или дока появляются в нужное время, в нужном месте. Так сказать «в контексте» - когда это необходимо.
#ux #ui
Факап с интерфейсом из недавней практики
1. Совсем недавно я решил улучшить первую сессию в продукте.
2. По своей неопытности с UX/UI, сделал новый дизайн, с новым флоу 1-й сессии, отличным от флоу повторных.
3. Думал, ща всё улучшу, а в итоге мой новый UI сильно уронил конверсию первой сессии (С1), да и повторную конверсию (С2) тоже сильно ухудшил. Юзабилити тестирование не делал, на эвристики не проверял. 🤦♂️
4. Сейчас как раз разбираюсь с темой UX/UI. Теперь буду всегда проверять по эвристикам Якоба Нильсена сначала.
5. Вот здесь https://www.nngroup.com/articles/ten-usability-heuristics/#poster можно взять красивый постер со всеми 10 эвристиками, чтобы перед глазами были и не надо было вспоминать.
6. В конце оригинальной статьи про эвристики https://www.nngroup.com/articles/ten-usability-heuristics/ есть ссылки на другие статьи, с более узким применением этих эвристик. Например, как применять их в сложных приложениях, в VR, в играх и в повседневной жизни.
#опыт #факап #ux #ui
1. Совсем недавно я решил улучшить первую сессию в продукте.
2. По своей неопытности с UX/UI, сделал новый дизайн, с новым флоу 1-й сессии, отличным от флоу повторных.
3. Думал, ща всё улучшу, а в итоге мой новый UI сильно уронил конверсию первой сессии (С1), да и повторную конверсию (С2) тоже сильно ухудшил. Юзабилити тестирование не делал, на эвристики не проверял. 🤦♂️
4. Сейчас как раз разбираюсь с темой UX/UI. Теперь буду всегда проверять по эвристикам Якоба Нильсена сначала.
5. Вот здесь https://www.nngroup.com/articles/ten-usability-heuristics/#poster можно взять красивый постер со всеми 10 эвристиками, чтобы перед глазами были и не надо было вспоминать.
6. В конце оригинальной статьи про эвристики https://www.nngroup.com/articles/ten-usability-heuristics/ есть ссылки на другие статьи, с более узким применением этих эвристик. Например, как применять их в сложных приложениях, в VR, в играх и в повседневной жизни.
#опыт #факап #ux #ui
Дима Беговатов, который ведёт @vchunt, собрал список всех телеграм-каналов про стартапчики. 💪
33 телеграм-канала про стартапы и для стартапов на русском языке
33 телеграм-канала про стартапы и для стартапов на русском языке
vc.ru
33 телеграм-канала про стартапы и для стартапов на русском языке — Дмитрий Беговатов на vc.ru
Привет, vc.ru! Я собрал самую большую на данный момент подборку каналов про стартапы, инвестиции и развитие продукта. Освежите в памяти популярные ресурсы и подписывайтесь на подающих надежды новичков!
Продукт должен решать проблему или боль?
Понравилась статья Олега Якубенкова, из блога GoPractice: «Продукт должен решать боль и проблему» vs «Продукт должен решать задачу лучше альтернатив».
Моё вольное #summary
1. Многие успешные продукты не решали никаких острых болей или проблем при запуске. Или люди не осознавали свои боли и проблемы при решении задач.
2. Слово «problem» переводиться не только как «проблема», а ещё и как «задача». И когда говорят «Does your product solve the problem?», скорее имеют ввиду «задачу», а не «проблему».
3. Люди ежедневно решают большое количество задач. Наша работа — найти способ решать эти задачи эффективнее.
4. Именно «добавочная ценность» предложенного способа решения задачи, по сравнению с альтернативами, может быть сильной причиной востребованности и успеха продукта.
5. И действительно, один из способов создать добавочную ценность — найти проблемы и боли людей при использовании существующих решений, а потом устранить их в своем продукте.
6. Другой способ создать добавочную ценность — найти новый и более эффективный способ решения задачи. В таком случае люди захотят выбрать наш продукт, даже если они не испытывают никаких болей и проблем с текущим решением.
7. Решение некоторых задач и правда сопровождается болями и проблемами, которые люди осознают. В таких случаях они с большей вероятностью будут искать альтернативу. И продукт, который исправит эти недостатки, даст им ценность и очень заинтересует.
8. Устранение проблем существующих продуктов — не самый лучший способ создать добавочную ценность. Люди могут быть удовлетворены текущим решением, но это не значит, что они не выберут более эффективный продукт, если мы его создадим.
9. К смене способа решения задачи, подталкивают две силы:
— Проблемы с текущим способом;
— Выгоды от использования нового.
10. Подход с устранением проблем и болей существующих решений использует первую силу для создания добавочной ценности. Но часто, новые продукты оказываются востребованными как раз за счёт предлагаемых ими выгод.
11. Подход через поиск проблем и болей загоняет в анализ недостатков текущих решений, а это ограничивает мышление.
12. В некоторых ситуациях и правда можно создать много добавочной ценности, если исправить проблемы и боли существующих продуктов.
Но подход через поиск наиболее эффективных способов решать задачи (быстрее, дешевле, больше) позволяет смотреть на новые технологии и методы их применения к разным задачам, чтобы сделать жизнь людей лучше.
#problem #gopractice
Понравилась статья Олега Якубенкова, из блога GoPractice: «Продукт должен решать боль и проблему» vs «Продукт должен решать задачу лучше альтернатив».
Моё вольное #summary
1. Многие успешные продукты не решали никаких острых болей или проблем при запуске. Или люди не осознавали свои боли и проблемы при решении задач.
2. Слово «problem» переводиться не только как «проблема», а ещё и как «задача». И когда говорят «Does your product solve the problem?», скорее имеют ввиду «задачу», а не «проблему».
3. Люди ежедневно решают большое количество задач. Наша работа — найти способ решать эти задачи эффективнее.
4. Именно «добавочная ценность» предложенного способа решения задачи, по сравнению с альтернативами, может быть сильной причиной востребованности и успеха продукта.
5. И действительно, один из способов создать добавочную ценность — найти проблемы и боли людей при использовании существующих решений, а потом устранить их в своем продукте.
6. Другой способ создать добавочную ценность — найти новый и более эффективный способ решения задачи. В таком случае люди захотят выбрать наш продукт, даже если они не испытывают никаких болей и проблем с текущим решением.
7. Решение некоторых задач и правда сопровождается болями и проблемами, которые люди осознают. В таких случаях они с большей вероятностью будут искать альтернативу. И продукт, который исправит эти недостатки, даст им ценность и очень заинтересует.
8. Устранение проблем существующих продуктов — не самый лучший способ создать добавочную ценность. Люди могут быть удовлетворены текущим решением, но это не значит, что они не выберут более эффективный продукт, если мы его создадим.
9. К смене способа решения задачи, подталкивают две силы:
— Проблемы с текущим способом;
— Выгоды от использования нового.
10. Подход с устранением проблем и болей существующих решений использует первую силу для создания добавочной ценности. Но часто, новые продукты оказываются востребованными как раз за счёт предлагаемых ими выгод.
11. Подход через поиск проблем и болей загоняет в анализ недостатков текущих решений, а это ограничивает мышление.
12. В некоторых ситуациях и правда можно создать много добавочной ценности, если исправить проблемы и боли существующих продуктов.
Но подход через поиск наиболее эффективных способов решать задачи (быстрее, дешевле, больше) позволяет смотреть на новые технологии и методы их применения к разным задачам, чтобы сделать жизнь людей лучше.
#problem #gopractice
Ищу продуктового дизайнера.
1. Работаю продактом в Точке. Наша команда делает software-продукты для клиентов нашего банка и для не клиентов тоже.
2. В команде 20 человек. У нас несколько продуктов и мы работаем над ними в рамках маленьких Scrum-команд, чтобы быстро и эффективно развивать их.
3. Некоторые люди в команде периодически ходят из одной Scrum-команды в другую, когда в спринте появляются для них задачи. Например, это продуктовый аналитик, UX-исследователь, UX-редактор, тестировщики и продуктовый дизайнер.
4. Ищем продуктового дизайнера, который вольётся в нашу команду и будет вместе с нами перформить над нашими прекрасными продуктами.
5. В Точке есть дизайн-система и поддерживающее коммьюнити продуктовых дизайнеров. Дизайнеры друг другу помогают и поддерживают. И ещё тусят вместе, обмениваются опытом.
6. Наша команда не работает над классическими fintech-продуктами типа кредитов, банковских карт, инвестиций и т.д.. Мы делаем аналитческий софт, который использует банковские данные, и помогает предпринимателям вести свой бизнес безопаснее и эффективнее.
7. Продуктовый дизайнер не только рисует интерфейсы наших продуктов, но ещё участвует в проектировании UX и исследованиях пользователей.
8. Если среди вас или ваших знакомых есть продуктовые дизайнеры, которые хотели бы сменить работу, то давайте пообщаемся. Напишите мне @shashcoffe
1. Работаю продактом в Точке. Наша команда делает software-продукты для клиентов нашего банка и для не клиентов тоже.
2. В команде 20 человек. У нас несколько продуктов и мы работаем над ними в рамках маленьких Scrum-команд, чтобы быстро и эффективно развивать их.
3. Некоторые люди в команде периодически ходят из одной Scrum-команды в другую, когда в спринте появляются для них задачи. Например, это продуктовый аналитик, UX-исследователь, UX-редактор, тестировщики и продуктовый дизайнер.
4. Ищем продуктового дизайнера, который вольётся в нашу команду и будет вместе с нами перформить над нашими прекрасными продуктами.
5. В Точке есть дизайн-система и поддерживающее коммьюнити продуктовых дизайнеров. Дизайнеры друг другу помогают и поддерживают. И ещё тусят вместе, обмениваются опытом.
6. Наша команда не работает над классическими fintech-продуктами типа кредитов, банковских карт, инвестиций и т.д.. Мы делаем аналитческий софт, который использует банковские данные, и помогает предпринимателям вести свой бизнес безопаснее и эффективнее.
7. Продуктовый дизайнер не только рисует интерфейсы наших продуктов, но ещё участвует в проектировании UX и исследованиях пользователей.
8. Если среди вас или ваших знакомых есть продуктовые дизайнеры, которые хотели бы сменить работу, то давайте пообщаемся. Напишите мне @shashcoffe
👍1
Каким должен быть интерфейс для пользователя?
Продолжаю искать ответ на этот вопрос.
Вот что нашёл в книге The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback
Моё вольное #summary
I. Симптомы плохого UX:
1. Продукт кажется неинтуитивным и им сложно пользоваться.
2. Не получается найти что искал и не понятно что делать дальше.
3. Можно зайти в тупик или получить непонятное сообщение об ошибке.
4. Трудно читается текст или дизайн кажется неэстетичным.
II. Признаки хорошего UX:
1. Продукт кажется лёгким в использовании.
2. Легко найти что искал, и понятно что делать дальше.
3. Интерфейс даже не замечается и полностью сосредотачиваешься на выполнении задачи.
4. Продукт даже может быть забавным в использовании и давать положительные эмоции, типа уверенности и спокойствия.
5. Хороший UX может приводить в состояние, которое психологи называют "потоком", когда полностью погружаешься в продукт. В этом состоянии всё уходит на второй план и испытываешь полную вовлечённость, с удовольстивем от выполнения задачи.
III. Что делает UX хорошим?
1. Неважно, насколько простой в использовании или красивый продукт, он не сможет обеспечить хороший пользовательский опыт (User eXperience), если клиент не ценит преимущества, предоставляемые продуктом.
2. Один из способов оценить UX — это оценить, насколько он помогает или мешает выполнить задачу и почувствовать преимущества продукта.
3. Плохой UX мешает выполнить задачу и почувствовать преимущества.
4. Хороший UX позволяет легко выполнить задачу и ощутить преимущества продукта.
5. Также, хороший UX обеспечивает высокую степень удобства использования и восхищения.
#ux #ui #product #design
———
Пока склоняюсь к такому ответу, что пользовательский интерфейс (UI) должен не мешать (и даже помогать) выполнять задачу пользователя.
Кто что думает на этот счёт? Поделитесь опытом и мыслями в комментах, плиз.
Продолжаю искать ответ на этот вопрос.
Вот что нашёл в книге The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback
Моё вольное #summary
I. Симптомы плохого UX:
1. Продукт кажется неинтуитивным и им сложно пользоваться.
2. Не получается найти что искал и не понятно что делать дальше.
3. Можно зайти в тупик или получить непонятное сообщение об ошибке.
4. Трудно читается текст или дизайн кажется неэстетичным.
II. Признаки хорошего UX:
1. Продукт кажется лёгким в использовании.
2. Легко найти что искал, и понятно что делать дальше.
3. Интерфейс даже не замечается и полностью сосредотачиваешься на выполнении задачи.
4. Продукт даже может быть забавным в использовании и давать положительные эмоции, типа уверенности и спокойствия.
5. Хороший UX может приводить в состояние, которое психологи называют "потоком", когда полностью погружаешься в продукт. В этом состоянии всё уходит на второй план и испытываешь полную вовлечённость, с удовольстивем от выполнения задачи.
III. Что делает UX хорошим?
1. Неважно, насколько простой в использовании или красивый продукт, он не сможет обеспечить хороший пользовательский опыт (User eXperience), если клиент не ценит преимущества, предоставляемые продуктом.
2. Один из способов оценить UX — это оценить, насколько он помогает или мешает выполнить задачу и почувствовать преимущества продукта.
3. Плохой UX мешает выполнить задачу и почувствовать преимущества.
4. Хороший UX позволяет легко выполнить задачу и ощутить преимущества продукта.
5. Также, хороший UX обеспечивает высокую степень удобства использования и восхищения.
#ux #ui #product #design
———
Пока склоняюсь к такому ответу, что пользовательский интерфейс (UI) должен не мешать (и даже помогать) выполнять задачу пользователя.
Кто что думает на этот счёт? Поделитесь опытом и мыслями в комментах, плиз.
Про проверку множества гипотез на потоке
Занятная математика про количество проверяемых гипотез в статейке от Carrot quest про growth-hacking.
Моё вольное #summary
1. Чем больше гипотез проверяем, тем больше влияем на результат.
2. Пусть результатом для нас будет рост какой-то важной метрики. Например, кол-во пользователей или выручка.
3. Чтобы проверять много гипотез, важно как-то круто выстроить работу в команде.
4. Допустим, только 30% наших гипотез будут успешными и действительо повлияют на результат.
5. Тогда, если мы будем проверять по 10 гипотез в недельный спринт, то за год получится:
10 гипотез в неделю Х 30% успеха = 132 успешные гипотезы.
6. Пусть каждая успешная гипотеза даст нам 3% роста. Тогда 132 успешные гипотезы дадут нам 400% роста за год (сложный процент).
7. Если тестировать по 1 гипотезе за спринт вместо 10, то прирост будет 40% за год. Тоже хорошо.
8. Источником гипотез для команды должны быть данные о поведении пользователей, аналитика, опыт прошлых гипотез. Но не в коем случае не мнение начальства!
9. Написано классно, цифры красивые, но есть вопросики вопросов:
– Как правильно формулировать гипотезы?
– Где их брать в таком количестве, чтобы проверять их без остановки целый год?
– Как построить работу в команде так, чтобы научиться их проверять в таком количестве?
У кого есть опыт потоковой проверки множетсва гипотез долгое время? Можете поделиться опытом как у вас была построена работа?
#growth
Занятная математика про количество проверяемых гипотез в статейке от Carrot quest про growth-hacking.
Моё вольное #summary
1. Чем больше гипотез проверяем, тем больше влияем на результат.
2. Пусть результатом для нас будет рост какой-то важной метрики. Например, кол-во пользователей или выручка.
3. Чтобы проверять много гипотез, важно как-то круто выстроить работу в команде.
4. Допустим, только 30% наших гипотез будут успешными и действительо повлияют на результат.
5. Тогда, если мы будем проверять по 10 гипотез в недельный спринт, то за год получится:
10 гипотез в неделю Х 30% успеха = 132 успешные гипотезы.
6. Пусть каждая успешная гипотеза даст нам 3% роста. Тогда 132 успешные гипотезы дадут нам 400% роста за год (сложный процент).
7. Если тестировать по 1 гипотезе за спринт вместо 10, то прирост будет 40% за год. Тоже хорошо.
8. Источником гипотез для команды должны быть данные о поведении пользователей, аналитика, опыт прошлых гипотез. Но не в коем случае не мнение начальства!
9. Написано классно, цифры красивые, но есть вопросики вопросов:
– Как правильно формулировать гипотезы?
– Где их брать в таком количестве, чтобы проверять их без остановки целый год?
– Как построить работу в команде так, чтобы научиться их проверять в таком количестве?
У кого есть опыт потоковой проверки множетсва гипотез долгое время? Можете поделиться опытом как у вас была построена работа?
#growth
Первую сессию нужно проектировать
#перваясессия #активация #онбординг #продукт
1. Первая сессия в продукте супер-важна, потому что не все пользователи потом вернутся в продукт. А ведь только в первую сессию бывает 100% пользователей.
2. Когда мы приходим в незнакомый аэропорт и нам надо сдать багаж, получить посадочный, найти гейт, сходить в туалет и т.д., то что мы ищем глазами?
Правильно – указатели. Мы ищем навигацию.
3. Навигация – это не обязательно стрелочки. Указателями может быть и сама геометрия пространства – так, что мы просто не сможем повернуть не туда.
4. Первая сессия аэропорта спроектирована так, что люди улетают почти что со 100% конверсией.
5. Понятное дело, что люди очень хотят улететь, когда приходят в аэропорт, но ведь легко можно сделать аэропорт, где люди будут улетать с конверсией 0,2 – 0,4%.
Это сделать не сложно, например:
1. Убираем всю навигацию.
2. Убираем охранников, к которым можно подойти.
3. Даём людям пространство аэропорта на их усмотрение и полную свободу выбора.
(☝️свободу выбора там, где человек не умеет и не компетентен ориентироваться)
И что получим?
Правильно – табун людей, пытающихся выяснить где же тут посадочные талоны получить и т.д.
6. Во многих продуктах первую сессию вообще не проектируют. А надо бы. Когда мы получим шанс ещё раз заполучить 100% пользователей? Никогда.
7. Поэтому, наша задача спроектировать первую сессию так, чтобы больше людей поняли выгоду от нашего продукта.
8. И желательно, чтобы эта выгодая была как можно более эмоциональной или рациональной. Важно, чтобы чтобы люди её понимали и для них это было круто/клёво/классно.
По мотивам этого видео с Красинским
#перваясессия #активация #онбординг #продукт
1. Первая сессия в продукте супер-важна, потому что не все пользователи потом вернутся в продукт. А ведь только в первую сессию бывает 100% пользователей.
2. Когда мы приходим в незнакомый аэропорт и нам надо сдать багаж, получить посадочный, найти гейт, сходить в туалет и т.д., то что мы ищем глазами?
Правильно – указатели. Мы ищем навигацию.
3. Навигация – это не обязательно стрелочки. Указателями может быть и сама геометрия пространства – так, что мы просто не сможем повернуть не туда.
4. Первая сессия аэропорта спроектирована так, что люди улетают почти что со 100% конверсией.
5. Понятное дело, что люди очень хотят улететь, когда приходят в аэропорт, но ведь легко можно сделать аэропорт, где люди будут улетать с конверсией 0,2 – 0,4%.
Это сделать не сложно, например:
1. Убираем всю навигацию.
2. Убираем охранников, к которым можно подойти.
3. Даём людям пространство аэропорта на их усмотрение и полную свободу выбора.
(☝️свободу выбора там, где человек не умеет и не компетентен ориентироваться)
И что получим?
Правильно – табун людей, пытающихся выяснить где же тут посадочные талоны получить и т.д.
6. Во многих продуктах первую сессию вообще не проектируют. А надо бы. Когда мы получим шанс ещё раз заполучить 100% пользователей? Никогда.
7. Поэтому, наша задача спроектировать первую сессию так, чтобы больше людей поняли выгоду от нашего продукта.
8. И желательно, чтобы эта выгодая была как можно более эмоциональной или рациональной. Важно, чтобы чтобы люди её понимали и для них это было круто/клёво/классно.
По мотивам этого видео с Красинским
12 причин провала стартапов от CBInsights
#report #research #analytics #startups
Увидел у Игоря Шойфота в канале этот репорт от CBInsights.
73% приходится на первые 2 причины:
1. Кончились бабки и не смогли поднять инвестиции — 38%
2. Оказалось не нужно рынку – 35%
Остальные 10 пунктов – всего лишь 27%.
Значит нужно как следует исследовать спрос на рынке перед началом и найти достаточное количество денег.
#report #research #analytics #startups
Увидел у Игоря Шойфота в канале этот репорт от CBInsights.
73% приходится на первые 2 причины:
1. Кончились бабки и не смогли поднять инвестиции — 38%
2. Оказалось не нужно рынку – 35%
Остальные 10 пунктов – всего лишь 27%.
Значит нужно как следует исследовать спрос на рынке перед началом и найти достаточное количество денег.
1. Команды создают продукты, чтобы помогать людям решать задачи ещё лучше чем они это делают.
2. Чтобы добиться этой лучшести, продукт должен создавать добавочную ценность относительно существующих способов «делать это».
3. Если эта ценность становится достаточно велика, то определённый сегмент пользователей отказывается от существующих продуктов в пользу нового. Это и есть product/market fit.
4. После достижения product/market fit команды учатся привлекать новых пользователей из выбранного сегмента, предлагая выгоды.
5. Если выгоды «зацепили» пользователя и он зашёл попробовать - это ещё не значит, что он станет пользователем. Для этого нужно хорошо продумывать активацию.
По мотивам статьи на GoPractice: https://gopractice.ru/product/user_activation/
2. Чтобы добиться этой лучшести, продукт должен создавать добавочную ценность относительно существующих способов «делать это».
3. Если эта ценность становится достаточно велика, то определённый сегмент пользователей отказывается от существующих продуктов в пользу нового. Это и есть product/market fit.
4. После достижения product/market fit команды учатся привлекать новых пользователей из выбранного сегмента, предлагая выгоды.
5. Если выгоды «зацепили» пользователя и он зашёл попробовать - это ещё не значит, что он станет пользователем. Для этого нужно хорошо продумывать активацию.
По мотивам статьи на GoPractice: https://gopractice.ru/product/user_activation/