Блог NunDesign

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

Не так давно одна наша талантливая девчушка-дизайнер рисовала новый интерфейс на прогу, написанную на 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.
• если предполагается фиксированный дизайн, но с неоднородным основным фоном, показать поведение фона при изменении размеров окна и (к примеру) центрировании рабочей области.

Узнала, что журнал Cool Girl закрывали с формулировкой “используют изображения обнаженных людей и животных в сексуальных позах”.
Как жить при власти, для которой “обнаженное животное в сексуальной позе” - не пустой звук?
© Линор Горалик

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

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

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

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

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