Дизайнерское: три этапа разработки
Дизайнер – это такой аналитик с развитым воображением. Дизайнер всасывает, накапливает информацию, обрабатывает её и выплёвывает пережёванное в заданной форме (отдаёт продукт дизайна) — три базовых этапа. И если к какому-то из трёх этапов он по любым причинам не готов, не умеет, не любит, не способен, хорошего результата мы не дождёмся.
1. Накопление исходной информации. В простом виде – к примеру, интервьюирование заказчика, скажем, веб-сайта (сервиса, программы) на предмет того, что он хочет получить. “Он сам не знает, чего он хочет!” — как часто измученный дизайнеры, после десятого-пятидесятого отвергнутого эскиза проекта произносят эту фразу? Сейчас формально не важно (просто одинаково), кто является заказчиком проекта для дизайнера, будущий владелец проекта или командный project manager, т.е. *кого пытать*, для того, чтобы собрать необходимый объём информации для анализа.
Большинство дизайнеров убеждены, что именно заказчик должен выдать ему объем, забывая о том, что заказчик зачастую не знает, что для работы дизайнера имеет значение, а что – нет, и не может оценить, правильно ли понял дизайнер задачу. Начинается волокита с отбракованными эскизами, обидами “а что же вы раньше нам это не сказали?..” и прочими претензиями. А на что обижаться-то? Надо было догадаться спросить. Надо было правильно ставить вопросы. Напрямую заказчика или PM`а – не принципиально важно здесь.
2. Обработка полученной информации. Вся информация в подавляющем большинстве случаев приходит дизайнеру в не структурированном виде, потоком данных. В процессе обработки часто оказывается, что отдельные куски информации – противоречивы и требуется возвращаться к п.1 и разбираться, дизайнер ли в процессе организации данных не правильно понял, к примеру, типы данных или заказчик недо-пере-мудрил с требованиями. Этап генерации идей и выбор моделей реализации. Идеи в некоторых случаях так же требуют пересогласования с заказчиком.
К примеру, отдаётся дизайнеру экран, в котором из базы выводится поток данных. Данные в формате “имя”/”дата”/”время”. Нужно решить – выводить этот поток данных в виде списка с разделителями или в виде таблицы с заголовками полей. Узнать, будут ли элементы списка (или строки таблицы) функциональными, должны ли как-то маркироваться, выделяться, сортироваться. Заказчик: “а я не знаю, как надо, вы специалисты, вам виднее“. Программер: “а мне вообще всё равно, скажет специалист по интерфейсам выводит в таблице – выведу в таблице“. И все смотрят на специалиста по интерфейсам, на дизайнера, и ждут от него решения.
3. Реализация обработанной информации. Есть структурированные данные, чётко обозначена цель, назрела идея как реализовать — вот теперь понадобятся инструменты для реализации, те же, к примеру, графические редакторы. Практика показывает, что если не допущено ошибок во время первого и второго этапа, то для исполнения третьего понадобится только хорошее знание среды разработки, и умение “красиво отрисовать”.
Думать нужно всегда, даже если ты всего лишь рисующий дизайнер в команде, где информацию за тебя выспросят и структуру сформируют. Доходит до абсурда: человеку отдали прототип навигационной менюшки в формате двухуровневого списка из пяти главных элементов списка + в трёх из них – по нескольку подэлементов. Нарисовал “меню” из двадцати визуально одинаковых элементов меню. Спрашиваю – “Как же так?.. неужели неясно, что это плохое решение?” — “А я не знал… а я не понял…” — “Если не понял, почему не спросил, не уточнил, не подошёл?”. Я могу понять, что человек не мыслит иерархическими структурами. Но не до такой же степени. Думать-то всё равно надо, даже если ты соглашаешься с тем, что остаёшься только отрисовщиком.
Я, кстати говоря, вовсе не утверждаю, что все три этапа должен в конечном счёте сам выполнять один человечек. Да пусть их хоть 10 будет, менеджеры, те, кто пытают заказчиков, информационные архитекторые, которые структурируют и анализируют данные и формируют экраны-прототипы, иллюстраторы, которые занимаются отрисовкой по прототипам, красоту наводят. Ошибка как раз начинается тогда, когда человечек, который не может взяться ни за один этап кроме отрисовки, пытается называть себя дизайнером и громко (иногда публично, на весь, прямо скажем, интернет) матерится на того самого заказчика, который не доволен его работой, “сам не знает чего хочет”. При этом человечек продолжает настаивать на том, что он самодостаточный дизайнер, просто все заказчики – козлы и лохи. Козлы – которые не принимают его работу и отказываются платить, лохи соответственно те, кто принимает его откровенно непродуманно исполненную работу и платит за неё.
Вот этому искусству мне еще учиться и учиться
Уже давно подумываю о составлении универсального и сильно упрощенного шаблона ТЗ, чтобы даже совершенно далекий от веба заказчик смог доходчиво объяснить что он хочет получить на выходе. А не что-то вроде: “Сделайте мне круто и дорого, вы же дизайнер!”
Искусству общения с заказчиком учиться можно бесконечно, универсальный шаблон-опросник можно создать только для маленькой ниши статических презентационных проектов.
Я как раз поднимаю вопрос чуть шире: почему дизайнер начинает работу в состоянии, не понимая что он делает и что нужно сделать? Зачем остаётся в отрасли вообще, если не умеет неупорядоченную информацию от заказчика переваривать в конечный продукт? Очень расстраиваюсь, когда вижу, что дизайнер не умеет, а, главное, не хочет думать.
а я вообще без ТЗ или четкой постановки задачи не начинаю работу. Я хоть и художник, но логика и практичность у меня на первом месте. На мой взгляд если менеджер (или дизайнер) не составил ТЗ для проекта вместе с заказчиком, то ничего путного уже не жди. Такие проекты тянутся годами, а вина за это валится друг на друга.
Света, скажите, если вы в ТЗ вычитываете какие-то двусмысленные или не понятные вам формулировки, вы будете молчать и рисовать “как поняли”, а потом за неутверждённый эскиз обижаться на PM`а или заказчика? Или всё-таки спросите, потребуете уточнений и однозначных формулировок?
Наш красавец выбирает первый путь. Причём лажает в таких деталях, которые – реально – всем, и заказчикам, и PM`мам представлялись очевидными, если включить даже не особые технические познания, а просто здравый смысл. И заказчик, и PM не всегда могут предсказать, что и где недопонял дизайнер/иллюстратор. Поэтому полюбому нужен диалог, а не формальное ТЗ.
Сколько будет заказчиков, столько будет и шишек набито, хоть тресни – а дизайн – вещь субьективная
[...] « Дизайнерское: три этапа разработки May [...]
часто приходится “допрашивать” заказчика на предмет того, чтоже он хочет, так как обычно стучат в аську и сразу сходу: “Нужен дизайн! Когда будет?”, от чего сразу мысль в голове: “Все понятно, закачик ждет чего-то, сам не знает чего”, но с другой стороны такие в плане дизайна не привиредливы, и их обычно все устраивает с первого раза:) хоть и не всегда
[...] С большим интересом всегда читаю серьезные статьи в блоге у Татьяны Вукс. Руководить целой командой разработчиков – это не просто другой уровень, не имеющий ничего общего с фрилансом (читай – любительством), но еще очень и очень сложно. Очень рекомендую к прочтению всем пост о трех этапах разработки проекта. [...]