Вадим Митякин написал о проектировщике в рамках продюсерского подхода к созданию цифровых продуктов

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

Проектирование — моделирование будущего продукта, работа с гипотезами о реализации тех или иных его частей.

Нет универсального навыка проектировать любые системы на любых технологиях для любых отраслей. За проектировщиком стоят:
— Реальный опыт создания систем, когда у него была возможность проверить разные гипотезы и узнать, как может вести себя система в реальной рабочей среде;
— Системный подход — поиск и своеобразные вычисления, за которыми стоят и прототипирование и способность смотреть на задачу с разных точек зрения.

Проектировщик — человек, имеющий привычку принимать решения. И имеющий достаточно смелости для этого.

Как состояться в профессии:
1. Насмотренность — знакомство с разными областями знаний;
2. Исследования — освоение выбранной области знаний;
3. Мастерство — использование своих знаний и создание новых областей знаний.

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

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

Как генерировать идеи для продукта

Внешние источники:

1. Тренды в вашей индустрии: что происходит на рынке
2. Что делают конкуренты
3. Какие фичи просят пользователи конкурентов
4. Что делают похожие бизнесы на других рынках (например, Amazon vs InstaMart in India)
5. Что обсуждают на конференциях/форумах/спец ресурсах в вашей индустрии
6. Какие фичи просят ваши пользователи

Внутренние источники

7. Что пользователи делают в продукте (или не могут сделать); как выглядит user journey
8. Что говорят пользователи, которые перестали пользоваться продуктом
9. Что говорят другие отделы, которые общаются с пользователями (саппорт, сейлзы, маркетинг)
10. Что говорит руководство компании/топ менеджеры/лидеры
11. Что делают другие команды в вашей компании, есть ли возможность для коллаборации или заимствования
12. Догфудинг (интенсивное использование продукта самой командой)
13. Небольшие сфокусированные дискуссии с командой
14. Работа в "обратную сторону" от видения: если вы хотите достичь X, какие проблемы должны быть решены

Важно помнить, что все это лишь источники идей, а не руководство к действию. Все идеи нужно попытаться кластеризовать и выделить темы на уровне проблем/возможностей для пользователей; а дальше уже определить потенциальный импакт от решения этих проблем и MVP для проверки гипотезы.

Заметки на полях. Из психологии.

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

Общая формула: событие → [автоматическая мысль] → эмоция

П Р И М Е Р

Событие:
прилетает внезапная срочная задача

Автоматическая мысль, которую не замечаем:
«Я не справлюсь» (или «Я могу не справиться»)

Эмоция:
тревога

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

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

То есть ты получил новую задачу, еще даже не узнал детали, не погрузился, но уже испытываешь тревогу. И все из-за автоматической мысли «Я не справлюсь» (или «Я могу не справиться»), которая не основана вообще ни на чем.

Автоматические мысли, разумеется, появляются постоянно, а не только на работе. Это могут быть мысли о себе (как в примере), о других, о самой ситуации.

И понятно, что будет полезно уметь замечать и работать с автоматическими мыслями в обычной жизни. Если вам интересно чуть подробнее покопать для себя эту тему, то можете просто начать хотя бы со статьи на Википедии (https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%BC%D1%8B%D1%81%D0%BB%D0%B8), чтобы как-то сориентироваться. Понимаю, что источник не самый глубокий, но для старта может подойти.

И здесь хочется привести только опросник об автоматических мыслях Джудит Бек, который хоть немного может помочь поработать с автоматическими мыслями:

1. Каковы доказательства, поддерживающие эту идею? Каковы доказательства, противоречащие этой идее?
2. Существует ли альтернативное объяснение?
3. Что самое плохое может произойти? Смогу ли я пережить это? Что самое лучшее может произойти? Каков самый реалистичный исход?
4. Каковы последствия моей веры в автоматическую мысль? Каковы могут быть последствия изменения моего мышления?
5. Что я должен делать в связи с этим?
6. Что я мог бы посоветовать ___ (другу), который находится в такой же ситуации?

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

Аутсорс-дизайн

Аутсорс-дизайн

С точки зрения бизнеса и денег аутсорс-дизайн очень на грани. И я почему то думаю, что это только про сложные интерфейсы.


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


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


3. Ниндзя-дизайнеры.
В аутсорсе ты либо работаешь в том промежутке времени, в который сам оценил проект, либо уходишь в минус по деньгам.
Значит нужны люди, которые быстро во все въезжают(а каждые 4 месяца — новый проект), которые не прокрастинируют, которым не нужно нетворкаться 2/3 времени, которые не уходят в творческий кризис на неделю.
Которые за сжатые сроки делают охуенно и не устают от динамики студии.
Таких на рынке единицы. И, получается, что требования у нас завышенные. И те кто нам по этим критериям не подошёл — просто шикарны для продуктовых процессов.


4. В команду и процессы нужно вкладывать постоянно.
Оптимизируешь, растишь, учишь, разбираешь ошибки, проверяешь и улучшаешь процессы, ревьюишь задачи.
Даёшь энергию, поддерживаешь — вытягиваешь эмоционально, помогаешь с барьерами. Это какой-то постоянный коучинг. Это никогда не заканчивается, идёт всегда и фоном.
Но с этим нельзя и переборщить, потому что вы всё-таки деньги тут зарабатываете, а не в обучающую академию играете :)

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

А нет, не с другой стороны, всё с той же. 😂

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

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

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

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

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

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

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

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

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

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