Какой становится логическая цепочка слогана? “Встал бы пораньше — успел бы на работу”, “Пил бы меньше — был бы здоровее” Сосал бы лучше, произошло бы что-то (какое-то действие, состояние). В данном случае – произошёл бы собссно ТРАХИСАН. Или наступил бы. Ребята, мы лекарство рекламируем или что? Чем вы там вообще занимаетесь?

Может я тороплюсь с критикой и обвинениями в безграмотности и это на самом деле такой крутой рекламный трюк; уж даже если я зависла и до сих пор не отпускает недоумение, если цепляет, значит, всё не так плохо?

Офисным дизайнерам в этом смысле веселее, чем фрилансерам, хотя и тех достать, при желании, можно. Самое простое – это задолбать странными сроками на работу и неоправданными дедлайнами. Когда несколько дней-недель-месяцев решаются какие-то глобальные вопросы на уровне менеджмента, утрясается ТЗ, что-то где-то планируется и вдруг дизайнеру наконец-то спускается задание с неожиданным требованием “сделать на вчера”, и тот, как на пожаре, начинает суетиться, пытаться в короткие сроки осознать то, что всё-таки соизволили ему предоставить в качестве задания, что-то срочно рисовать, и при этом проджект менеджеры, а так же главное руководство должны обязательно подходить к нему где-то с периодичностью раз в 15 минут, или позванивать на офисный телефон, и нервно вопрошать: “Ну что? Когда? Что ты возишься!!! Тут работы на 15 минут, подумаешь, пару иконок нарисовать?! Чем вы там всю неделю занимались?..” Хорошо при этом ещё стоять над душой, отслеживая, чтобы дизайнер не отвлёкся на чай, мессенджер или ещё куда-то, хорошо ещё при этом комментировать скорость его работы, используя ключевые фразы “не тупи!”, и “ну ты тормоз!”. “Быстрее, прыжками, все на забор!” Творческий импульс вспыхнул, как промокшая пиротехника, и с мерзким шипением зарылся обратно в землю.

Удачно совмещать такой прессинг с каким-нибудь другим, к примеру, сравнивая работу этого дизайнера с каким-то другим. “Вот Жан нарисовал такую заставку за 20 минут, и получилось у него гораздо лучше!” Тут нужно обязательно полагается почувствовать себя убогим дерьмом, которому никогда не достичь уровня профессионализма Жана и, видимо, преисполниться неимоверной благодарностью к такому руководству, которое, не взирая на то, что ты не Жан, терпит тебя, платит тебе зарплату и соизволяет присутствовать в проектах и дальше. Вообще сравнивать в процессе работы то, что получается у дизайнера с тем, что выдают, к примеру, дизайнеры студии Пирогова, 2advanced, или обиженно вспомнить о том, что “а вот Вася был крут, ему ничего не стоило забабахать здесь флешевую анимацию”, как-то забыв при этом, что вася был уволен именно за то, что был никудышний иллюстратор и эскизы у него были убогие, а флеш его и нужен был на полтора трудодня в год…

Ещё отлично получается, когда присылают дизайнеру в работу чью-то недоделку с заданием “доделать”, “довести до ума”. И если такое счастье приходит дизайнеру на фриланс, тот либо отказывается доделывать за кем-то вообще, либо же предлагает заказчику отказаться от полуфабриката и начать работу уже с ним над новой концепцией. В большинстве случаев ясно почему: разные люди, разные стили, мало удовольствия в том, чтобы пытаться попасть в стиль предыдущего дизайнера и при этом гарантированно не попортить, а потом, когда наступит момент расплаты (за работу), окажется, что основная-то работа уже была сделана тем самым предыдущим! Разработана концепция, продумана идея и отрисованы все основные элементы! Что тебе-то, всего немного доделать надо было же ж? А ведь у офисных дизайнеров такого выбора, как правило, нет. И придётся ему, болезному, дорисовывать страницы, которые по логике вообще никак не вписываются в базовую концепцию, а сделать нужно не просто чтобы вписалось, но и чтобы “не испортило основную идею!”, разумеется.

Хорошо ещё офисному дизайнеру работается “под угрозой увольнения”. Кризис, как вирус, повально подламывающий компании с разработчиками, или изменение стратегии фирмы, или просто такая политика работы с персоналом: пусть чувствуют, что здесь суетиться нужно для того, чтобы оставаться сотрудником фирмы! Так, на всякий случай, периодически напоминать про сложную ситуацию, про возможное расформирование подразделения или периодически заводить разговоры о неприбыльности дизайнерской команды, способов ненавязчиво напоминать дизайнеру о том, насколько иллюзорна любая стабильность в этом мире (что, признаю, не является неправдой но…) на самом деле не мало, просто делать это нужно регулярно, чтобы не расслаблялись.

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

Правда, что уже ожидаемо, повылазили траблы из старых проектов, трёх-шести месячной давности. И на таких примерах особенно заметно, какой бардак у меня в документации и в контроле переписки с нашими заатлантическими. Во французской версии одного из давно сданных проектов обнаружены неправильные названия разделов сервиса. А у меня чёткое ощущение того, что туда-сюда мы их меняли уже раза три или четыре. А в гневном письме – “Я уже 4 месяца назад говорил тебе, что нужно исправить ошибки “… По текстовой документации, таскам в джире и найденным в архиве письмам – версия верная, может, по телефону был какой-то разговор? Или затерялось какое-то письмо? Или было оно не четыре месяца назад, а неопределённый период времени назад и искать по полному архиву следует, что не возможно за разумное время? Не вспомнить.

Во время отпуска нужно будет спланировать переупорядочивание процесса работы. Задача не из простых, если учесть, что обязанности изрядно размыты, и управление командой (кстати по номенклатурным требованиям я официально называюсь не “арт директор”, а “руководитель подразделения дизайнеров”, о как! Бухгалтерия наша говорит, что не существует такой должности, арт директор, извиняюсь), и кроме того, что “управляю”, сама рисую интерфейсики-кнопочки-иконочки, и вёрстка — самые сложные или самые скорые проекты всё ещё на мне, из первого набора дизайнеров остался один паренёк-дизайнер, я его представляю ньюбам как “продвинутого верстальщика” , остальные ещё со статусом “новички”. Да, ещё этап “проектирования интерфейсов” по значительной части проектов здесь же.

