Очень близкая мне статья про сторифреймы

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

— Так, и что тут у вас?
— А вот поглядите, можно сохранять любимые места из книг.
— Хм... а из электронной можно?
— Можно, хотите загрузить?
— Да. Ок загрузил, а где теперь найти?
— А вот, посмотрите в ленте.

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

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

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

Мягкие навыки для продуктовой работы

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

Но есть ещё личные качества или мягкие навыки, они же soft skills. Глобально выделяют довольно капитанские навыки: умение работать в команде, гибкость, эмпатия, широта взглядов, стрессоустойчивость, управление временем и т.п.
Я не люблю слово "капитанские", но здесь оно прекрасно подходит — очевидно же, что мало кому нужен закостенелый угрюмыш, не умеющий разговаривать с людьми.

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

Это было краткое вводное в понятия hard/soft skills.

А теперь к делу — какие же мягкие навыки нужны тем, кто работает в продуктовых командах?
Помимо очевидных, я бы выделил следующий ТОП-5:
1. Любопытство и тяга к знаниям
2. Умение доставать нужную информацию
3. Решительность и находчивость
4. Структурирование информации
5. Умение вовремя остановиться

Могу рассказать по каждому навыку с примерами из опыта- почему навык важен и как его проверить/проявить.
Надо?

Иван Емелюшкин написал, что может предпринять дизайнер (не фрилансер), если у него кончились задачи.

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

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

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

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

4. Проведите пользовательское тестирование с опытными пользователями и новичками. Пройдитесь по основным и второстепенным сценариям.

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

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

7. Заявите о себе: напишите статью, распишите кейс, опубликуйте работу в портфолио.

https://designpub.ru/67ac0a28a732

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

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

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

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

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

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

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

Эффективно, когда команда встречается с незрячим тестировщиком, вместе с ним тестирует интерфейс и на месте договаривается о том или ином решении.

https://medium.com/Valeria.kurmak/73845933b550

Командообразование

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

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

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

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

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

С каждой новой итерацией мы менялись ролями внутри команды и брифами с другими командами. Чтобы мы не расплавлялись Саша закручивал гайки: сначала на работу отвели 7 минут, потом урезали речь менеджера на защите до 3 предложений, а в самом конце от начала работы до презентации прошло всего три минуты.

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

🏍️ Более быстрая лошадь

🏍️ Более быстрая лошадь

Продуктоводы любят цитировать Генри Форда:

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

Вывод делается такой, что пользователи, мол, сами не знают, чего им надо.

Кажется, в этой байке очень мало хорошего:

1. «Если бы спросил, они бы попросили». Да откуда ты знаешь? Спроси сначала — мало ли, вдруг ответы тебя удивят.

2. Допустим, реально ответили, что нужна «более быстрая лошадь». Это весьма полезная информация, только надо сфокусироваться на «быстрая», а не «лошадь». Почему важна именно быстрота, а не выносливость, комфорт или там стоимость владения? Что смогут они такого делать, чего раньше не могли? Сразу возникают вопросы, которые помогут увидеть правильное направление.

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

4. Средний продуктовод — далеко не Генри Форд (сорян). Не грех и спросить, корона не свалится.

В общем, я за другую цитату Форда:

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