Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта 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

Энтони из UX Movement написал о таком состоянии кнопки как «загрузка».

Его стоит показывать, когда пользователь нажал на кнопку, но система ещё не обработала запрос. Так пользователь понимает, что система работает, и не жмёт на кнопку повторно.

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

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

Чтобы пользователь лучше понимал, что происходит, текст на кнопке можно менять, например: «Отправить» → «Отправка…»

https://ux.pub/v-kakih-sluchayah-neobhodimy-knopki-s-indikatorom-zagruzki/

Принцип «Направляй, а не ругайся»

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

Если клиент не заполнил поле и жмёт на кнопку «далее» — направьте его: поставьте фокус на это поле, откройте клавиатуру. Можно написать аккуратное «Укажите» под полем ввода. Главное — не скатываться в нахально-безразличное «Обязательно для заполнения». Звучит, будто тётка на почте нахамила.

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

Меня тут спрашивают, зачем нужны шпаргалки, о которых я написал постом выше

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

Например, вы знаете основы JS, но всё чаще встречаете в примерах непонятный новый синтаксис — ES6. Вы можете прочитать про него длинную статью (например: http://babeljs.io/learn-es2015/), но, скорее всего, сразу всё забудете. Тут вам и придёт на помощь шпаргалка https://devhints.io/es6

Или вы установили себе модный редактор кода Visual Studio Code, но не знаете ни одного хоткея в нём. Вот шпаргалка с ними: https://devhints.io/vscode

Или вы решили научиться верстать флексбоксами, но постоянно забываете синтаксис. Шпаргалка вам его быстро напомнит: https://devhints.io/css-flexbox

Как Reddit аудиторию набирал

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

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

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

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

Как создавалась активность на Reddit?

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

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

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

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

Источник - https://m.habr.com/ru/company/changeagain/blog/298284/

Как отличить проработанное решение задачи от поверхностного

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

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

Есть универсальный вопрос, который позволяет отличить проработанное решение от поверхностного:
"Ты уверен, что лучше эту задачу нельзя было решить ?"

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

В общем, прорабатывайте решения и будьте в них уверены. Вдруг спросят: "Ты уверен?"