С такой нагрузкой даже фраза “то пусто, то густо” звучит не так, чтобы очень корректно. Скорее “то менее густо, то густо на грани креша”, когда запущено три студии, одна из которых по объективным причинам 2005-я и две 2008-е (и не перепутай!), в фотошопе исходники-заготовки по трём-четырём проектам одновременно, вторичные приложения (вьюверы, документы, файловые менеджеры и разные мессенджеры) теснятся с неудобной для работы плотностью, а в браузерах (тоже трёх-четырёх) открыты сразу все проекты и соответствующие им пейджи, к примеру, с документацией на шарепоинте или со ссылками на связанные ресурсы. Крышесносительное распараллеливание работ, когда сам процесс распараллеливания с меньшим успехом происходит у тимов команд, для которых что-то рисуется, верстается или придумывается, когда ребята стоят чуть ли не в очереди за “сюда нужно пару кнопочек”, “а у нас здесь вёрстка поехала”, и вообще “через 15 минут телекаст с канадой”.

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

Нечёткие постановки – хроническая беда руководства и тимлидеров. Знаю, что не хорошо и непедагогично спорить с начальством (и уж тем более в присутствии моих уже подчинённых), но уж больно часто задалбывают нечёткими, двусмысленными или даже противоречивыми постановками задач. Как тут обойтись без повышенных тонов? “Ну тут же всё понятно! Что же вам не понятно?” – так сидишь, думаешь, может, это я такой даун. Оглядываешься на своих техдиректоров-тимлидов – им тоже не понятно. Начинаешь ковырять непонятную задачу в присутствии всех же, показываешь постановщику – вот, смотрите, если так, как вы говорите, то *тут* и *тут* не сходится. Если *вот это* родительские элементы, а *вот это* — дочерние элементы, то каким образом вы поворачиваете вашу матрицу на 90­° против часовой стрелки и как это ваши дочерние элементы стали главными, а некоторые из родительских – младшими? Ага, тут постановщик понимает, что сам чего-то недопонимает, и правда, не сходится.

Или так: “я же об этом вчера целый час всем вам рассказывал!” — уж сколько раз собирались завести маленький такой локальный диктофон и записывать голосовые совещания, мало ли, может, дома перед сном захочется переслушать… А на самом деле тоже обычная ситуация, никакая не чрезвычайная или исключительная, когда постановщик имеет представление некоего продукта (проекта), перед глазами он его держит, что ли. И вот он пытается описать это представление своими словами перед аудиторией. Вы в корову играли? Многие играли. Иногда даже простая задачка на “изобразить слово” не решаема – не читает аудитория то, что пытается изобразить герой игры. Так и у нас часто бывает. И ему, постановщику, уже давно кажется, что описание он сделал очень подробное и понятное, а все слушатели либо не видят (не понимают) его описания, либо видят настолько искажённым, что постановщик (о! презентатор идеи!) начинает раздражаться, а в последствии – искать виноватых (чем вы слушаете?!). А оказывается, нужен был именно ветеринар, способный писать, а не, хм., борзописец, готовый разобраться в теме. Хотя… во многих случаях как раз неоднозначные формулировки – это очень хитрый шаг процесса: когда заказчик или постановщик сам не понимает что нужно, а признаться в этом не хочет (не обязательно из-за комплекса неполноценности, может как раз из-за сложной стратегии работы с командой), и далее – либо команда уже без него попытается найти оптимальное решение, либо, если решение всё-таки получилось глючное, всегда ясно, кто виноват: я же говорил, что ветеринар, а вы опять всё не правильно поняли, и что мне предлагаете?

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

Когда цели проекта сформированы сколько-нибудь внятно, прикинуть первую версию такого “среднего” экрана довольно просто; и дизайн был нарисован, и принят заказчиком восторженно, и даже программеры, которые изрядно придирались к некоторым элементам дизайна, как к трудно реализуемым или малоадекватным, наконец-то сказали, что всё замечательно. Т.е. утверждён будущий стиль дизайна сервиса. Игрушки закончились, и теперь нужно бы приниматься за отрисовку уже реальных экранов. И тут у нас начинается ступор. Потому что этап проектирования сервиса в целом полностью на себя взяла канадская команда. Именно они там у себя в своих конференц-румах ежедневно с отделом маркетинга, руководством и прочими участниками процесса бурно, по нескольку часов ежедневно (по словам нашего канадского управляющего) обсуждают сценарии поведения пользователя при работе с сервисом, только… Ни одно из этих обсуждений не заканчивается присланными прототипами экранных форм. Что ж за беда-то такая?

Человечек специалист, который у них, там, должен был бы рисовать прототипы, группировать по сценариям и присылать сюда готовые шаблоны для рисующего дизайнера, то ли не справляется, то ли вообще не подходит для такой работы. Его первый вариант экранов, отрисованный в Visio, который мы получили больше недели назад, даже на тот период был недостоверный и не отвечающий никакой логике, не иллюстрирующий ни один из возможных сценариев. Так, набор каких-то страниц с формами, который мы покрутили-покрутили, и отложили, как пример показательно безграмотной работы. Тогда решили попробовать другой метод: устроили телефонную конференцию с включенным на компьютере одним общим монитором (через сервис logmein.com, давно используем его в работе и радуемся, что такое есть). Предварительно, до начала конференции, набросали наиболее вероятных 5-7 экранов; оказалось, что для того, чтобы диалог был конструктивным, канадским менеджерам действительно проще получить пусть и не оптимальныме (а никто и не говорил, что это последняя версия), но хоть какие-то экраны.

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

В процессе обсуждения, кстати, народ довольно часто повышал голос. Особенно конфликтные моменты возникали между программерами и кем-то другим: что делать, если на панели размещены два *горизонтальных бегунка* для изменения размеров просматриваемой области (zoom) и ограничителя времени (time) – они так красиво нарисованы рисующим дизайнером, так эффектно смотрятся, но как они будут меняться, когда изменится горизонтальный размер панели? Должны они тоже “ужиматься” и до какого минимума или должны “уезжать” за край рабочей области? Или имеет смысл сделать их вертикальными, но ведь тогда придётся передоговариться с “генеральным”, который уже официально сообщил, что эскиз того самого презентационного варианта интерфейса ему так понравился, что он ТРЕБУЕТ, что бы ничего не меняли ни по пожеланиям отдела маркетинга, ни по техническим требованиям программеров, а зум и таймер уж больно замечательно визуально вприсываются именно в горизонтальном состоянии… А с точки зрения привычности-удобства для пользователя вертикальные бегунки будут удобнее… и т.д.

