1. Дизайн Продукта / Задачи и функциональные требования

Я начала работать в качестве дизайнера продуктов (да-да, молоко, творог, яйца) два с половиной года назад, хотя веб-интерфейсы разрабатываю около 11 лет. Часть интересных вещей, которым я научилась, забываются. Новые знания пребывают в хаосе, а понимание вещей интуитивно. Я чувствую, как работает дизайн в продукте, но мне трудно объединить всё в систему и объяснить её не только кому-то, но и себе.
Поэтому я для себя (и для N.) решила повспоминать важные вещи, чтобы можно было к ним вернуться, восстановить старые хорошие привычки и объединить все это с текущим ощущением в какой-то законченный снимок картины мира. В общем, это будет моя версия “Things i have learned in my life so far”.
Не нужно воспринимать написанное мной как руководство к действию, потому что ко всему нужно относиться критически, мало ли в интернете (сумасшедших) экспертов. Но мне было бы приятно узнать, если кто-нибудь найдёт в этих постах ответы, к которым у него созрели вопросы, и интересно, в каких моментах я ошибаюсь.

Я разбила своё понимание того, чем я занимаюсь на восемь частей.
Первая и восьмая часть будут плавно переходить друг в друга, как Уроборос — змея, кусающая себя за хвост. Потому что в моем представлении работа над продуктом — цикличный, а не линейный процесс.
Когда я доросла до уровня, на котором стало интересно думать глубже концептов на тендер, с помощью гугла, википедии и всяких best practices начала свой увлекательный путь хождения по граблям в проектировании взаимодействия.
Перерыла ворох описаний, схем, планов, многостраничных спецификаций, сделанных, к несчастью, из самых лучших побуждений другими дизайнерами, менеджерами всех мастей, бизнес-аналитиками и другими небезразличными прекрасными людьми. У Миши Дубакова смешно написано про такие спецификации, почитайте.
Я честно пыталась применить их в работе, и обращала внимание на то, что не отваливалось на протяжении проекта. Постепенно пришла к выводу, что для правильного понимания того, зачем, для кого, как и в какой последовательности создаются продукты, необходимо совсем немного, а спеки, написанные юридическими иерархично нумерованными списками полезны, только если это приложение к договору. Ну и баню еще протопить.
Я отжала всю свою и чужую Имитацию Бурной Деятельности и оставила только следующие вещи:
Стейкхолдеры и их задачи
Цели и задачи проекта
Функциональные требования

Две главные сущности, которые находятся в постоянной зависимости друг от друга, и моя работа — придумывать в какой:
- Стейкхолдеры (Собственник, Руководители, Разработчики, Маркетинг, Пользователи).
- Проект. Может быть крупным (продукт), средним (функциональность, фича) или мелким (UI компонент). Деление условное, и я не буду вдаваться в терминологию, потому что это не важно.
У каждой из этих сущностей свои цели и задачи. Мне нужно сформулировать задачи второй через задачи первой.
1. Владельцы мясных лавок
Стейкхолдеры — люди (или роли), которые влияют на проект. Мне очень не нравится это слово, но хорошего перевода я не знаю, поэтому буду использовать его.
Стейкхолдеры бывают разных типов, а у каждого типа еще много ролей (например, Собственник, Руководители, Разработчики, Маркетинг, Пользователи). Можете погуглить, в интернете много страшных картинок, описывающих все возможные типы. Лишние пляски вокруг этих ребят пока кажутся мне ИБД, если вы помните, о чем я.
Что нужно о них знать, так это кто они, какие у них задачи, и в какой степени все эти ребята влияют на проект.
Ну и все. Казалось бы, что сложного, внимательно слушаем всех стейкхолдеров и решаем задачи, тех, кто важнее.
Но дьявол, как известно, в деталях. Пользователи выделяются из этой компании, потому что они представляют спрос, а остальные (руководители, маркетологи, разработчики) — предложение. Одеяло растягивается всегда в разные стороны. Кроме того, один человек может иметь несколько ролей, быть и владельцем продукта и пользователем. Поэтому доходит до парадоксов, когда пользуясь большим весом одной роли в проекте, человек продвигает задачи роли с меньшим весом.

