Блог NunDesign

И у меня скоро грядёт долгожданное счастье – две недели отпуска. Уехать по особым причинам никуда не выйдет – и дитёнку в школу, а куда ж я без него, и вообще, так что должгожданного моря в этом году уже не светит, вот и кончилось наше лето. Но всё равно, даже о таком тихом отдыхе мечталось уже давно, и стопка книжек для чтива ждёт, и настроение мало рабочее. Заявления на отпуск у наших тимлидов обязательно должны согласовываться с канадским руководством, и я, честно говоря, волновалась, что как раз именно перед отпуском обрушится срочный, важный, глобальный проект и мне дешевле будет остаться в офисе. Но вроде всё тихо, руководство “дало добро”, руководитель одного из подразделений даже с комментарием “ I think that Tatiana really deserves a vacation and I’m ok with it! ” – прям умилилась, чесслово, настолько, что даже не стала отвечать, что правильное написание имени – Tatyana через ya :).

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

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

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

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

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

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

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

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

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

Человечек специалист, который у них, там, должен был бы рисовать прототипы, группировать по сценариям и присылать сюда готовые шаблоны для рисующего дизайнера, то ли не справляется, то ли вообще не подходит для такой работы. Его первый вариант экранов, отрисованный в 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].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(more…)

Я уже расказывала о том, что наши дизайнеры кроме прочих задач рисуют эскизы рекламных сайтов, большей частью на наши же программы и сервисы, в том смысле, что разрабатываемые у нас, а не для сторонних заказчиков. Таких рекламных сайтов на каждую тему может быть несколько: организовывается ли акция, или  выпускается версия программы, заточенная под определённые задачи (суть определённых задач заказывает отдел маркетинга, у них там свои исследования) или затеваются продажи на другой рынок (один из примеров – индийский рынок, и рекламная компания, ориентированная на индусов, там и цветовые гаммы использовались другие, не такие, как для американской аудитории, ещё была кое-какая специфика). В принципе постановка задачи для рисующих дизайнеров всегда почти одинакова: чётко (не запрятано среди прочих “элементов дизайна”) видно название программы или сервиса, тексты, которые кратко дают понять, что это за программа и зачем она юзеру – в первой половине экрана, и СамаяГлавнаяКнопка “Download Now” (для программ) или “Join Now” (для сервисов) в правой верхней части экрана, по исследованиям отдела маркетинга эта зона – самая комфортная для клика по главному элементу сайта.

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

(more…)

Когда я писала заметку “Офисное дизайнерское – несколько наших 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 удачных, утверждённых скетчей на разные проекты, а это, извиняюсь, не хухры мухры, и себя осуждаю, пинаю как могу… Она же мне сказала, что всё таки отошлёт скетч, почему же я только предупредила её о том, что это неправильно и рисковано? Надо было блин запретить! Даже в ущерб нашим замечательным отношениям, её уверенности в своих талантах. Теперь вот думаю, что, может, срочно нужно опыта поднабраться для пущего соответствия канадскому офису и покурить чего такого особого?

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

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

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

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

И вот такая, казалось бы, мелочь пузатая, а не задача, становится трудно реализуемой из-за того, что какая-то скромная подзакладка (типа табов) по имени “IE PLUGINS” во французской версии называется “EXTENSIONS des fichiers IE”, а вспомогательный текст на специальной панели, так до пикселя размеченный, в эту панель просто не влазит. Делать панель больше? Значит, две другие, рабочие, нужно соответственно уменьшать. А с размером шрифта поработать нельзя, потому что у программеров шрифт задаётся в каком-то специальном объекте, одном на все текстовки. А размеры панелей у программеров где-то захардкодены так, что динамично изменять их в зависимости от локализации невозможно, а переделать – возможно, но (возвращаясь к вопросу о перепроектировании с нуля) “это займёт некоторое время”, которого нет у нас, нет в плане у PM`а, нет у заказчика.

Скажите мне только, почему так удивляется поставщик (сюда) задания, что чего-то сделать нельзя или можно, но “не быстро”? Задача-то месяц назад ставилась совсе-е-ем другая. Даже взять всего один элемент новшеств — те же языковые локализации, уже была бы другая концепция, изначально, и проектировалось бы другое, а ведь это только один, ближайший пример. И начинаются костыли, и разрушается логичная концепция, и у разработчиков опять состояние, близкое к тому, что это они — не профессионалы, работают над трудным, очень может быть что — неудачным проектом. А трудностей-то всего в том, что основная задача – костыли удержать да подпорки расставить. А тут ещё к ихним трудностям мы, мыши дизайнеры. У нас, видите ли, немецкая кнопочка сюда не помещается, а значит, нужно не просто текстбокс уменьшать, но и прогрессбар сдвигать, и ещё что-то там не состыковывается… А тут бы после добавления ещё (скажем так) 10% функциональности надо бы сценарии вывода интерфейсных окон изменить…

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

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

UPD: я ни разу не программист, так же, как и прочие дизайнеры в команде, поэтому большую часть проблем, которые нельзя решить, озвученных программерами, мы принимаем на веру. К примеру: заказчик хотел. чтобы интерфейс проги мог открываться на full screen. Программеры сказали: это не возможно в данных условиях реализовать на ближайшем этапе. Почему? Я не знаю. Но дизайнерам приходится работать в рамках фиксированных размерах окна. И таких примеров много.

Тестировщик наш в растерянности… Получил список исправлений по проекту, которые нужно проверить, а там, помимо программерских пунктов задачи для дизайнеров с формулировками типа “сделайте нижнюю кнопку БОЛЕЕ КРАСНОЙ…“, подходит, спрашивает, а как это протестировать? Пипеткой цифры замерять?

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