1. Накопление исходной информации. В простом виде – к примеру, интервьюирование заказчика, скажем, веб-сайта (сервиса, программы) на предмет того, что он хочет получить. “Он сам не знает, чего он хочет!” — как часто измученный дизайнеры, после десятого-пятидесятого отвергнутого эскиза проекта произносят эту фразу? Сейчас формально не важно (просто одинаково), кто является заказчиком проекта для дизайнера, будущий владелец проекта или командный project manager, т.е. *кого пытать*, для того, чтобы собрать необходимый объём информации для анализа.

Большинство дизайнеров убеждены, что именно заказчик должен выдать ему объем, забывая о том, что заказчик зачастую не знает, что для работы дизайнера имеет значение, а что – нет, и не может оценить, правильно ли понял дизайнер задачу. Начинается волокита с отбракованными эскизами, обидами “а что же вы раньше нам это не сказали?..” и прочими претензиями. А на что обижаться-то? Надо было догадаться спросить. Надо было правильно ставить вопросы. Напрямую заказчика или PM`а – не принципиально важно здесь.

2. Обработка полученной информации. Вся информация в подавляющем большинстве случаев приходит дизайнеру в не структурированном виде, потоком данных. В процессе обработки часто оказывается, что отдельные куски информации – противоречивы и требуется возвращаться к п.1 и разбираться, дизайнер ли в процессе организации данных не правильно понял, к примеру, типы данных или заказчик недо-пере-мудрил с требованиями. Этап генерации идей и выбор моделей реализации. Идеи в некоторых случаях так же требуют пересогласования с заказчиком.

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

3. Реализация обработанной информации. Есть структурированные данные, чётко обозначена цель, назрела идея как реализовать — вот теперь понадобятся инструменты для реализации, те же, к примеру, графические редакторы. Практика показывает, что если не допущено ошибок во время первого и второго этапа, то для исполнения третьего понадобится только хорошее знание среды разработки, и умение “красиво отрисовать”.

Думать нужно всегда, даже если ты всего лишь рисующий дизайнер в команде, где информацию за тебя выспросят и структуру сформируют. Доходит до абсурда: человеку отдали прототип навигационной менюшки в формате двухуровневого списка из пяти главных элементов списка + в трёх из них – по нескольку подэлементов. Нарисовал “меню” из двадцати визуально одинаковых элементов меню. Спрашиваю – “Как же так?.. неужели неясно, что это плохое решение?” — “А я не знал… а я не понял…” — “Если не понял, почему не спросил, не уточнил, не подошёл?”. Я могу понять, что человек не мыслит иерархическими структурами. Но не до такой же степени. Думать-то всё равно надо, даже если ты соглашаешься с тем, что остаёшься только отрисовщиком.

Я, кстати говоря, вовсе не утверждаю, что все три этапа должен в конечном счёте сам выполнять один человечек. Да пусть их хоть 10 будет, менеджеры, те, кто пытают заказчиков, информационные архитекторые, которые структурируют и анализируют данные и формируют экраны-прототипы, иллюстраторы, которые занимаются отрисовкой по прототипам, красоту наводят. Ошибка как раз начинается тогда, когда человечек, который не может взяться ни за один этап кроме отрисовки, пытается называть себя дизайнером и громко (иногда публично, на весь, прямо скажем, интернет) матерится на того самого заказчика, который не доволен его работой, “сам не знает чего хочет”. При этом человечек продолжает настаивать на том, что он самодостаточный дизайнер, просто все заказчики – козлы и лохи. Козлы – которые не принимают его работу и отказываются платить, лохи соответственно те, кто принимает его откровенно непродуманно исполненную работу и платит за неё.