В общем, конференция прошла успешно, я успела отрисовать изрядное количество черновиков экранов, и сегодня девочка-дизайнер уже рисует визуальные представления по этим черновикам. Они-то на самом деле, чуть причёсанные, и стали прототипами экранов для дизайнера. Формально, если бы было больше времени (и каждый занимался своим делом) по этим бумажным черновикам стоило бы сделать аккуратные схемы в каком-нибудь правильном редакторе, но сроки, сорванные канадским “проектировщиком” из-за того, что сначала он нарисовал не то, что надо потому что не понял, что же надо, потом в отпуске был, потом просто потерялся из-за интенсивных дискуссий с идеологами-генераторами идей по сервису. Отчасти его кст.говоря стопорил именно поток-объём идей: фантазёры-идеологи придумывали что-то совершенно не из реального мира, настолько оторванное от жестокой действительности, что он даже не знал, как это можно преобразовать в экранную форму и тем более в сценарий (набор экранных форм). И даже более того: часть нафантазированных идей тормозилась из-за того, что наиболее приближенные к технологиям, к реальной разработке менеджеры останавливали некоторые особо фантазийные идеи именно тем, что не были уверены, что разработчики, гм., смогут “такое” реализовать, а обсудить непосредственно с разработчиками техническую возможность невозможно (извиняюсь), потому, что разработчики спят, отделённые от дискуссии часовым поясом в +7 часов. Но проблема, должен ли проектировщик хотя бы в какой-то мере быть в курсе особенностей технологий разработки — это к вопросу о небольшой дискуссии по поводу одного из недавних постов “Дизайнерское: интерфейсы в исходниках” в трансляции на ya.ru, когда обсуждали требования к вакансии специалиста, то ли инфоарха, то ли проектировщика интерфейсов

Lisa:
1. Понимание особенностей разработки на .net для инфоарха точно будет обязательным входящим, или это можно рассказать при общей вменяемости человека?
2. Я видела, когда аналитика сочеталась с коммуникабельностью, но редко люди признают в себе оба этих качества одинаково сильными То есть аналитика тут важнее и ее человек должен самопризнавать, но я бы вторй пункт формулировала бы не как коммуникабельность, а как готовность и способность обсуждать и работать в команде. Оттенок чуть другой.
3. “Получение, обработка и синхронизация информации о текущих этапах разработки между разными подразделениями, работающими над проектом: отделом маркетинга, программистами, дизайнерами, интеграторами.” Это инфоарха задача или все-таки менеджера проекта? Я бы инфоарха не стала бы нагружать синхронизацией в процессе, в начале – да, деваться некуда, а в процессе это скорее для пм задача, отдавать инфоарху для внесения изменений уже согласованное.

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

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

В общем, описанным где-то там выше способом мы формируем первую группу наборов экранных форм, иллюстрирующих разные сценарии поведения пользователя в этой программе. Вплоть до того, что у файлов-иллюстраций каждого отдельно взятого сценария будут порядковые номера, чтобы канадские менеджеры не запутались при обсуждении первого, предложенного уже нами варианта; ведь следующий этап, всё ещё предваряющий уже реальную разработку, будет заключаться в том, что эти экраны (хоть и статическими картинками) будут тестироваться группой подопытных, которые будут изображать из себя представителей ЦА и создавать первую базу отзывов о работе будущей программы. А программеры уже в нетерпении подгоняют: их тестовые “учебные” скрипты готовы переростать в реальные, и, кажется им, затягивается процесс в бессмысленных совершенствованиях наименее важного для работающего сервиса этапа – проектирования интерфейсов и сценариев поведения.

Для нас же в общем-то понятно: канадское руководство просто пока прикрывает не особо одарённого чувака, который как бы “проектировщик интерфейсов”, понимает, что чувак не справляется, но, извиняясь перед нами, говорит о том, что “вот он ещё учится, пусть на этом проекте он ещё ошибается и делает неправильно, но если его не отшить, то на каком-то втором-третьем проекте у него начнёт получаться”. И ведь повлиять на ситуацию не возможно даже убеждениями в том, что на нашей стороне, в нашей команде этот этап – проектирования интерфейса – всё равно получается лучше, может сюда его и перенести? Ан нет. Почему? Потому что все те самые идеологи-фантазёры с генеральным в компании — они все там, за окияном, и проектировщик тоже им нужен на самом деле там, и это справедливо. Он должен их видеть, слышать, щупать общаться с ними, это должен быть диалог не только в процессе фантазирования, но и в процессе работы над прототипами, набросал черновики, показал, обсудили, перерисовал, показал, обсудили… а как удобно такие обсуждения иллюстрировать тут же зарисовками на доске с фломастерами! тут же стёр, дорисовал, показал, обвёл акцент… динамика! Мы оказались в менее динамичной среде: мои бумажные прототипы, дизайнерские эскизы, отрисованные в редакторе – это уже статика, на которую уходит больше времени; хорошо ещё, что почти всё, отправляемое от нас, почему-то утверждается почти без замечаний.

