Когда дизайнеру не нужно ТЗ

И что ему нужно вместо этого.

Многие считают четкое ТЗ неотъемлемым артефактом работы дизайнера. Я расскажу о случаях, когда ТЗ не просто лишнее, но и может навредить проекту.

ТЗ подразумевает, что заказчик точно знает, что ему нужно. Например, новый сайт или доработка приложения. В этом случае дизайнера не интересует, сработает ли описанное в ТЗ решение. Его цель, причем довольно спорная, — удовлетворить клиента и двинуться дальше.

Почему спорная? Если мы соглашаемся, что дизайн должен решать проблемы пользователей, то в этом случае вы решите проблему лишь одного человека — заказчика. Да, вы получите свои деньги и перейдете к следующему проекту, но никогда не узнаете насколько эффективным было ваше дизайн-решение. Другими словами, вы не сможете расти.

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

Заранее сложно определить, какое решение сработает и каким образом. Мало того, многие решения нельзя реализовать сразу. Это происходит по двум причинам:

Каждый этап должен дать информацию, которая подскажет, стоит ли реализовывать выбранную функцию полностью.

Хороший пример — Instagram Shopping. Сначала команда внедрила возможность делать отметки на фото. Пользователь кликал на отметку и переходил по ссылке в магазин бренда. Теперь, проверив результаты решения, Instagram добавил возможность создать полноценный магазин внутри приложения.

Если бы Instagram реализовал полноценный магазин сразу, то компания потратила бы уйму ресурсов без гарантии, что этой функцией будут пользоваться.

Вспомните страницу профиля в Instagram. Она тоже менялась ни один раз, а некоторые эксперименты так и не внедрили после нескольких недель тестирования. Хороший пример продуктовой работы.

В первом случае вы снимаете риск необходимости новой функции, разбивая ее на несколько шагов, во втором — пошагово дорабатываете ее удобство. В обоих случаях четкое ТЗ не имеет смысла, потому что на каждом этапе вы узнаете что-то новое, за счет чего корректируете изначальную задачу и дорабатываете под нее решение.

Руководство должно ставить понятные цели, а дизайнер самостоятельно найти способ достичь их наилучшим образом. Эти цели должны основываться на конкретных проблемах пользователей.

До внедрения Instagram Shopping все продажи происходили по одному сценарию — «Пишите в Директ». В чате обсуждалась цена, товар и способ доставки. С внедрением полноценного магазина эта рутина будет попросту не нужна. Другими словами, будет решена проблема взаимодействия продавцов и покупателей. (Ну и, конечно, попытка решить главную проблему Цукерберга — обогнать Безоса.)

Реальность всегда смеется над четкими планами не только в разработке продуктов, но и в жизни. Четкие планы опасны, так как слишком фокусируют на определенном решении, из-за чего можно упустить отличную идею, которая откроется лишь в процессе.

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

Спасибо за прочтение, друзья.

Недавно описал пошаговый план развития дизайнера.
Мой Instagram, Telegram-канал.