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

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

Все правила легко применимы к исходникам с поддержкой артбордов и не требуют особых усилий к запоминанию, потому что являются логичными.

Не смотря на то, что описанные подходы уже используются и проверены временем, заметка будет обновляться по мере нахождения более эффективных приемов работы.

1. В проекте нужен «Мастер»

Задача Мастера в том, чтобы заниматься слиянием исходников (синхронизацией). Хотелось назвать его библиотекарем, но в продуктовых командах — библиотекарь это отдельный исполнитель, занимающийся исключительно библиотекой и гайдлайнами.

Слиянием может заниматься каждый участник команды, но Мастер нужен именно для того чтобы избежать путаницы, сократить трату времени на вникание в работу и обрести дзен.

2. Версии файлов заменяем датами

Новый день работы начинается с дубликата папки с самыми актуальными исходниками. Таким образом вы сможете откатиться обратно или восстановить хронологию действий, если этого потребует проект в любой удобный для вас момент.

В названиях папок присутствует название проекта, для того чтобы можно было копировать папку куда угодно без дополнительных корректировок и настроек к экспорту. Это исключает путаницу с другими подобными папками.

Формат имени папки строится на привычном дедуктивном методе:
«Project-name-yyyy-mm-dd». Где имя может содержать дополнительную информацию, например «АЕ Анимация иконок меню». Это нужно для более быстрого поиска работ.

Комментарии стоят не везде, а во благо приоритетности и быстрого поиска.

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

Изредка, случается, что необходимо иметь две разных версии в один день. Тогда рекомендуется дописывать версии и пояснять их при необходимости:
Project-name-yyy-mm-dd ver-1
Project-name-yyy-mm-dd ver-2

Поскольку мы полностью в курсе только тех изменений, которые произвели сами, необходимо следовать следующему правилу

3. Чужие исходники не трогать

Совместная работа над проектами подразумевает наличие исходников-дубликатов. Если вам необходимо взять исходник другого участника команды — берите его дубликат, а оригинал не трогайте.
Для удобства работы рекомендуется исходники делить именами, например:
Project-name-yyy-mm-dd User 1
Project-name-yyy-mm-dd User 2

Открывая оригинал — вы рискуете по неосторожности испортить чужой исходник не заметив этого. Зачем потом тратить время на поиски и исправления подобных курьезов?

Если один из дизайнеров привлекается к проекту периодично, то для удобства поиска его исходников рекомендуется хранить все его исходники в отдельной ветке.
Тогда папка проекта содержит в себе сначала каталог участников, а затем личный архив исходников по датам.

В этом скриншоте видно, что в проекте уже теперь две папки — появилась Sedisheva

4. Архив без мусора

В актуальной папке дня рекомендуется держать только те файлы, которые претерпели изменения. Это позволит при необходимости быстро совершить откат, а не перебирать кучу дубликатов в поисках прошлой версии.

Дубликаты, которые нужны только для открытия и копирования отдельных данных лучше переименовывать для отличия.

5. Читаемость исходника

То, насколько легко вы или любой другой участник команды сможет сориентироваться в исходнике зависит от ряда важных моментов:

1. Как выставлены имена артбордов и групп
   
2. Есть ли порядок в рабочей области
   
3. Как построена работа с листами
   
4. Где хранятся утвержденные и не утвержденные макеты.

Про имена

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

Для отображения разных состояний одних и тех же экранов в нумерации дописывается алфавит.
01. Название экрана — Деятельность на нем
01а. Состояние А
01б. Состояние Б
02. Название экрана — Деятельность на нем

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

1-01. Флоу 1
2-01. Флоу 2
3-01. Флоу 3

Порядок в рабочей области

Хорошим тоном считается нормальная сетка из артбордов. Помимо того, что она радует глаз, так же легко «читается», а главное создает четкую структуру в хаосе драфта из кучи версий.

Когда создание отдельных страниц становится нецелесообразным, а разделение групп крайне необходимо, приходится поступать вот так.

Для отображения нескольких флоу на одном листе я пользуюсь визуальным разделением.

Работа с листами

Разделение проекта на страницы — значительно упрощает работу. Например, использование отдельной страницы для GUI поможет сократить временные издержки на перемещение от экрана с которым работаете до GUI с которого необходимо взять нужный объект.

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

