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

Lena Dorogenskaya
Sep 9, 2018 · 9 min read

Я начала работать в качестве дизайнера продуктов (да-да, молоко, творог, яйца) два с половиной года назад, хотя веб-интерфейсы разрабатываю около 11 лет. Часть интересных вещей, которым я научилась, забываются. Новые знания пребывают в хаосе, а понимание вещей интуитивно. Я чувствую, как работает дизайн в продукте, но мне трудно объединить всё в систему и объяснить её не только кому-то, но и себе.

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

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

Я разбила своё понимание того, чем я занимаюсь на восемь частей.

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


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

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

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

Я отжала всю свою и чужую Имитацию Бурной Деятельности и оставила только следующие вещи:

Стейкхолдеры и их задачи

Цели и задачи проекта

Функциональные требования


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

  1. Стейкхолдеры (Собственник, Руководители, Разработчики, Маркетинг, Пользователи).
  2. Проект. Может быть крупным (продукт), средним (функциональность, фича) или мелким (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.

Посвящаю это яйцо Захару Шлимакову

Lena Dorogenskaya

Written by

Designer at Vizydrop.com | dorogenskaya.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade