Помню, когда наше дизайнерское агентство только начинало раскручиваться, мы создавали сайты с многоязычной поддержкой. А так как в те годы многоязычная поддержка еще не являлась стандартной функцией, то и стоила она дорого. Я не задавался вопросом, для чего она нужна заказчику и уж тем более как будет переводиться их контент. В результате функция никогда не использовалась. В основном я внедрял их пожелания, а не удовлетворял нужды их бизнеса. Соответственно, я тратил кучу денег заказчика.
Чем больше функций вводится, тем больше сложностей и выше цена. Ваша задача – помочь заказчику придерживаться простых вещей.
Вы, возможно, уже заметили, что здесь красной нитью проходит одна тема: всегда поддерживайте простые решения. Ваша задача как веб-разработчика состоит в том, чтобы воздерживаться от излишеств как своих, так и заказчика. Вместо того чтобы глобально переделывать сайт, остановитесь на искусной перегруппировке. Вместо того чтобы добавлять больше функций, определите набор простых функциональных возможностей и придерживайтесь его. Вместо слепого поклонения новейшим трендам сосредоточьтесь на простом, вечном и классическом.
Это гарантирует заказчику высокий показатель возврата средств, которые он вложит в сайт, работая с вами. А также сведет до минимума опасность последней ловушки при переделывании любых проектов: негативной обратной связи.
Что делать с негативными отзывами
Я уже говорил о том, что реакция людей на изменения редко когда бывает положительной. Некоторые из нас просто не любят изменений, а другие разочаровываются в них, потому что все изменилось не так, как они ожидали. В любом случае все изменения на сайте, вызовут реакцию и у пользователей, и у заинтересованных в бизнесе лиц.
Мы установили, что минимальные изменения уменьшат шансы на критику. Но это не всегда возможно, а даже если и получится, вы все равно получите негативную обратную связь. Не следует доверять первым откликам, будь они положительные или отрицательные.
Я вспоминаю, как мы обсуждали этот вопрос с Даниелем Буркой, когда он был ведущим дизайнером в Digg. Он рассказывал мне, как сложно ему было не реагировать на критику сразу же, после того как выходил в свет новый элемент его проекта. Он предпочитал тут же решать кажущуюся проблему. Но потом он научился тому, что если подождать пару недель, пользователи привыкают к изменениям и принимают их. В конце концов, это стало его стандартным методом. Он не делал дальнейших изменений до тех пор, пока элемент проекта не проживет хотя бы двух недель.