Утвержденные и не очень макеты

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

Я стараюсь располагать весь драфт на отдельной странице и копировать оттуда последние версии макетов в проектные страницы. Чтение версий драфта чаще всего происходит слева направо, сверху вниз, а для групп экранов просто сверху вниз, т.е самые свежие макеты расположены всегда правее и ниже всех остальных.

Ценообразование связано напрямую затратами  времени × сил , где ценностью является результат работы, предоставляемый клиенту пользу, силу или статус.

Парадокс состоит в том, что клиент, ища дешевого сотрудника для выполнения разовых или периодических работ — рискует платить больше, чем работа того стоит. И платит. Платит деньгами, силами и лишним временем, сам того не замечая. Когда замечает, расстается и ищет другого исполнителя.

Связано это с недостаточным уровнем знаний исполнителя. Дешевый исполнитель не профи и большую часть работ делает не автономно, а руками. Либо вовсе использует не эффективный инструмент, который сковывает возможностями.

И говорит о том, насколько сложна задача. Убедительно говорит, потому что сам в это свято верит. Так у проекта растут сроки, из-за них поднимается себе стоимость и проект раздувается до неприличия.

Наглядный личный пример:

Задача: Избавиться от 10 шрифтов включая начертания в проекте, заменив их на 2-3 аналогичных бесплатных.

Проверь себя дзгнер: сколько тебе понадобилось бы времени, чтобы заменить все шрифты в этом проекте? (ответ ниже)

Верный ответ: 5 мин.

Как так получилось? Да легко!
Illustrator: Type → Find font…
Sketch: Style text

Примеров, в которых нужны не только профильные знания, но и эффективность даже придумывать не нужно: «Обнови старую шапку и подвал на всех страницах на утвержденные новые», «Обнови меню на всех страницах магазина», «Обнови везде картинку / кнопку / стиль ссылки» и проч. В случае, когда цена базируется на строгом контроле времени подобная эффективность становится архиважной. Для исполнителя — потому что он может реализовать свой потенциал в бо́льшем числе проектов. Для заказчика — получает продукт в горячие сроки.

В итоге «дорогой» профессионал сэкономил бы время и деньги клиента, помимо того, что в целом по умолчанию помогает зарабатывать. Важно что специалист может просто выполнять творческую деятельность, не преследуя целей повышения конверсии, удобства работы с информацией или скорость поиска. Эти «мелочи» дорого обходятся клиенту и его бизнесу.

Посчитаем на утрированном примере ценообразование на сроках:

| |Специалист                      |Профессионал |

|Час работы: |200 руб.        |800 руб. |

|Потрачено времени:              |min: 30 мин
max: 3 часа |5 минут |

|Итого к оплате: |от 100 руб. до 300 руб | 67 руб.  |

Ручной работой, я бы вряд-ли уложился в час. И это мы не учитываем самого факта эффективности результата труда, на сколько инвестиция в дизайн оказалась оправданной.

И как быть?

Клиент не худрук и насквозь не видит навыки исполнителя, лишь догадывается насколько успешен исполнитель, разглядывая портфолио как простые картинки. И результат работ тоже. Тогда вопрос, как выбрать хорошего исполнителя?

Задавайте больше вопросов. Пусть вам расскажут как будет проходить работа. Пусть вас распросят о всех деталях проекта. Составят тех. задание, проведут анализ, выставят оценочные показатели на которые можно будет сослаться для подтверждения успешной реализации проекта.

Если фрилансер/группа/студия не разузнали дотошно подробности, не провели анализ и другие подготовительные работы — то они занимаются творчеством в дизайне и продажами бестолковых шаблонов в верстке, а хуже того просто бизнесом, впаривая и зарабатывая на безграмотности клиента в своей нише.

Но это же дорого?
Нет, это прибыльно. Но только если люди, к которым вы обратитесь помогут поставить верные цели и составить бизнес-требования, которые будут осязаемы и измеримы. Инвестиция в бизнес не может быть дорогой. Она может быть или неверной или оправданной.

Дорого платить за результат, который не принесет пользы. Дорого, потому что можно было вовсе не тратиться.

Не все знают что можно вставить прототип на Биханс. Правда не всем это и нужно :)
Прототипы, показывают объемы детализации работы. Это очень удобно и наглядно. Лучше прототипов лишь видео презентация или анимация.
А еще лучше работающее приложение или проект.