По поводу трудностей, которые возникают в таких распределённых командах, хочу процитировать кусок из одной замечательной статьи, найденной уже давно на rsdn`е и не закрываемой в окне Оперы уже несколько месяцев, изумительно иллюстрирующей именно наши проблемы, которые наблюдаю ежедневно, статьи Алистэра Коуберна “Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения”

Основным фактором в разработке программного обеспечения является возможность коммуникации. На рисунке 1 изображена некая кривая, с помощью которой я иллюстрирую свои методологические рассуждения. На этом рисунке видно, как падает эффективность коммуникации, если исчезает ее модальность и синхронизация. Этой теме посвящено несколько исследований (см. [Pl] и [Si]), кроме того, эту же зависимость подтверждает и Вайнберг, который описывал проекты около 30 лет назад [Wei].

Самым эффективным видом коммуникации является непосредственное, личное общение (например, когда вы обсуждаете что-либо и рисуете при этом на доске). Если мы будем убирать одно за другим все возможности общения, присущие двум людям, рисующим у доски, мы увидим, как падает эффективность коммуникации. Убирать мы будем следующие свойства:

• Физическая досягаемость. Я не знаю, как это объяснить, но физическая досягаемость собеседников влияет на их общение. Что бы ни лежало в основе этого влияния – трехмерность, синхронизация, запах или малозаметные визуальные сигналы – при коммуникации это имеет большое значение.
• Разнообразные модальности. Человек общается не только словами, но и при помощи жестов. Часто человек может высказать свое суждение жестикуляцией, например, поднимая бровь или указывая на что-то пальцем.
• Интонация и синхронизация речи. Чтобы подчеркнуть важность какого-либо высказывания или, к примеру, свое удивление, говорящий может ускорять или замедлять темп речи, делать паузы или изменять интонацию.
• Ведение диалога в реальном времени (вопрос-ответ). С помощью вопросов слушающий выясняет для себя то, что ему было неясно в речи собеседника, или же получает дополнительные сведения, которых ему не хватает для полного понимания предмета. Синхронизация вопросов и ответов является основополагающим определением типа коммуникации.

Итак, что же произойдет, если мы начнем убирать одно за другим все эти свойства?

• Убираем только физическую досягаемость. Поместим собеседников на противоположные концы видеосвязи. В принципе, при этом сохраняются все основные свойства физического присутствия, и тем не менее, эффект уже не тот. Когда мы испробовали этот способ в Норвегии, где одна часть команды разработчиков находилась в Осло, а другая – в Лиллехаммере, то оказалось, что команда находила верные проектные решения, только когда всем удавалось собраться вместе. Даже то время, которое люди тратили, чтобы вместе дойти до электрички, было более продуктивно для работы, нежели видеоконференция.
• Убираем жестикуляцию и визуальную синхронизацию, оставляем интонацию и вокальную синхронизацию (другими словами, используем для общения телефон). Большинство людей во время беседы по телефону рисуют. Если человек рисует линию, которая соединяет два прямоугольника, это значит, что он собирается сказать нечто важное, то, что нужно отметить особо. Визуально-слуховая синхронизация информации закрепляет в сознании человека ее суть. Когда люди говорят по телефону, эта синхронизация исчезает, а вместе с ней из коммуникации исчезают жестикуляция, выражение лица собеседника, и т.д.
• Теперь уберем голосовую синхронизацию и интонацию, оставим лишь возможность задавать вопросы (электронная почта). Без голосовой синхронизации мы не можем ни сделать эффектную паузу, ни подождать, не будет ли у собеседника возражений или вопросов, ни ускорить или замедлить темп речи, чтобы сделать высказывание. Лишив себя возможности использовать интонацию, человек не может выразить с ее помощью, насколько удивительна, скучна или очевидна выраженная в письме идея.
• Теперь уберем возможность задавать вопросы (но восстановим один из перечисленных выше факторов). Не имея возможности услышать вопросы собеседника, говорящий должен сам догадываться, что тот знает или не знает, какие вопросы мог бы задать, и включать в свою речь ответы на эти несуществующие вопросы. И все это он должен сделать, не имея обратной связи со своим слушателем. Этот вид коммуникации допускает наличие визуальной (видеокассета) или слуховой (аудиокассета) информации.
• И, наконец, убираем все свойства коммуникации – визуальные, слуховые, голосовые, синхронизацию общения, возможность задавать вопросы – что же мы получаем? Правильно, бумажную документацию. На приведенной выше модели вы видите, что документация является наименее эффективным способом коммуникации из всех возможных. Тот, кто пишет документацию, должен строить догадки относительно своей аудитории безо всякой обратной связи, у него нет возможности использовать ни синхронизацию и другие эмфатические сигналы, ни жестикуляцию и интонацию.

Но к некоторым экранам не возможно не придраться. Вот, к примеру, замечательный раздел “Мои коллеги” при условии, что никто из моих коллег на сервисе не представлен:

Как это, интересно знать, я могу быть своей собственной коллегой? Зачем же меня в этот список? Это что-то сродни “добавить себя во френды”. Хорошо, что хотя бы кнопка “пригласить (себя) в 1 круг” задизейблена. В любом случае имхо добавлять “себя” в список своих коллег — излишне.
Если в списке найденных позиций всего один элемент – на самом ли деле так нужны целых два чекбокса типа “выбрать все”, окружающие никакие не “все”, а единственный элемент списка?

Ещё одно спорное решение – с пересечённой навигацией, когда один подраздел принадлежит сразу нескольким разделам. Никогда не нравились такие решения, всегда сбивали с толку юзеров и вызывали недовольство сервисом. Простой пример: заходим в раздел “Сообщения”, оттуда из подразделов выбираем “Вакансии” (т.е. предполагается, что мы получим список сообщений-вакансий) видим вроде пока логичную картинку с навигацией:

После этого кликаем на любое сообщение из полученного списка и оп-па! Меню меняется на такое:

Где я, кто я? Теперь я не в “Сообщениях”, а в “Работе”, в каком подразделе раздела “Работа” нахожусь? Где подменю “Отклики”?

Интересное решение с логотипом Moikrug+Yandex. Да, по традиции логотип размещён в левом верхнем углу, воспринимается единым, цельным объектом, но его “верхняя часть” ведёт на главную яндекса, а нижняя – на главную Moikrug соответственно.

Вот только интересно, как много благодарных пользователей скажут своё вежливое “спасибо”, когда, как и на других проектах, потянутся в этот левый верхний угол,чтобы, скажем, вернуться на главную страницу проекта MoiKrug, и, не прицелившись, попадут в Yandex?

А ещё интересная какая штучка! Временной вертикальный градусник в разделе “Люди” -> “дни рождения”. Который сворачивается по месяцам. Очень оригинальное решение, правда. А вот поздравить *не яндекс.открытками*, а просто текстом по-прежнему из этого интерфейса нельзя, неужели же ж все прям так любят эти открытки и ни разу никто из пользующихся сервисом не попросил такую простую задачку решить? А я каждый раз, если хочу кого-то поздравить, выхожу из интерфейса “дней рождений”, и иду отправлять пользователю обычное сообщение с поздравительным текстом.

К примеру, в одной из прошлых заметок я писала о том, как часто дизайнеры, рисующие эскиз, забывают о том, что текст, который на конечном веб-сайте будет отображаться текстом, желательно в эскизе ставить с отключенным anti-aliasing`ом, что, с одной стороны, является подсказкой верстальщику о том, что этот текст – не элемент оформления, который будет картинкой, с другой стороны – не вводит в заблуждение заказчика, который, утверждая эскиз, видит одно представление, получая отвёрстанный веб-сайт – совсем другое. Оказывается, обратная проблема – тоже не редкость, когда текст, на эскизе отрисованный явно со спецэффектами и должен на сайт ставиться соответствующей картинкой, почему-то отрисовывается без антиалиасинга, и это не элемент дизайна. Типичный пример:

Ещё одна из распространённых проблем – намеренно низкая цветовая контрастность между текстом и фоном; но как бы ни был представлен текст на сайте – собственно текстом или картинкой, суть в том, что его будут читать, и он при этом должен быть читабельным. Какую такую особую нежность видят рисующие дизайнеры в таком решении, объяснить не могут сами, однако когда указываешь на ошибку — иногда обижаются, но чаще — удивляются, мол, и правда, а как же я сам-то недосмотрел?

В этом примере есть сразу несколько ошибок: и та самая низкая контрастность между цветом фона и цветом текста, и отключен anti-aliasing на явно декорированном тексте, и ещё одно: этот ужасный градиент, особенно тот, который в нижних трёх строках. Первое впечатление от такого оформления: оп-па, мы опять в 90-х! Объяснить же, что это не модно, не красиво, неуместно, бывает очень сложно; особенно при условии, что мы-то совершенно не против градиентов в оформлении шрифтов в принципе и часто используем, и смотрится успешно. Вообще же про “немодность” в шрифтографике говорить сложно, любое решение может смотреться в определённом контексте безупречно и уродливо, здесь, конечно, многое зависит от мастерства дизайнера.

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

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

Шрифт Dear Joe не похож на ваш почерк. Он не похож на чей бы то ни было почерк. Если вы считаете, что по идее вашего дизайна следует использовать ваш собственный почерк как шрифт, попробуйте научиться пользоваться Fontifier и оставьте бедного Джо в покое.

Шрифт Dolphins ассоциируется с рекламой развлекательных мероприятий 70-х годов. Конечно, есть вероятность того, что он будет даже в какой-то мере уместен в рекламе, скажем, воскресной дискотеки с темой музыки 70-х годов прошлого века, но к сожалению, современными дизайнерами он используется в самых сверхъестественных, самых несоответствующих местах.

Шрифт Papyrus может быть вполне уместен для эскизов макетов с этнической темой, но из-за того, что его изрядно “затаскали” к месту и не к месту, на сегодняшний день использование этого шрифта говорит только о том, что дизайнер попался ленивый и лишённый воображения.

По какой-то причине и дизайнеры, и заказчики дизайна очень любят этот шрифт. Да, он сильный, мощный, но… такой уродливый!

Шрифт Brush Script на сегодняшний день используют только невоодушевлённые задачей дизайнеры, которые почему-то посчитали, что тот же “Times New Roman” для них “слишком серьёзный”.

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

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

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

Замечательная картинка, которая и может быть иллюстрацией тому, как визуальными средствами можно подсказывать пользователю, куда тянуться мышей и на что кликать. Но дизайнеры — публика упёртая, и зачастую, пока не докажешь на практике, что их пречудесный интерфейс “не работает”, ошибку в эскизе не видят. Интересно при этом, что те дизайнеры, которые знакомы с какими-то анализаторами активных зон на веб-страницах, типа той же зоны, в которой должна находиться СамаяГлавнаяКнопка, гораздо более динамично реагируют на замечания, да и при разработке эскиза мыслят немного по-другому, держат на не особенно осознаваемом уровне ту самую будущую карту кликов, сводя весь интерфейс к одной активной зоне.

Анализировать активные зоны на сайте можно только постфактум, когда уже потрачено время на эскиз, вёрстку, интеграцию. У всяких отделов маркетинга, который тестированием и анализом занимается в промышленных масштабах, в работе какие-то платные тулзы, но для бытовых целей обычно достаточно бесплатных или условно-бесплатных. Общую информацию о самых кликабельных, горячих зонах страниц сайта может предоставить тот же Google Analytics (раздел “Содержание”, подраздел “Наложение данных на сайт”):

Ну да, кликните на превьюшки, чтобы увидеть экраны с метками google analytics в полный размер. Метки показывают в прямоугольничках на ссылках, сколько в процентном отношении, относительно общего количества кликов по ссылкам в документе, кликали на конкретные ссылки. На первой превьюшке можно увидеть клики на главной странице этого блога, на второй превьюшке – на одной из внутренних страниц, одной из последних добавленных записей. Это не особенно удобно для анализа:

• во-первых, в интерфейсе аналитики я так и не нашла, как переключить относительные значения в процентах в абсолютные значения в количествах кликов.
• во-вторых визуализация этой статистики… подкачала. да, не наглядно, излишне, по моему мнению, лаконично. Здесь будет уместно (и многим дизайнером полезно) вспомнить о замечательном visualstyle.ru, где в разделе “Визуализация” как раз и публикуются разные оригинальные способы построения инфографиков, любых данных.

Ещё один замечательный сервис, который поможет вам построить карту кликов сайта – http://crazyegg.com/, как раз он и есть “условно бесплатный”, т.е. тестовые карты можно построить бесплатно, но для профессиональной работы стоит завести платный аккаунт. У этих ребят всё в порядке с визуализацией, строятся карты и с зонами, где холодные цвета показывают менее активные зоны, чем горячее цвет, тем активнее зона, и с метками, при клике на которые можно посмотреть точные, абсолютные значения количества кликов (метки тоже цветные, тона ближе к красному – больше кликов, синие – меньше). Так же можно построить карту с зависимостью кликаемых зон с разрешениями экрана, операционными системами, в зоне “konfetti” есть так же интересная статистика количества кликов пользователей, пришедших от конкретных рефереров (вот вам визуальный инструмент оценки полезного траффика и бесполезного).

Очень мне нравится простенький, как в настройках, так и по визуализации результатов тестирования сайта adgreed.com. Показывает статистику по кликам (не только на ссылках, но и случайных кликах по тексту или пустому экрану, это для дизайнера тоже, кстати говоря, важная информация) и по движениям мыши по экрану. Статистика показывается раздельно для разных разрешений экранов пользователя, клики и движения мыши которого учитывались. При этом обнаружилось интересное: если для документа стоит одновременно код google analytics и код adgreed, и во вкладке со статистикой от google analytics была запущена задача “Наложение данных на сайт”, то AdGreed показывает экран с графическим представлением статистики, наложенным на фиксированные по ссылкам данные от гугла (те самые, в процентах относительно общего числа кликов). Получается вполне наглядно:

Здесь на первой превьюшке – визуализация статистики по движениям мыши (зелёные метки), на второй – клики (красные метки), статистика для экрана 1024px, на третьем – клики, статистика для экрана 1600px.

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

