Я занимаюсь прототипированием с тех самых пор, как в России стало известно об Axure. С 2008 года. А проектированием гораздо дольше. Хотя называть ту работу проектированием можно с большой натяжкой. Скорее, написание технических заданий, да дизайн для простейших сайтов, по функционалу уступающих даже современным промо.

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

Речь пойдёт о начинающих проектировщиках, которые делают интерактивные (и не очень) прототипы, и дизайнерах.
Рассмотрим классический сценарий. Исполнитель получает заказ, оценивает сроки своей работы и садится за неё в последний возможный момент. У кого-то этот момент находится в начале календарного плана, у кого-то — в ночь перед сдачей проекта, всё зависит от степени самоорганизации и ответственности.

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

Многие пользователи программы Axure поначалу сталкивались с такой проблемой, как оформление псевдоссылок. Дело в том, что по умолчанию софтина не позволяет делать ссылки (или текст, что, в принципе, — одно и то же) подчёркнутыми пунктиром. Поэтому у начинающих творцов прототипов (прототипистов?) периодически можно увидеть псевдоссылки со сплошным подчёркиванием, что вносит в документ путаницу. На самом деле решить эту задачу очень просто.

Поискав на Хабре материалы на тему проектирования и составления технических заданий, я обнаружил, что их очень немного, и те, которые есть, довольно поверхностны и содержат лишь ключевые рекомендации по производственному процессу…
Нет, слишком сложно начал. Люди, где примеры технических заданий? Где клёвые детальные прототипы? Где примеры решений задач с разработкой сложных сайтов, с различными ролями пользователей, с интерактивными приложениями? Где кейсы?

При создании нового сайта особое внимание следует уделять сбору материалов перед этапом проектирования. Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами? Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?

— А вы что, не можете спроектировать сайт без этих материалов? Я же вам сказал, что я хочу на нём видеть, и какие задачи он должен выполнять, — это произносится с неподдельным удивлением на лице. А ещё с лёгким амбре неуверенности в компетенции исполнителя.
— Конечно, можем, — отвечает проектировщик, пожав плечами.

С этого момента время на создание сайта увеличивается в два, два с половиной раза.

 

Хороший проектировщик – на вес золота. Остальные участники производственного процесса создают тело сайта. Проектировщик – его душу. Так каким же должен быть проектировщик, гордо называющий себя профессионалом?

Должен быть немножко продажником. Не краснеть и не запинаться во время общения с заказчиком. Уметь слушать, беспристрастно анализировать услышанное и тут же задавать нужные вопросы. Проектировщик, сгорбившийся за компьютером и не показывающий носа из офиса, не сможет презентовать свою работу.

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

 

 

Ура, товарищи! Почта Яндекса сильно изменилась. Многие вещи стали действительно крутыми и полезными, но в глаза сразу попало именно то, чего я никак не ожидал от Яндекса.