Тем не менее, если остались лишь силы на вставку рабочего прототипа из InVision или Marvel, то во втором случае это реально сделать. Как сделать подобное из инвижион я не разобрался, но думаю что это тоже реально.

Инструкция
Заходим в прототип, находим кнопку Share и после клика копируем код из таба Embed

А затем уже вставляем полученный код в Behance

Профит :)

p.s.: Хочется заметить, что прототип, конечно же круто, но пожалуй, он должен не заменять, а дополнять проделанную презентацию в виде анимаций и видео. Сугубо для людей, желающих потыкать и поглядеть все досканально. Все таки люди любят посмотреть все глазами и по-быстрому, а не сидеть и разбираться что где можно сделать, а что просто картинка.

Залог продуктивной работы — правильная постановка задания, которое составляется самолично. Таким образом я показываю заказчику насколько верно понял задание и справлюсь ли.
 

Заблуждения

Важно понимать, что пренебречь составлением задания нельзя. Категорически. Это защита от клеветы и намеченная цель для достижения результата.
Если кажется что:

1. Это пустая трата времени и глупость.
2. Вы итак друг друга поняли и переписывать обсуждаемое нету необходимости.
3. Задача мала чтобы уделять этому так много внимания.
4. Клиент старый и проблем не возникнет.
   … то пора переосмыслить подход к работе.

В любом случае, так кажется до тех пор, пока недопонимание не всплывает наверх. Сами причины — нежелание делать рутинную и неинтересную работу. 
В тех отдельных случаях, где задача мала — я рецензирую в скайпе. Нету ничего зазорного написать 3-5 предложений для малого объема работ, потому что даже тут можно неверно понять (заказчика) или ужасно объяснить (исполнителю) и завалить работу на «победный» повтор.
 

Проблемы долой

Встречаются клиенты, нежелающие работать над заданием . Суждения базируются на экономии времени, а если вдуматься то выходит в точности наоборот: вначале мы тратим время на то чтобы самостоятельно разобраться (это ~вдвое медленнее, чем рассчитывает клиент), затем после неверно проделанной работы мы тратим дополнительное время на разбор ошибки, постановки правильного задания и затем на повторную работу.
Клиент, категорически отказывающийся работать по схеме полноценного разбора задания — даже не рассматривается. Кому нужен такой супер герой «человек-мудак» тяжелый заказчик? 

Умный клиент разжевывает подробности, но чаще встречается дилетант, который не знает что нужно исполнителю и как правильнее это подать. Клиент и не обязан правильно ставить задачу, — потому вас и нашел — чтобы вы сделали классно. Вы же столько лет оттачивали мастерство по ведению проекта начиная с обсуждения задания. (Он даже и не знал что есть такой этап!)

Поэтому ответственность берите на себя. Это работа и мы знаем как провести проект к успеху по шагам. Для этого требуется больше концентрации, внимания и дотошности на данном этапе сотрудничества.

В случае если клиент уже сам написал задание, можно либо переписать, либо пройтись по каждому из подозреваемых моментов с детальными вопросами, для большей уверенности взаимного понимания.

Сокращаем риски

Один из простых и не менее действенных способов сократить риски при утверждении задания — техника «3+», описанная в книге «Сначала скажите нет». Джим Кэмп использует эту технику для проверки клиента при переговорах для уверенного «закрытия сделки».

Я использую эту технику чтобы убедиться, что верно понял чего хочет клиент, даже если «все просто» со слов последнего:  Когда вы подошли к утверждению отрывка написанной задачи, спросите клиента по крайней мере три раза об одном и том же. Вопрос допускается формулировать по разному, но суть остается одинаковой.

Не смотря на направленность на переговоры, книгу рекомендуется прочесть для ознакомления и использования техник переговоров повседневно и в быту.

Эту технику используют когда вы желаете убедиться, что «да», которое вы слышите — это действительно «да». Вы не пытаетесь трижды услышать «да». Наоборот: вы просите клиента сказать «нет» и, если он даже на приглашения сказать «нет» говорит «да», — это уже действительно положительный сдвиг и верное взаимопонимание.

Осталась мелочь, начать работать над проектом!