Не так давно одна наша талантливая девчушка-дизайнер рисовала новый интерфейс на прогу, написанную на Builder`е. Дизайн утвердили, порезали и внедрили. Кажется, прога получилась удачная и в перспективе успешная, потому что срочным образом прислали переводы элементов интерфейса (по дефолту английский) на французский, немецкий, испанский. А девчушка, которая рисовала эскиз, в отпуск ушла. А изрядная часть этих самых “элементов интерфейса”, с текстами, сделана графикой для пущей привлекательности. Открываю исходник, а там… Все слои структурированы по группам и подгруппам, все названы так, чтобы можно было найти любой блок, в группе иконок подгруппа на состояния этих иконок – обычные, активные, over,  click, и то же самое со всеми остальными панельками и закладками.

Дабы не нарушать красоту структуры исходника, в каждом на тексты создала ещё подгруппы – по языкам, замена текстовок заняла меньше получаса, генерация всей графики – около часа. Слои в самом PS выглядят при этом так:

На один (два) уровня повышаются степени вложения групп в том случае, если необходима так же отрисовка разных экранов. И как же было невероятно трудно работать с исходниками, отрисованными нашими канадскими друзьями, когда поиск достоверных слоёв для каждого экрана интерфейса — это загадка, которую даже если и удаётся разгадать, толку от этого не много, потому что интерфейсы – не достоверны. При 10 элементах главного меню, в каждом из которых от 3 до 8 элементов подменю в 9 из 10 экранов АКТИВНЫМИ подсвечиваются не те, которые активны в этом интерфейсе. В формах текстовые поля (input`ы) нарисованы РАЗНОЙ высоты, и при выяснении напрямую с их менеджером “что это за прикол” оказывается, что, конечно же, недосмотр, вы там сами сделайте одинаково, это же САМО СОБОЙ РАЗУМЕЕТСЯ. Часть отрисованных элементов вообще не должна присутствовать в формах и попадала туда по ошибке или недосмотру главного менеджера, который увидел красивую картинку и отмахнул – отправляйте!, не попытавшись даже проникнуться логикой данного сценария. Чуть ли не половину форм приходится придерживать до тех пор, пока этот канадский менеджер проснётся, чтобы можно было выяснить — ошибка ли нарисованное или новая фича, и к какому разделу относится “вот этот” правильно нарисованный, но неправильно названный экран. В конечном итоге уважаемый канадский менеджер задолбался выяснять отношения между нами и канадскими же дизайнерами, махнул рукой и сказал нам: “вы там сделайте… на своё усмотрение… чтобы красивенько и в общем стиле предыдущих экранов”.

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

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

Проектировщик интерфейсов

Личные качества:

• аналитическое мышление;
• высокая коммуникабельность;
• ответственность.

Профессиональные:

• умение структурировать информацию, внятно излагать мысли в устной и письменной форме, создавать графические прототипы
• умение оценивать комплекс задач в целом и одновременно внимательность к деталям;
• опыт разработки пользовательских интерфейсов: знание базовых принципов их построения, опыт создания пользовательских интерфейсов для веб-приложений, разработки схем, диаграмм, «скелетов» веб-страниц;
• понимание жизненного цикла разработки веб-проектов;
• понимание особенностей разработки на .NET.

Задачи:

• Участие в обсуждении целей и задач проекта, частей проекта, функциональности отдельных модулей, доскональное понимание прикладной задачи.
• Проектирование информационной модели работы пользователя (групп пользователей).
• Согласование мнений о содержании, структуре и организации сайта в целом.
• Получение, обработка и синхронизация информации о текущих этапах разработки между разными подразделениями, работающими над проектом: отделом маркетинга, программистами, дизайнерами, интеграторами.
• Разработка макетов экранных форм и сценариев диалогов.
• Поддержание макетов экранных форм в актуальном состоянии и предоставление этих макетов разработчикам ДО начала реализации, а не постфактум, когда что-то исправлять уже поздно или нерентабельно.
• Принимать участие в usability-тестировании интерфейса, вносить предложения по оптимизации экранных форм с точки зрения удобства использования.
• Уметь мотивировать свои решения и предложения перед разработчиками и перед менеджментом, представляющим отдел маркетинга.

Ссылка на вакансию, “чем-то похожую на то, что хотелось бы”, спасибо Денису Бескову-Доронину

http://www.iainstitute.org/jobboard/jobs/job.php?id=4020

Вот, к примеру, такая интимная вещь, как организация фолдеров и файлов на дизайнерском компьютере: каждый, кто приходит в офис, пытается создать себе такую структуру, какая уже была у него на домашнем компьютере или на предыдущей работе. Иногда рабочие файлы запрятаны в глубь поддиректорий или даже разбросаны по разным дискам — от десктопа и “My Documents” на C: до совершенно невообразимых путей разной глубины на других дисках. А представьте себе, если по ходу горячей работы дизайнер внезапно не пришёл с утра на работу (мало ли, заболел), или, что ещё чаще бывает, в конце рабочего дня отправил эскиз и благополучно ушёл домой, и тут обнаруживается, что в отправленном допущена ма-а-аленькая ошибка, которую НАДО исправить сегодня, потому что она должна уйти в работу для канадских интеграторов, у которых рабочий день только начался. И что? Им терять целый рабочий день?

Я, обычно, всё равно задерживаюсь на 2-3 часа позже остальных наших творческих личностей, и часто бывает так, что по ходу дорабатываю что-то из их исходников (ошибки или замечания канадских менеджеров), но запоминать все уникальные структуры для файлов надоело. А компы дизайнерские все типовые и размечены одинаково на два диска, С и D. Поэтому был введен локальный корпоративный стандарт:

• Все рабочие проекты живут на диске D в папке projects, в которой создаются папки с именами, соответствующими проекту, для которого ведётся работа. Даже если по этому проекту дизайнеру нужно было нарисовать одну единственную иконочку – исходник для неё, версии и результирующий файл должны лежать в папке с именем этого проекта, никаких temp или other!
• Если проект контролируется через SVN, папка с дизайнерскими исходниками по проекту должна лежать в общей папке проекта, просто не добавляется в SVN.

Следующий трабл обнаружился, когда оказалось, что дизайнеры нифига не хотят уделять внимание именам файлов тех эскизов-иконок-экранных окон, которые они создают/отдают в работу верстальщикам или программерам. И ходит в работе очередной “test123.png”, потом “Первая Проба 123-1.png” (ага, вот так вот, через пробелы), потом “!!!my last test123-5.png” или ещё что похуже, и разобраться в собственных версиях картинок, или даже идентифицировать быстро, для какого проекта какая из картинок рисовалась, в какой-то момент не может уже сам дизайнер, не говоря о том, какие проблемы возникают, если нужно срочно передавать его работу другому. Поэтому мы договорились именовать файлы так:

• никаких пробелов в именах файлов, никогда. И никаких русских букв, тоже никогда;
• если это название скетча для проекта, которым занимается один дизайнер, в имени – латиницей название этого проекта;
• если была необходимость в версиях скетчей – номер версии указывается постфиксом через дефис;
• если на один проект рисуют разные дизайнеры (есть у нас целая ветка, рекламные сайты, там их много на каждую тему делают) – к имени скетча добавляется имя дизайнера.

Причём внутри нашей команды получилось договориться без проблем, с канадскими же дизайнерами упорно не получается договориться до сих пор. И ведь доходит до нелепостей и полной, извиняюсь, бюрократии. К примеру, приходит скетч и требование к нему “отверстать допиксельно как нарисовано, ибо утверждено всем возможным руководством вкупе с отделом маркетинга”. Ок. Верстаю. Обращаю внимание, что на двух равноценных панелях с картинкой-стрелочкой (линк на следующий шаг) эта картинка на одной нарисована с отступом в 20 пикселей от правого края, на втором – 10 пикселей. И уточнить было бы по мессенджеру у канадского рисовальщика интерфейса (или почтой, хоть бы и с СС его руководителю, если не жалко палить ошибки дизайнера) — дело минуты, но нет же. Мне приходится писать ГлавномуНашемуМенеджеру, который мой месседж перепосылает ГлавномуКанадскомуМенеджеру о том, что здесь, скорее всего, ошибка. Тот мне отвечает через нашего менеджера письмом: нет, ошибок нет, верстайте как нарисовано. Да нет же, говорю, такого не может быть. Пришлите, говорит, скрин и обведите красным, где вы видите ошибку. И вот я на скрине указываю красным разницу в отступах, перепосылаю нашему менеджеру, тот – канадскому, оттуда приходит ответ, что “дизайнер, который рисовал эти скетчи, вышел на ленч, так что вы сами просто учтите там при вёрстке, что правильное решение – 20 пикселей от правого края”.

Это я привела достаточно абсурдный пример, знаю, хотя он не придуманный. Основные же договорённости всё равно касаются проблем с исходниками скетчей. Опять же, большая часть из них очевидны и тыщу раз озвучены веб-мастерами, но увы, приходится об этом писать опять и опять, и, если со своими договориться получилось сразу, то канадская команда упорно не хочет придерживаться этих правил. Итак, про .psd исходники:

