Общаясь в GTalk с Ренатом, дизайнером из Казахстана, получился интересный диалог с ответами на вопросы по веб-дизайну и управлению проектами.
Ренат: Вот недавно клиент появился с ТЗ, брифом, с пожеланиями. Говорит сделайте мне карту Казахстана на флеше. Явно видно, что карту можно сделать без флеша на простом ХТМЛ. Когда можно использовать флеш, а когда нет? Где грань?
lessio: Мы в Имперави флеш не используем. Вот и грань. Никакого флеша, это мертвая технология. Часто легко аргументировать тем, что на айфоне и айпаде нет флеша, а у клиентов как правило какое-то из этих устройств есть. Но некоторые клиенты все равно заказывают на стороне флеш баннеры, что не радует, потому как идет только во вред сайту. Недавно мы сделали интернет-магазин и клиент поставил промо-флеш баннеры, из-за которых визуальное добавление товара в корзину происходит с задержкой. Это очень плохо и клиент получается враг себе. Мы не можем с этим ничего поделать.
А еще есть типичная ситуация, когда клиенты называют флешом любую анимацию и после обсуждения, оказывается, что речь не о флеш-технологии. Получается, что клиенту не нужен флеш как таковой, им нужно решение определенной задачи, с применением какой технологии это будет сделано не важно. Поэтому html5 + css3 + javascript решают подобные задачи в полной мере.
Дизайнер в итоге должен стать арт-директором, иначе он хреновый дизайнер. Это так?
Я считаю работа дизайнера должна измеряться его зарплатой и известностью его работ (в меньшей степени), а кто он по должности не имеет значения.
У дизайнера два показателя успеха:
- Сколько он зарабатывает.
- Сколько людей и насколько успешно пользуются его работой, с помощью которой они решают свои задачи.
Второй пункт весьма абстрактный, вот поэтому денежная оценка наиболее показательна. Опыт + знания + навыки + идеи + трудолюбие + терпение + обучаемость + развитый здравый смысл = дизайн + деньги.
Как ни крути все дизайнеры поневоле выполняют менеджерскую работу (переписки, звонки, совещания) помимо своих работ. Так и должно быть или это лишняя работа?
Так не должно быть. Очень плохо когда дизайнер выполняет менеджерскую работу, это всегда приводит к снижению продуктивности, к снижению качества и еще к массе проблем.
И причины очень просты: дизайнер неспособен объективно оценить свою работу по времени и по стоимости. Это относится не только к дизайнерам, любой человек очень субъективно оценивает самого себя и как следствие свою работу. Вот например, программисты всегда супероптимисты. Я никогда не встречал такого программиста, который смог бы оценить свою работу точно в срок или с запасом. Оценка всегда более чем оптимистичная.
Менеджер проекта более объективен, так как он видит картину со стороны и несет прямую ответственность за результат. Поэтому он может оценивать, во-первых, саму работу дизайнера более объективно, во-вторых, может оценивать сроки и стоимость более точно. Все это позволяет более продуктивно вести диалог с клиентом, меньше ошибаться в оценках и делать работу качественнее, а не выдавая свои амбиции и самолюбие за якобы качество и идейность.
Дизайнер вполне может принимать участие в совещаниях и обсуждениях, но лишь как наблюдатель, чтобы быть в курсе или чтобы менеджер мог ему задать какой-то тонкий вопрос по дизайну.
Работа менеджера проектов — слишком обширная деятельность чтобы ее совмещает с еще какой-то. Управление проектами — это целая жизнь.
Клиенты часто просят связать с исполнителем без посредничества менеджера, чтобы времени не терять. Менеджера может не оказаться на месте, даже на «добрый день, сейчас я свяжу с дизайнером» время уйдет.
С клиентом должен общаться менеджер проекта и никто больше, связывание с исполнителями это мелко и не дальновидно.
Со стороны менеджера — это попытка спихнуть ответственность на кого-то еще и неумение решать проблемы.
Со стороны клиента — это неосознанная попытка загубить проект, вмешиваясь в ход работы и в то, что его не касается.
А вообще дизайнер должен же быть в курсе программирования сайта. В каких пределах необходимо знать техническую часть создания сайта?
На уровне того как это работает должен знать безусловно, мы вообще работаем только с дизайнерами, которые умеют проектировать и понимают как сайт работает изнутри, в том числе на уровне верстки.
Времена «сайтов картинок» давно прошли. Дизайнер, который не знает html + css + jquery — ничего не стоит. Изучить эти две технологии и библиотеку jquery не так уж сложно. Результат будет поразительный. Дизайнер, который понимает, как сайт работает, как его будут верстать и дизайнер, который не понимает — это два разных человека. Первый — профессиональный веб-дизайнер, второй — отсталый неумеха.
Программирование знать не обязательно и возможно даже вредно. А вот понимать принципы шаблонизации и того как устроена CMS, на которой будет работать сайт — необходимо. Это помогает избегать массу неожиданностей и проблем, когда программисты сталкиваются с невозможностью реализации задумок дизайнера или на эти идеи требует столько времени, что проект начинает приближаться к катастрофе.
Обратная ситуация тоже верна: программист должен понимать основы веб-дизайна, стиля, типографики и т.п.
Что спрашивать у заказчика, какую информацию? Нужен ли бриф вообще?
Это вопрос, на который нельзя ответить. Как строить процесс работы и какую документацию писать, каждый выбирает сам, после изучения того какая вообще документация бывает и как строят процесс в разных компаниях, а также на основе своего опыта.
Все дело в том, что условия всегда разные. В каждой компании разные менеджеры, разные исполнители, разные принципы работы, разные типы сайтов и т.д. Нет универсального набора документации. Состав документации, вопросы клиентам — все это выкристаллизовывается с опытом. Поэтому все что нужно это:
- Прочитать все возможные книги по управлению проектами.
- Провести массу интервью с клиентами.
- Создать несколько проектов от начала и до конца в команде, проделав после каждого проекта разбор полетов.
Если мы сейчас возьмем и составим список «идеальной документации с идеальными примерами» — это никому не поможет. Пока не набил шишек и не проверил на практике — все это будет водой. Кстати, это причина почему я никогда в своих статья не привожу примеров и шаблонов документации. Это не имеет смысла. Это никому не поможет. То кто думает, что поможет — заблуждается.
Кто должен составлять техническое задание? Все участники проекта?
Техническое задание должен составлять менеджер проекта и по ходу задавать вопросы клиенту, дизайнеру, программисту и всем остальным, если дело касается каких-то тонкостей или сложных моментов. Например, менеджер не всегда сам может оценить сложность программирования какого-то модуля, только программист сможет помочь в оценке этой работы.
Я думаю так: для разработки сайта с заказчика хватает только информации о компании и общие пожелания на чем делать акценты. А конкретные вопросы типа «какой цвет вам нравиться, стиль оформления, наличие флеша и т.д.» это знает только студия, не клиент. Студия лучше знает, как и что получится. Не перестаю так думать.
Все верно. Я на 100% за такой подход. Но определенная вовлеченность клиента в работу желательна и часто даже обязательна. Необходимо всегда обсуждать с клиентом техническое задание, сложные моменты, сомнения по проекту, по результатам, по целям и т.д. Конечно, удерживая клиента на определенном расстоянии. Вот как раз менеджер проекта еще и некий буфер между разумными обсуждениями и микроменеджментом клиента. Причем говоря про «сдерживания клиента», я ни в коей мере не имею в виду ничего плохого. Клиент, который хочет влиять на ситуацию не глуп. Во-первых, это происходит часто неосознанно из-за реального беспокойства о результате проекта и о его качестве. Во-вторых, возможно излишняя вовлеченность — это звоночек, что процесс работы идет не так как надо и возможно скоро проект упрется в тупиковую ситуацию.
Как вообще веб-дизайнеру прокачиваться? Читать книжки — это теория. А на работе проекты могут быть не «вкусными».
Самому выдумывать проекты и делать их для себя ради тренировки, пожалуй это единственный путь.
Я с этого начинал. У меня было портфолио полностью из выдуманных проектов. И это работает. Причем не стоит останавливаться достигнув какого-то уровня и потока заказов. Можно показывать концепты, идеи, потому что в таких вещах часто проявляются настоящие умения, ничем не ограниченные. Это оценят.
Если сделал, кому показывать? Нет клиентов, арт-директора, экстремальных ситуации. Или тоже выдумать?
Это не важно, главное просто практика и стремление к совершенству, все остальное в реальных ситуациях само собой получится, если рука набита на таких работах «для себя».
А еще, считаю важно вести блог, потому что когда сам пишешь, то поневоле начинаешь размышлять, прикидывать с разных точек зрения и так тоже совершенствуешься и учишься, особенно учишься сам себя критиковать.
Говорят дизайнеру не обязательно уметь рисовать. Но мне это очень помогает для быстрой визуализации задумки, особенно при рисовании иконок. Это преимущество или только заменяемый инструмент?
Я бы не обобщал всех дизайнеров. Для того кто рисует иконки, иллюстрации — безусловно преимущество и необходимый навык. Для дизайнера сайтов достаточно знать основы: композиции, теории цвета и т.п. Потому что веб-дизайн, на мой взгляд, ничего общего с искусством не имеет. Веб-дизайн это прежде всего логика, удобство использования и то как работает сайт, а не художество. Так что веб-дизайнеру лучше иметь какое-то техническое образование.
Веб-дизайнер больше архитектор. Веб-дизайнеру полезно рисовать от руки эскизы на бумаге, но для этого в художественную школу ходить не обязательно.
У нас есть проектировщик. Очень хочет стать дизайнером, так мы ее называем именно архитектором.
Считаю что дизайнер=проектировщик и проектировщик=дизайнер. При работе над сайтами визуальная архитектура, т.е. проектирование не должно отделяться от оформления. И таким образом все это должен делать один человек начиная с прототипов и заканчивая дизайн-макетами. Это очень эффективно и продуктивно. Иначе когда прототипы делает проектировщик, а макеты дизайнер, то срок проекта увеличивается раза в два.
Когда дизайнер занимается только оформлением, то его роль какая-то слабая слишком, ведь по сути ему остается только раскрашивать блоки.
Нет, бывает замечаешь что тут можно сделать лучше, убрать, добавить и говоришь проектировщику, мол, чтоб исправил ТЗ по новым требованиям.
А когда проектирует и оформляет сайт дизайнер такой проблемы нет. Цельность и скорость работы повышается в разы.
ТЗ ловушка.
В точку. Мы идем к тому чтобы оно было минимальным и описывало только то, что реально необходимо в работе. Потому что стали замечать: пишем ТЗ, но потом ни мы, ни заказчик по ходу работы в него не смотрит.
Я и не смотрю. Я читаю бриф и общаюсь с менеджером. А он говорит мне на что особенно обращать внимание.
А что в брифе содержится?
Кто заказчик такой, чем занимается, чем особенны, чего ждете, какие цели от проекта
Если возвращаться к «идеальной документации», то без сомнения в ней должно быть:
- Цели проекта
- Структура проекта (абсолютно все страницы сайта с адресацией)
- Функциональные требования (в самом лаконичном и простом виде)
И поясню про функциональные требования. Это небольшие заметки по важным функциям или разделам проекта, в которых кратко, емко объясняется как должно работать или рассказывается про тонкие моменты. Например:
Раздел Поиск
На сайте можно искать товар по названию или по артикулу.
Все. Никакой воды, никакой канцелярщины. Отметили тонкий момент и теперь о нем не забудем. И так по каждой важной функции, человеческим языком.