Как дизайнеру интерфейсов правильно принимать задачу: 18 вопросов, которые спасли меня от факапов и переделок
Раньше я прыгал в работу, не докопавшись до сути. Сейчас у меня есть шаблон, который помогает разобраться в задаче, еще до Figma. Делюсь им — может, и тебе пригодится
Как я раньше брал задачи (и почему это было больно)
Раньше я начинал работу сразу: открывал Figma, накидывал макет, искал красивые референсы. Но в какой-то момент всё начало разваливаться.
То бизнесу что-то не то. То юзеры не понимают, как этим пользоваться. То проект уходит в сторону. То появляется кто-то с фразой: «А вы вообще зачем всё это делаете?»
И ты стоишь, как школьник у доски, не зная, что сказать.
Мне стало ясно: фигачить «по верхам» больше нельзя. Нужно задавать вопросы. Много. До тошноты. Пока не станет по-настоящему понятно.
Я собрал свой шаблон вопросов
Я сделал шаблон, который теперь использую перед каждой задачей. Да, он большой. Да, иногда кажется, что «и так всё понятно». Но почти всегда, когда кто-то отвечает на эти вопросы, мы находим новое. Настоящее. Важное.
Делюсь этим шаблоном — с пояснениями и формулировками, которые я сам использую в диалоге.
Вот что я спрашиваю перед стартом задачи
Начинаем с сути
Что вообще надо сделать?
Без лишнего — одно-два предложения
Какую проблему мы решаем?
Не фичу, не хотелку. А проблему.
Почему это важно? А зачем? А если не делать?
Я реально 5 раз подряд спрашиваю: а зачем?
Понимаем бизнес и процесс
Как выглядит текущий процесс?
Если есть схема — супер. Если нет — рисуем её сами. Часто после этого половину задачи можно выкинуть.
Какая цель бизнеса?
Что конкретно должно измениться после запуска? Конверсии? Время? Вовлеченность?
Что произойдет, если задачу не решим?
Это часто вскрывает настоящую мотивацию команды
Погружаемся в пользователя
Кто наша аудитория?
Возраст, роль, поведение, опыт, привычки.
Какую задачу хочет решить пользователь?
Тут не про фичу, а про его боль. JTBD-шный подход.
Как он решает это сейчас?
Что делает вручную? Где костыли? Что бесит?
Какие сценарии мы хотим поддержать?
«Я как пользователь хочу…» — и так 3–5 штук.
Откуда он вообще к нам приходит?
Понимаем контекст
Что не так с текущим решением?
Что уже пробовали? Что не работает? Почему взялись за это сейчас?
Какие есть требования и ограничения?
Техника, законы, сроки, политика.
Формируем решение
Какая идея фичи?
Какое поведение и какие возможности должны быть в интерфейсе?
Что будет критерием успеха?
Как поймем, что всё получилось?
Есть ли референсы?
Кто делал подобное? Почему это хорошо (или плохо)?
Подключаю немного ТРИЗ (но по-простому)
Давай представим идеальный результат.
Что должно измениться в идеале, если всё пойдет по плану?
А если пойти дальше — можно ли вообще обойтись без этой фичи?
Представь, что функции выполняются, но объекта нет. Часто появляются неожиданные идеи.
Какие противоречия в задаче?
Например, хочется и просто, и информативно. Или и быстро, и надежно. Это важные штуки, которые потом всплывают как баги или фидбэк.
Этот шаблон — мой якорь
Я не всегда задаю все вопросы дословно. Иногда в разговоре они звучат иначе. Но каждый пункт — проверка на то, что я действительно понимаю, что делаю.
С тех пор, как я начал использовать этот подход:
- стало меньше правок,
- стало проще защищать дизайн,
- появилось чувство, что я действительно решаю проблему, а не просто делаю «ещё один экран».
Помогу освоить дизайн, найти работу и повысить грейд. Мой проект X-Mentors — это самое доступное и честное менторство для дизайнеров
Главное отличие от курсов и других менторских школ — формат. У нас нет ограничений по встречам, сложных тарифов и долгого ожидания обратной связи. Ты можешь начать с 7-дневного бесплатного периода, чтобы попробовать и понять, подходит ли тебе такой формат.
Мы делаем упор на практику и живое взаимодействие 1 на 1. Я помогу выстроить понятный план развития и буду давать честную обратную связь, чтобы твой путь в дизайне стал проще и увереннее.