• Все слои должны быть именованы в соответствии с содержащимися в них объектами. Группы слоёв должны быть объединены в Set`ы (Groups) требуемой вложенности, и тоже должны быть именованы. Все эти Layer68 и Group29 – самый удобный способ запутать партнёров по проекту.
• В случае, если в одном файле включены группы слоёв для разных экранов (разных разделов сайта или программы), базовые группы должны полностью визуализировать экран. Чтобы не надо было догадываться, что для экрана такого-то нужно включить второй слой (контент), 28-й (шапка с формой) и 69-й (меню с правильно подсвеченным элементом меню), а для… ну, понятно, в общем.
  

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

• Cценарии поведения объектов – кнопок, табов, элементов меню.
  

  Замечательно получилось, когда на один из проектов дизайнер всё хорошо сделал и продумал – и структура групп, и имена слоёв. Картинка была хорошо порезана, проект (не web, а windows приложение), всё скомпановано. Потом дизайнер уволился, а у нас возникла задача сгенерить интерфейс для языковых версий. А навигация по разделам вся — рисованная, и по задумке дизайнера все элементы навигации – чуть отличаются друг от друга, и каждый элемент при этом имеет пять состояний (normal, active, over, press, disable). И сценарий на смену каждой кнопки дизайнер ДЕРЖАЛ В УМЕ: вот для нормальной “этот” слой – 80% opacity, для over – 100%+включается “вот этот слой”, для disable – 63% + выключается “вот этот слой”. Замечательно, но как мы с другим дизайнером, которого спешно пришлось ставить на этот проект, “угадывали” эти сценарии для генерации состояний элементов… в общем, такого быть не должно.

• Ещё немного очевидных вещей – типы шрифтов. Правила должны быть достаточно строгими: для текстов, которые будут использоваться в проекте, использовать только стандартные шрифты, все тексты с нестандартными шрифтами завёрстываются картинками. Уж сколько раз твердили, повторяли, настаивали…
  

  Очень любят канадские дизайнеры использовать в эскизе “шрифты, похожие на стандартные”! И обидно, что с т.зр. визуала (это важно при презентации своего скетча руководству, чтобы утвердили побыстрее) макеты с этими “почти похожими” и в самом деле смотрятся значительно элегантнее. а на наши угрозы со словами “все тексты, которые отвёрстаны нестандартными шрифтами, будем ставить КАРТИНКАМИ” руководство вяло отбивается “да нет, ставьте текстом… подберите что-то там наиболее близкое…”

• Anti-aliasing — больная тема. Опять же, если текст должен в проекте быть текстом, он и в эскизе должен быть не размытым, с выключенным anti-aliasing (=none). Очевидно? Казалось бы, да, но упорно не соблюдаемо.
  

  Это вызывает серьёзные спорные моменты, особенно для заголовков, которые (в сл. веб проектов) или жирные, или не жирные, сделать вёрсткой заголовок, который должен быть текстом, стандартным шрифтом и чуточку тяжелее, чем его regular (заметно на тех же, скажем, Tahoma+regular+Sharp anti-aliasing) практически не возможно. И, как всегда, отмазка, мол, сделайте уже как-нибудь.

• Стандартные эффекты. Так же, как и в случае со сценариями, где нам приходилось угадывать свойства слоёв для состояний кнопок, так же часто невозможно угадать, какие свойства и эффекты применялись к слою перед тем, как дизайнеру вздумалось отрендерить слой в “простой”.
• Стандартные объекты. Значительная часть дизайнерских скетчей легко раскладывается на стандартные объекты – прямоугольные (четырёхугольные или со скруглёнными углами заданного радиуса), окружности-овалы, должны оставаться векторными формами. То же касается сложных форм, нарисованных пером или интегрированных из векторного редактора, то же касается векторных масок.

Хорошую заметку прислали, на английском, специально прямо для наших канадских творцов: “10 Tips For Creating Website Mockups In Photoshop“. Но я бы не стала так уж прямо привязываться к первым двум пунктам, или же сформулировала бы по-другому. Всё-таки простые формы в дизайне экранов – это частный случай, а не обычное решение. А как часто и мои дизайнеры, и я сама в скетче что-то не векторное дорисовываем ручками, доводим до идеального состояния. Да, эскиз получается не масштабируемый легко, ничего не поделаешь. Простые векторные формы, плоский стиль подходит не для 100% задач.
Ещё важно, из того, что должен отслеживать дизайнер на этапе создания макета (а не отдавать на волю верстальщика или программиста) — как должен выглядеть интерфейс при разных разрешениях экрана:

• если дефолтный скетч рисуется для разрешения экрана 800х600, проверить, как он будет смотреться при разрешениях 1200х1024, 1600х1200;
• если предполагается резиновый дизайн, показать, как он будет тянуться и куда что ползёт, какие элементы продолжают выравниваться от центра экрана, какие выравниваются по правому/левому краю, как изменяются размеры панелей;
• если предполагается фиксированный дизайн – показать выравнивание по отношению к центру экрана;
• то же касается экранов для windows-программ – как выглядит интерфейс при изменении размеров программы, её минимальный размер + full screen.
• если предполагается фиксированный дизайн, но с неоднородным основным фоном, показать поведение фона при изменении размеров окна и (к примеру) центрировании рабочей области.

В командной офисной работе ситуация меняется, и значительно. Даже в команде из двух человек – рисующего дизайнера и работающего с ним в паре верстальщика уже появляются какие-то требования к макету, который дизайнер отдаёт верстальщику в работу, какие-то договорённости по методам обмена информацией, стандартах документов и даже в именовании объектов работы. А если в команде несколько рисующих дизайнеров и несколько верстальщиков? Практически не возможно в реальной работе избежать ротации проектов и дизайнеров на проектах. По разным, обычным совершенно причинам, к примеру, временным:

• дизайнер уходит в отпуск (замечательная причина, я считаю!)
• дизайнер заболел, и не меньше чем на две недели (будьте здоровы, дорогие!)
• дизайнер отпросился по семейным обстоятельствам (это, обычно, несколько дней, но проект-то ждать не будет!)
• дизайнера просто приходится переводить с одного проекта на другой (сложная причина. Иногда необходимо это делать несмотря на то, что этим дизайнером уже выполнено 70% работы.)

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

• дизайнер уходит в декретный отпуск (и это тоже замечательная причина!)
• дизайнер увольняется потому, что ему предложили что-то получше (для любого человека естественно выбирать лучшее предложение из имеющихся, глупо ведь взывать к смешным “верности компании” или прочим абстрактным сущностям)
• дизайнер увольняется потому, что ему не интересны задачи, которые ставятся в этой компании (мало ли, человека в 3D тянет, а здесь у него сплошь плоские интерфейсы, юзабилити какое-то и прочая чушь)
• дизайнера увольняют (тут причин может быть много, они описывались уже раньше в заметках “Почему увольняют дизайнеров?” и “Дизайнеров увольняют потому что… Продолжение“.)

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

Весной была довольно объёмная работа над одним приложением. Помимо прочих “элементов дизайна” необходимо было разработать в едином стиле 12 полноформатных иконок для базового приложения и для его подприложений, каждая с фреймами 256×256, 128×128, 64×64, 48×48, 32×32, 16×16, каждый размер в решениях 32 бита и 8 бит. Ничего сложного, но у нас с иконочной графикой дизайнеры возиться вообще не любят, совсем пиксельные стандарты (на 16 цветов и на 2 цвета) не были нужны, но всё равно для мелких размеров в 256 цветах обычно нужна ручная догонка фреймов. Программист сделал 11 иконок из 12 и… вынужден был по важным семейным обстоятельствам отпроситься в отпуск на неделю. По проектным срокам иконки должны были понадобиться дней через 10, поэтому отпустили без проблем. Но у нас как всегда: внезапно изменилась погода, всё перекроили, где-то на горизонте замаячили инвесторы и сообщение о том, что презентация – в пятницу, до которой три дня. Я перевожу “доработку” последней иконки на другую девочку, тоже талантливую и умелую. Пол дня она пыталась… нарисовать эту последнюю иконку в стиле предыдущего дизайнера. Потом забила и за полтора дня ПЕРЕРИСОВАЛА все 12 иконок в почти (почти!!!) том же стиле, но всё же немного по-другому, в соответствии со своим видением правильного набора иконок. Её иконки оказались удачными вполне, работу утвердили, а 11 иконок предыдущего дизайнера, неделя работы, оказались просто не востребованными (хотя по виду тоже ничего, не плохо).

А ещё… а ещё бывает так, что команда дизайнеров (и рисующих, и верстающих) распределена между континентами. Телефоны-интернеты, конечно, в какой-то мере сглаживают границы между распределёнными офисами, но всё равно договориться, если человечек не стоит перед тобой прямо сейчас, если он не видит твоего лица, если ты говоришь по английски не идеально, он русский не знает, да и английский знает не намного лучше тебя, а у тебя француский вообще по нулям, а приглашать переводчика – это испорченный телефон, с меньшей потерей вы уж как-нибудь сами на английском, если при этом всём у вас ещё и разница во времени в 7-8 часов, и возникает вопрос по работе, который останавливает работу с одной стороны, потому что вторая сторона ещё (или уже) спит, если есть элемент недоверия к какой-то там заграничной команде и отношение к ним, как к соперникам, и где-то немного, чуть-чуть (достаточно, чтобы усложнить, но недостаточно, чтобы уволить) саботируется этап работ, или если какие-то стандарты, которые имеют отношение не столько к дизайну, сколько к тому же представлению о том, что такое здравый смысл, если это всё приплюсовать к перечисленным выше проблемам, которые вынуждают вводить стандарты и договорённости….

Тогда в дизайнерском офисе вынуждены вводить какие-то внутренние стандарты и договорённости, да.

Я попробую не разлениться к следующему посту и всё-таки немного написать о наших стандартах и договорённостях, тех, которые уже введены (в частности, по поводу файловой структуры офисной машины или по поводу структуры исходных графических файлов) и тех, которые ещё, видимо, будут вводиться, а вы, уважаемые читатели, можете написать о каких-то удобных вам или принятых в вашей компании правилах для дизайнеров и дизайнерских проектах.