Дао веб-строителя

в 12:30, , рубрики: web-разработка, бизнес-процессы, веб-дизайн, Веб-разработка, реальный мир, метки: , ,

Дао веб строителя

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

Все мы очень любим смотреть на интересно сделанные сайты. Нестандартный скролл, параллакс, типографика — всё это очень привлекает и радует глаз. Нынешние дизайнеры при использовании современных технологий в состоянии реализовать любой каприз заказчика и собственной фантазии. С другой стороны, средства программной разработки развиваются столь же интенсивно. Различные фреймворки, SASSы и прочие радости жизни ускоряют процесс и облегчают жизнь программистам и верстальщикам. Казалось бы, живи и радуйся, веб-индустрия, сверкай бриллиантами гениальной интерактивности, раздвигай рамки привычного скучного мира однообразных сайтов…

«Но» обязательно будет. Но в конце :)

Много миллионов раз до меня было сказано, что пользователи ходят в интернет за информацией, что «content is the king» и всё в таком духе. С этим глупо спорить: как правило, всех нас интересует именно информация, не столь важно в каком медийном виде она представлена, текст, фото или видео. Однако, правильный контент ещё надо уложить в прокрустово ложе таксономии и разбить на правильные блоки с нужным содержанием, расположенные в нужных местах и в нужный момент. Опять же, необходимо проставить теги или что-то их заменяющее для того, чтобы посетитель мог одним-двумя кликами сгруппировать блоки контента по своему усмотрению. В сумме это можно называть «информационной архитектурой».

В свою очередь, информационную архитектуру часто путают с модным термином «юзабилити», означающим по сути «удобство пользования». Уточню термин: говоря о юзабилити, большинство людей имеют в виду красиво свёрстанные формы и правильные кнопки, то есть визуальную сторону вопроса, интерфейс. Нельзя сказать, что юзабилити и информационная архитектура не пересекаются, но это всё же разные вещи, работающие на одну цель: повышение скорости работы с системой.

Но самое главное в том, что всё вышеперечисленное — не задача, а лишь средства её решения.

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

Пример неправильной задачи: сделать интернет-магазин так, чтобы конверсия составляла 20%. Какому бизнесу, скажите на милость, нужна конверсия любого уровня, если после первой же попытки заказа покупатель бежит в Яндекс.Маркет писать гневный отзыв об омерзительной работе службы доставки? Причём конверсия первичных покупателей действительно может быть высокой… ровно до тех пор, пока волна гневных отзывов не накроет весь проект медным тазом.

Понятное дело, что сказанное относится к любой разумной деятельности человека: сначала пойми задачу, потом выбирай способ реализации. Просто лично я последнее время слишком часто сталкиваюсь с тем, что даже у хороших технических специалистов (а иногда — именно потому, что они хорошие специалисты) технологическая красота решения затмевает исходную задачу. Вау, параллакс! Вау, типографика! А на телефонные звонки, например, отвечает робот, и живого оператора дождаться нереально.

Так вот, моё мнение: дао веб-строителя — создание реально работающего инструмента ведения бизнеса, а не удовлетворение собственных дизайнерских или технологических амбиций.

Дао веб строителя

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

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

Могу гарантировать, что на этом пути придётся прорубаться сквозь непонимание заказчика и другие трудности, но, честное слово — результат того стоит, и в итоге сделанный сайт сделает мир немного лучше, а не станет очередной технологической погремушкой.

Автор: speedy095

Источник

Поделиться

* - обязательные к заполнению поля