UX-специалист или UX-команда?

Теория и практика -
Share Button

Не так давно приятно было услышать вопрос от программиста: “А Вы разбираетесь в юзабилити?”. Некоторое время спустя, от него же, я увидела правки дизайна, со ссылкой на какую-то книгу (не помню источник), в которой описывались стили для отображения “нестандартных кнопок”. Это повлекло с моей стороны вопрос, а что же такое стандартные кнопки. Ответ был достаточно прост: “Браузерные”.

Диалог на этом был исчерпан и дизайн сайта вернулся к первоисточнику, т.е. творению рук дизайнера. Как менеджер, я соприкасаюсь со всеми звеньями в цикле производства продукта, от пожеланий заказчика до продажи рекламщиками. Наверное единственные, кто на сегодня не используют слово “юзабилити”, являются представители последних, т.е. менеджеры по рекламе. Хотя думаю и до них доберется, как только они осознают связь конверсий (их процентов) с тонкостями ux-сегмента.

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

Профильная литература по проектированию интерфейсов начинается со сбора требований, и оканчивается на прототипировании либо дизайне. Это в случае вовлечения специалистов на ранней стадии. На других стадиях оно включает и тестирование уже готового продукта, с внесением изменений. Львиная доля работ отнесена к специалистам юзабилити, что в нашей стране часто является добавочной работой дизайнера. Не могу оспорить это, т.к. именно эти люди, понимая пожелания заказчика, видят продукт от набросков в голове до опубликованной в Интернет версии. А каково же место других членов команды в процессе?

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

Менеджер и его стратегические планы по освоению р/с заказчика.

Менеджеры – уникальная профессия, которую недопонимают (побоюсь сказать недолюбливают) большинство узкоспециализированных профессионалов. Понаобещают заказчику с три короба, а потом выдают команде порциями. И делайте, что хотите, нам за это платят! Общаясь с заказчиком, профессиональный менеджер предлагает концепцию на существующие деньги, узнаёт можно ли будет заработать чуть позже, и тут же предлагает концепцию развития проекта (потом мы можем добавить такие-то разделы, к регистрации пользователя добавить возможности соц сетей и т.д.). Этот же менеджер, приходит к юзабилити-специалисту, либо дизайнеру и выдает ту информацию, которая касается базовой (оплаченной) работы. Проект идет в разработку, публикуется, начинает приносить деньги. Можно приступить и к реализации концепции развития. Менеджер радостно об этом сообщает, а на него смотрят и спрашивают “куда и как теперь необходимо разместить все дополнительные элементы, без внесений серьезных изменений в текущий интерфейс?”. На этот вопрос есть множество вариантов ответа, но суть остается та же, это куда-то “присовывается”. Развивать не стоит, вывод прост: вовлекайте юзабилити специалиста на этапе обсуждения концепции продукта.

SEO-специалист и его стратегические планы по завоеванию топ-10.

Если говорить об Интернет-бизнесе, то успех проекта – это заработанные деньги, достаточно тесно связанные с трафиком. А в данном случае с поисковым трафиком. Я могу искренне подержать тяжелый вздох сеошника, получившего готовый Интернет-магазин, в котором все рубрики и товары открываются аяксом через основной каталог на одной странице. Особенно, при требовании менеджера получить трафик из внутренних разделов. Конечно, при небольшом количестве товаров, для потенциального посетителя это удобно, но как для seo-специалиста, в этом есть затруднения. И, получив проект уже в готовом виде мы, или теряем трафик, или ломаем работу проектировщика, внося изменения. А вот привлекая данного специалиста на старте проекта, мы получаем возможность внести seo-требования до этапа проектирования продукта.

Веб-техногол и его стратегические планы по освоению новых технологий.

Отнесу эту профессию к творческим видам деятельности с глубокой стратегической логикой. Находясь между дизайнером и разработчиком в цикле производства, они видят продукт изнутри до и после своей работы. И вот, получив макет от дизайнера (после проектирования), они начинают задавать вопросы, зачастую связанные с логикой работы продукта. И очень часто оказывается, что хорошо продуманное до этого, может содержать не 10 “шт” в отображении, а 100 “шт” через пол года работы проекта. Что красивое и удобное пролистывание контента основного раздела на главной странице, положит БД и так далее по кругу. Чья ошибка на этапе проектирования? Это неважно. Проектировщик не додумал, менеджер недосказал, заказчик не предположил. Виновных в данном случае не бывает. Есть общая ошибка проекта. Что в этом случае? Думаю оптимальным является дружное сотрудничество проектировщика (дизайнера) с кодером на этапе проектирования. Обсуждение используемых в прототипе технологий с тем, кто будет это в результате реализовывать.

Разработчик и его стратегические планы по чистоте кода.

Разработчик последним получает продукт в работу. Упускаю роль контент-менеджера, отнесу этот этап к адекватной работе менеджера проекта. Разработчик получает проект, когда у всех уже “замылен глаз” и все наизусть знают все, что было создано до этого этапа. И тут возникают новые вопросы, которых достаточно много, но зачастую они начинаются со слов: “А что, если…?”. Лично я очень люблю вопросы программистов. Они часто недовольны тем, что приходит им на руки. Их логика отличается от логики менеджеров и дизайнеров. Но именно они задают вопросы, которые зачастую не приходят в голову ни одному из звеньев процесса. Как быть с ними? Стоит прислушаться, либо проще сказать: “Ты кодь, мы уже все продумали”? Думаю это один из последних слабо-болезненных этапов по внесению корректировок в интерфейс. Ведь то, что ему предоставили, то он и запрограммирует. И если его вопрос может изменить интерфейс не сегодня, так через нескоторое время, стоит обратить внимание и дослушать все его нарекания на полученные исходники.

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

Share Button