SRGID — как я думаю до того, как рисую

Самая частая ошибка в продукте — принять формулировку задачи за саму задачу. «Сделай сплиттер расходов», «добавь AI-ассистента», «нужен экран настроек». Вроде и звучит конкретно, и руки уже тянутся к макету. Но формулировка почти всегда описывает предполагаемое решение, а не проблему.

SRGID — это защита от этого прыжка. Пока я не прошёл Scope, Reality, Gap и Impact, я не могу переходить к Decision. Не потому что так будет красивее смотреться в будущем кейсе, а потому что решение, принятое до понимания, — это угадывание. Иногда угадывается, но чаще нет.

Пройди их по порядку — можно увидеть, как D открывается только после первых четырёх. Это и есть суть метода: каждый шаг готовит следующий.

S — Scope. Что это за задача на самом деле

Первым делом я не доверяю исходной формулировке. Определяю тип задачи: это фича, сценарий, целая система, координация, контент, визуал или код? Где её границы и кто в ней участвует. На выходе — продуктовая интерпретация задачи, а не пересказ тикета.

R — Reality. Что происходит сейчас

Фиксирую текущее состояние как есть. Что реально видит пользователь, какие ограничения есть у команды и платформы, что здесь подтверждённый факт, а что — моя гипотеза. Разделять факт и догадку критично: половина плохих решений растёт из гипотезы, которую приняли за факт. На выходе — имеем что имеем.

G — Gap. Где разрыв

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

I — Impact. Почему это важно решать

Не каждый разрыв стоит закрывать. Здесь я взвешиваю влияние: на пользователя, на бизнес, на процесс команды. Где уместно — привязываю к метрикам. Этот шаг отвечает на вопрос «а зачем вообще мы это делаем?» и помогает не тратить месяц на проблему, которой почти никто не замечает.

D — Decision. Продуктовый вектор

И только теперь — решение. Но это ещё не UI-детали и не цвет кнопки. Это направление: принцип изменения, который вытекает из первых четырёх шагов. Из Decision дальше растут IA, флоу и экраны — но сам он про «куда», а не про «как именно нарисовать».

Проще всего показать на живом примере. В кейсе Т-Банк — совместные поездки задача пришла как «сделать, чтобы друзья могли делить расходы в поездке». Классический сплиттер счёта. Вот как её развернул SRGID:

Если бы я начал с Decision, я бы нарисовал ещё один калькулятор дележа счёта — и промахнулся мимо настоящей боли. Первые четыре шага сместили фокус с «денег» на «контекст». Всё остальное в кейсе — следствие этого сдвига.

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