Вторая часть рассуждений о гуманистическом дизайне

Заказчик в нашем случае — это, как правило, бизнес или государство. За приложением или сайтом он приходит не из тяги к прекрасному. Ему эти продукты нужны для решения каких-то своих, совершенно конкретных задач.Чтобы было проще, остановимся на заказчике от мира бизнеса (самый распространенный случай). Так вот, задача у бизнес-заказчика всегда одна: получить больше прибыли. Даже если он свою задачу так прямо не озвучивает. И здесь нет ничего — это про здоровое желание развития бизнеса.

«Нам нужно удобное приложение, чтобы клиенты могли заказать прогулку по Неве прямо со своего телефона» — говорит заказчик. Во что это распаковывается на самом деле: 👉 Мы хотим освоить еще один канал продаж. То есть, получать больше заявок на входе и больше продаж на выходе. Прибыль растет. 👉 Мы хотим разгрузить наших менеджеров. То есть, либо их силы можно будет направить на более важные задачи, либо штат можно будет просто сократить. Расходы снижаются, а значит — прибыль растет. 👉 Мы хотим поддерживать постоянный контакт с клиентами. То есть, иметь возможность напоминать о себе через пуш-уведомления, присылать им индивидуальные предложения, в конце концов, просто постоянно «присутствовать» на их телефонах. Больше касаний с клиентом — больше вероятность повторной покупки. Повторные покупки растут… ну, вы поняли. Прибыль, да.

Таким образом, если обобщать все сказанное — мы должны помочь бизнес-заказчику заработать. Мой пример с организацией сценариев в приложении из предыдущего поста достаточно наглядно показал: чем меньше мы любим пользователя при проектировании приложения, тем больше у него возникнет причин «слиться» и не донести денег. Хорошая новость: наоборот тоже работает! Чем больше пользователей мы оставим довольными, тем больше денег в итоге дойдет до заказчика.

Еще раз, приложение должно радовать в первую очередь пользователя, а не заказчика. Если мы дизайним то, что усложняет пользователям жизнь только потому, что нам так сказал заказчик — мы вредим сразу всем. И то, что заказчик за проект платит деньги — это не оправдание, а отягчающее обстоятельство. Потому что мы уже выяснили, что для заказчика приложение — это инвестиция, которая должна драйвить новую прибыль, а не веселый способ потратить имеющуюся. Тупое соглашательство — одна из причин, почему в мире гораздо больше недолюбленных пользователей и таких же недолюбленных заказчиков! 🫠

Тут же хочется заметить, что уход в другую крайность тоже недопустим. Если дизайнер нацепил корону и не желает (а чаще — не умеет) аргументировать заказчику почему нужно сделать иначе — то высока вероятность того, что это просто осел, которого научили пользоваться Фигмой.

Заказчик имеет право выражать любые пожелания, даже если они противоречат всем принципам хорошего дизайна — просто потому, что он эксперт в своем бизнесе, а не в дизайне. И настоящая любовь к заказчику — она в том числе в том, чтобы уважительно и понятно объяснить ему, где он ошибается. И вообще, теплое человеческое общение — стоит гораздо дороже холодного птичьего языка из «диджитальных терминов»! 🤗

Наконец, довольно очевидно, что любовь к заказчику подразумевает соблюдении договорных обязательств. Думаю, это база, которую излишне комментировать. Ну а в следующем посте я наконец расскажу о том, как дизайнеру можно (и нужно!) любить разработчиков! 👨‍💻