Владимир Лалош написал о FAQ (частых вопросах).

В FAQ должны быть вопросы, которыми реально интересуются пользователи. Например: «Зачем приложению мои данные?» Прочитайте, что люди спрашивают в соцсетях, о чём говорят в отзывах, с чем обращаются в колцентр.

Формулируйте вопросы так, как их задал бы человек. «Вы гарантируете безопасность оплаты банковской картой через интернет?» → «А платить у вас картой безопасно?»

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

Если вопросов много, распределите их по разделам.

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

https://medium.com/maratori/501067e7a8da

Вадим Шлячков написал о законе Хика.

В статьях (и даже в википедии) пишут, что закон Хика утверждает следующее: с увеличением количества вариантов увеличивается время принятия решения.

В своей работе Хик пишет не о «времени принятия решения», а о «времени реакции выбора», что не одно и то же.

1. Время простой реакции (simple reaction time) — испытуемый даёт единственный ответ на единственный раздражитель.
2. Время реакции выбора (choice reaction time) — от испытуемого требуется реагировать различным образом на разные типы раздражителей.
3. Время реакции различения (discrimination reaction time) — предполагает единственный ответ на один из нескольких раздражителей.

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

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

Также исследования показали, что закон:
— Перестаёт работать после практики. После 6000 попыток время реакции на 8 вариантов раздражителей приблизилось ко времени реакции на 2 варианта.
— Не работает, когда раздражитель и способ реакции взаимосвязаны. Надо указать стилусом на подсвечиваемую область.
— Не распространяется на реакцию зрачков.
— Не учитывает эффект последовательностей.
— Ограничен количеством вариантов. Время реакции в эксперименте с 1023 вариантами отличалось всего на 20−30 мс от эксперимента с 31 вариантом.
— Не всегда хорошо описывает ситуацию, когда пользователь может связать предлагаемые варианты ассоциациями.

https://medium.com/v.shliachkov/2d577e005a69

Нужно ли платить за услуги консультантов и бизнес-трененов?

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

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

Это часто создает иллюзию бесполезности консультаций: мне помогли осознать то, что я и так знал все это время. Еще и за деньги 🙁 Я ведь и сам мог ...

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

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

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

Три правила организации процесса дизайна

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

Отмена

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

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

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

Выводы
Делайте кнопку «Отмена» темно-серой, чтобы пользователь воспринимал ее как возврат в безопасную зону, а не призыв к действию. 

Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

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

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

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

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

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

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a