Если вы планируете работы по проектированию или обновления пользовательского интерфейса в продуктах B2B, и не хотите выглядеть в глазах бизнеса белой вороной, вам требуется выявить объективную сложность (далее — масштаб) одного или нескольких цифровых продуктов.
Это поможет дать количественную оценку предстоящим затратам времени и ресурсов, обосновать их и выбрать, с какого из продуктов начать работу при прочих равных.
Как можно считать
Кажется, что достаточно посчитать макеты (скриншоты) и сразу станет понятно, какой продукт масштабнее. Но это неверно. Мы довольно быстро можем столкнуться такой ситуацией:
В одном продукте по требованию заказчика (просьбе разработчиков или тестировщиков) были покрыты макетами все возможные состояния, и мы увидим десятки или даже сотни макетов. Причём в некоторых случаях визуальную разницу между ними можно будет найти только, прочитав требования или задачу, по которым они были подготовлены. Ну допустим, в списке или таблице будет отличаться только подсветка пиктограммы, или в форме сообщения об ошибке будет разный текст. Важно ли это для понимания масштаба продукта? Очевидно, нет — полное покрытие макетами это безумие, явное перекладывание ответственности, очевидное затягивание сроков и бессмысленная работа в целом.
В другом продукте нет такого скрупулёзного покрытия макетами, там состояния могут быть вынесены в компоненты или приведены в типовых компоновках и шаблонах (что гораздо целесообразнее и правильнее).
Можем сделать ошибочный вывод, что второй продукт менее масштабный. В то время как оба продукта предназначены для достижения бизнес‑целей в рамках одного‑двух ключевых сценариев примерно одной сложности и в плане масштаба они в общем‑то равны.
Как считать правильно
Основная идея метода предлагаемой оценки заключается в том, чтобы считать разделы и формы, ориентируясь на сценарии. В этом случае нам важно не сколько элементов видно на экране, а сколько точек входа и шагов выполнения задач содержится в продукте в целом.
Что мы увидим в результате
Оценка — это буквенно‑цифровой код, ориентируясь на который даже незнакомый с методом человек может получить общее представление о масштабе.
Например: SX4-2, M6U2-2, L7U4-6
Думаю, что в таком порядке со сравнением оценок сложностей не возникнет — здесь используется уже привычная шкала размеров: XS, S, M, L, и далее.
Как это посчитать и объяснять?
Считать можно уже созданные или пока ещё планируемые макеты, или вообще пройти по существующему продукту. Здесь мы учитываем только уникальные разделы и формы, причём без состояний и повторений.
1. Число разделов
Посчитайте число разделов, начиная со стартового экрана (точки входа), и выберите подходящее начальное обозначение по таблице:
SX — 1 (Ну, как в анекдоте: «А меньше не имело смысла...»)
S — 2–3
M — 3–5
L — 6–9
X — 10–12 (Если вы дошли до этой строки, то вы перестарались и вам пора провести реструктуризацию продукта)
XL — 13–16 (Вы очень упорны)
XXL — 17–20 (Желаю вам крепкого здоровья, сил, терпения и такта. И побольше. Вас же там человек 30 работает над интерфейсом, верно?)
Не нашли подходящего обозначения? Вы никогда не закончите свою работу над продуктом или в вашей команде давно забыли, что и для кого делают.
2. Максимальная глубина разделов
Оцените вложенность каждого раздела: вкладки и формы вместе, выпишите максимальную глубину.
Например, у вас четыре корневых раздела, и в одном из них три вкладки, в каждой из которых можно открыть от одной до четырёх форм (создать, просмотреть, отредактировать — настроить — использовать, удалить). Запишите 7 (3 вкладки и максимум 4 формы).
3. Число уникальных продуктовых компонентов
Почти в каждом продукте встречаются компоненты взаимодействия, которые не входят в состав дизайн‑системы — такие, что их приходится реализовывать самостоятельно (собирать из атомов) или использовать сторонние решения. Запишите их число после буквы U.
Например, у нас есть график, который мы делаем сами и больше в других продуктах такого нет — пишем U1.
4. Ключевые сценарии
Не лишним будет указать число ключевых продуктовых сценариев, для которых создавался продукт. Продукт без сценариев вызывает вопрос для чего он создан. Обычно их штуки 3–4, за исключением продуктов‑интеграторов, которые частично или полностью включают в себя функциональность других продуктов. Запишите количество в конце оценки, отделив дефисом.
Вот и всё
Скорее всего в вашем продукте подсчёт не займёт много времени. Если возн��кают трудности, то, возможно, стоит подумать о наведении порядка в структуре ваших макетов. Если оценка очень велика, то продукт определённо стоит реструктурировать, чтобы пользователь не терялся и не просил добавить то, что там уже есть (ну об этом вы и сами уже задумываетесь, верно?).
Советы, вопросы и ответы
Главный совет: не мельчите.
Не считайте формы подтверждения действий, уведомления, валидацию и варианты сообщений об ошибках.
А как насчёт наполненности разделов и форм?
Учёт наполненности требуется скорее для оценки когнитивной нагрузки, а для этого уже есть методы и не один.А что делать, если метод не подходит?
Развивать этот или искать подходящий метод.Нет, правда — у меня нет стартового раздела
Но продукт‑то есть? Значит и точка входа есть, хотя бы кнопка или триггер.Я получил результат NNN, что с ним делать?
Зафиксируйте, разместите на видном месте и обновляйте. Кроме планирования, результат удобно показывать в отчётах как прогресс работы над продуктом: начали с SX4-1, а теперь доросли аж до M6U2-2! Или было XL32U9-8, но мы выкинули устаревшее, внедрили обновления, реструктурировали оставшееся и теперь у нас L7U4-6.
Кажется очевидным и даже скучным. Но нет ничего важнее обсуждения очевидных вещей. Представьте себе зелёный цвет, а теперь попросите коллегу сделать то же самое и показать на него пальцем. Не деритесь!