Пользователи тоже не одинаковые. И задача одного пользователя может вызывать проблемы у других. Например, есть платящие ребята, которые кажутся более важными для проекта, потому что приносят деньги. Но сильный перекос в платящую аудиторию может нарушить общую экономику. Например, во free-to-play играх перекос в экономике в пользу донатеров отталкивает игроков, играющих бесплатно, они уходят, и донатерам некого «нагибать» 😞. В принципах занозы написано про что-то похожее.
Кого слушать? Это очень просто, как ездить на велосипеде, который горит, и ты горишь, и всё горит, и ты в аду. Проведу параллели с яхтами, потому что люблю их.
Есть курс относительно ветра (базовая функциональность), при котором парус наполняется, и яхта набирает ход. На одном курсе относительно ветра яхта будет идти быстрее, чем на другом, но яхта будет продолжать идти, даже если вы будете идти против ветра. Достаточно лавировать и держать выбранный курс за штурвалом. Если вы выкрутите штурвал слишком сильно или не докрутите его, парус провиснет, яхта замедлит ход или остановится совсем. Если ветер изменился, а курс вы оставили прежним — яхта остановится.

Ветер — задачи пользователей, курс судна — задачи проекта, течение — остальных стейкхолдеров. Пока они в какой-то степени решаются — яхта быстро или медленно, но идёт, до тех пор, пока чьими-то задачами не начали пренебрегать. Выход один — при изменении/добавлении функциональности мониторить use cases всех ролей, чьими интересами мы можем случайно пожертвовать.
Исследования пользователей
Есть огромное количество всяких интересных практик, которые нужно попробовать, но самое клевое, конечно, интервью. В ходе интервью мы проверяем свои гипотезы или просто слушаем и смотрим.
Общаться с человеком желательно в том контексте, в котором он пользуется продуктом. Каждый раз я нахожу неожиданные детали. То, что делают люди, показывая проблему часто гораздо информативнее, чем то, как они её описывают.
Еще мне очень нравятся всякие фотки с цветным стикерами на магнитных досках, которые делают UX дизайнеры со своими командами. Про них я могу вам рассказать ничего вообще. Скорее всего там происходит какая-то магия, о которой я не знаю.
В результате у вас будет:
- Описание стейкхолдеров;
- их проблем и задач;
- понимание веса каждой роли.

2. Цели и задачи проекта
Если проект не новый, то всё о пользователях известно. Поэтому на практике этот этап чаще не второй, а первый. Осторожно! Сейчас будет самый скучный экран этого поста, можно его перечитывать во время бессонницы.
Цель — то, к чему стремится проект или человек.
Может быть не достигнута никогда, оставаясь истинной, в отличие от задач. Например, «Качественное образование, интересное и доступное для всех.» Достигнем мы её? Не знаю. Может какая-нибудь СШ №156 тоже думает, что она качественная и интересная. Но зато, доступность направляет нас в сторону низкой стоимости или бесплатности с фокусом на отбор материалов по качеству и интересу, а не соответствию программам министерства образования.
Задача — конкретное действие, которое выполняется для достижения этой самой цели. Есть еще проблема — задача с противоречием в определении.
Задачи проекта следуют из задач ролей примерно так:

Есть мелкие звоночки, которые могут указывать на то, что с вашим велосипедом что-то не так, и вы скоро будете в аду. Или вы уже в аду, и не понимаете почему все вокруг довольные и улыбаются.
а) Когда цели и задачи никак не формализованы и волшебным образом живут у каждого в голове.
В интернете есть 100500 статей на тему почему важно формулировать все важные штуки письменно в доступном месте, можете их все прочитать. Моё понимание такое — нам нужен одинаковый фреймворк, в рамках которого мы принимаем решения. Чем больше людей в этом участвует, тем больше разночтений и противоречивых решений в продукте.
б) Когда вместо задачи проекта вам формулируют решение.
Компетентные ребята не формулируют решение вместо задачи. Если вам не повезло, то придется взять часть работы на себя и определять задачу/проблему самостоятельно. Найти пользователей с проблемой, взять интервью, исследовать, поспорить, подраться, в конце концов. В конечном счёте никому не интересно, повезло или не повезло с коллегами или клиентами. То, что сделал дизайнер — результат работы дизайнера.
Просто невероятно, сколько сбивающих с толку форм, ненужного мелкого функционального мусора, лишних полей, странных переселектов с двумя значениями, обманчивого взаимодействия может сгенерировать простая фраза: «Оксана, давай просто добавим поле», а Оксана не спросила «Зачем?».
3. Функциональные требования
Функциональное требование — описание поведения системы между обстоятельствами и желаемым результатом.
Я пользуюсь фрактальным (Мандельброт one love) методом впихивания_всего_в_одну_картинку. Скудный формат «Стейкхолдер — Задачи — Функциональные требования, решающие его задачи» держит меня в тонусе и не дает размазывать формулировки.

Когда у меня есть такая схема функциональности, связанной со стейкхолдерами, продукт воспринимается не как набор фич, а как единая органичная система, где каждая задача решается без ущерба для других. С ней легко приоритезировать функциональные требования, потому что легко подняться на уровень выше и посмотреть, какая задача важнее. Или выделить только ту функциональность, с которой реализуется ключевая особенность продукта. И самое главное — такая схема помогает отличать необходимости от возможностей.
Затем функциональные требования можно разбить на функциональные блоки (фичи и стори). Я предпочитаю job story, потому что в её формулировке на первом плане контекст.
Сравните:
User Story
Как сотрудник компании, я хочу взять больничный, поэтому я могу написать в канал slack.
Job Story
Когда я приболел, я лежу в соплях и в постели, и хочу взять больничный, так что я могу написать в канал slack с мобильного телефона.
Контекст важен. Роль тоже важна, потому что функциональность может решать задачи разных ролей. Но в моей схеме роли уже определены, осталось только упомянуть нужную.
У Ryan Singer в статье “How a product is like a function” очень здорово описано, что такое функциональность. Кроме того, его формулировка похожа на job story, в основе которой лежит мой любимый контекст. Статья уложила все сущности в систему в моей голове. Я объединила его схемы с моей, и вот что у меня вышло.
У Райана на входе ситуация (x) к которой применяется функциональность (f), а на выходе результат (y).

“The user starts in some circumstance x. Whatever product or solution they apply is a function f(). Applying the product to that circumstance f(x) produces a result: y.”

Потом он вводит Δ для определения ценности (value) и сравнивает с результатом(y):

Я бы роль пользователя (x2) тоже упоминала, поэтому формулировка в моей версии job story скорее будет такой как на картинке.

Результат мы тут же можем сравнить ценностью (y и Δ). И вот тут должны появится метрики успеха, которые в отрыве от контекста тоже мне всегда казались ИБД.
Кажется, что ценность (Δ) и есть задача пользователя. Получается, что мой метод впихивания_всего_в_одну_картинку можно выразить так:

Другими словами, я на на своей схеме стараюсь сообразить, какая функциональность должна быть в продукте, чтобы решить задачи определённых людей. А job story помогает понять, какой результат и какая именно реализация функциональности лучше всего подойдёт к задаче.
Ну вот, получилось четко и сухо, мне нравится. Сущностей ограниченное количество, и они протягиваются через проект. Почитайте и послушайте Райана ещё, он классный.
Документирование
Документирование – это тоже проектирование взаимодействия, мои маленькие любители многостраничных талмудов.
Фиксируем выводы. Каждый раз одни и те же грабли, ей богу. Наслаждаюсь когда на каком-нибудь собрании человек произносит что-то совершенно неожиданное, уверено добавляя что все же итак это прекрасно знают 🤦
Чем меньше проект, тем меньше хочется возиться с формулировками. Кажется, что это какая-то бюрократия, просто уже давайте сделаем и разойдемся. Но когда что-то начинает идти не так, люди ориентируются не на первоначальный курс, а ошибки в решении. Как человек, который заблудился в лесу со своим горящим велосипедом ориентируется не на солнце, а на места, где, как ему кажется, он уже был.
Все наши открытия доступны в таком месте, чтобы люди не могли их не прочитать. Не читают— набираем 22 кеглем, произносим вслух, присылаем ночью СМС, делаем татуировку в зависимости от степени нашей неадекватности.
Основной документ один, в нем концентрировано перечислены выводы со ссылками на первоисточники, чтобы погрузиться в какой-то отдельный вопрос. Человек должен узнать о продукте/фиче/проблеме без дополнительных переходов в другие места.
P.S. Ах да, есть еще нефункциональные требования, про которые я пока только знаю, что они есть. Если вам есть что про них рассказать, напишите, пожалуйста, в комментарии или в facebook.

