.jpg "Как дизайнеры и разработчики могут играть слаженно (и продолжать бегать с ножницами)")
На перевод этой статьи меня побудила статья Кормление и уход за разработчиками (или почему мы такие ворчуны).
Автор той статьи отвечает на топик, приведенный ниже. Для полного видения картины нужно посмотреть на нее с разных сторон. Автор предлагает посмотреть со стороны дизайнера. Кому интересно — под кат.
Как дизайнер, работающий в технически ориентированных компаниях последние десять лет или около того, я трачу много времени на работу с разработчиками. Эти сотрудничества — наиболее конструктивные и плодотворные рабочие отношения, которые у меня были.
Дизайнеры, вы тоже можете создавать эти типы отношений с разработчиками — вы просто должны прорваться через ваши личные предубеждения (как дизайнеров, так и разработчиков), чтобы создать пространство для эффективного партнерства. Если вы успешны, преимущества намного перевешивают любые боли и незначительные изменения необходимые, чтобы этого добиться.
Я работала в консалтинге, в академии и в одной из самых известных фирм-разработчиков в мире. Я видела поведение разработчиков с разных сторон и работала с многими видами дизайнеров (от очень технических до концептуальных, до визуальных и иных).
Есть несколько устоявшихся моделей поведения плохо дизайнера, которые подрывают нашу репутацию в глазах разработчиков. Я добилась большого успеха, уточнив свой подход к дизайну в технически ориентированной компании, и в процессе образовались долговечные, основанные на доверии, эффективные отношения с разработчиками, тогда как остальные дизайнеры провалились. Хороший дизайнер может экспоненциально улучшить свою работу, если он имеет хорошего партнера-разработчика, но для этого они должны внести небольшие корректировки.
Здесь мои лучшие подсказки для создания эффективного дизайна и технических отношений. Моя цель — уменьшить предубеждения с обеих сторон и помочь дизайнерам и разработчикам сформировать сильный альянс для создания лучших продуктов.
1. Используйте инструмент, которым пользуются они
Как дизайнер, вступающий в новую команду или начинающий новый проект, первый шаг — это задать простой вопрос: «Как тебе нравится работать?». Многие дизайнеры совершают ошибку использования инструментов или процессов, к которым они привыкли или они нашли успех с предыдущей командой. Но вещи меняются быстро в программном обеспечении, и каждая команда уникальна.
Я обнаружила, что я могу избежать процесса расхождения, просто спросив команду разработчиков, как им нравится работать и какими инструментами они уже пользуются. Некоторым командам нравится создавать согласующий документ, чтобы отслеживать баги или использовать программное обеспечение для их поиска. Некоторые могут даже просто отправить имеил или использовать гибкий инструмент наподобие Pivotal Tracker.
Ключ к дизайнерскому успеху — это не то, насколько хороши их приемы, но то, как они успешны в взаимодействии их дизайна, так, чтобы рабочий проект был близок к идеалу, насколько это возможно. По-настоящему хороший дизайнер может адаптироваться к любому инструменту, необходимому для эффективного взаимодействия дизайна — даже если изучение нового инструмента занимает немного больше времени, это окупается в прокладывании дороги с помощью уменьшения трения с разработкой.
2. Участвуйте в полном цикле разработки
Дизайнеры могут легко испортить свои отношения с разработчиками, если они не активизируются до самого конца цикла разработки продукта. Команда разработчиков, работающая к запуску, разочаровывается, когда аутсайдер пикирует с несколькими детальными изменениями. (И если вы не включитесь раньше, чем прямо перед запуском, вы фактически аутсайдер.)
Разработчикам нужны дизайнеры для участия в полном цикле жизни продукта или возможности, не просто для разработки фронт-энда. Дизайнеры должны быть хорошо осведомлены (если не вовлечены) о тяжелых инженерных задачах создания основных структур данных, хранения, поиска и фреймворках интерфейса. Дизайнеры должны праздновать и способствовать каждому этапу вместе с остальной частью команды — даже если это кривой, наполовину сделанный прототип, использующий набор #00C ссылок в Comic Sans
Слишком часто я наблюдаю, как мои коллеги дизайнеры вмешиваются в эстетику или взаимодействие дизайна раннего прототипа. Ранние критические замечания дизайнеров о вещах, о которых инженер ещё даже не задумывался, не способствуют включению дизайнера в следующие ревью. В результате дизайнеры кончают тем, что начинают выпрашивать значимые изменения за неделю до запуска и, в большинстве случаев, не получают их.
3. Будьте конкретны насчет того, что требует улучшения
Многие дизайнеры думают, что они закончили, когда дают законченный, «pixel-perfect» макет разработчику. Дизайнеры начинают нервничать, когда продукт или возможность становятся близки к релизу, и фронт-энд не выглядит в соответствии со со спецификацией. Но вместо того, чтобы отвечать на последний билд разработчика «это не соответствует моему макету, вот макет в случае, если вы его потеряли» — будьте конкретными!
Дизайнеры натренированы замечать даже самые маленькие детали, которые большинство людей никогда не заметят. Разработчики не намеренно упускают детали — это просто не такой приоритет для них, как основная функциональность или создание кода без багов. Это работа дизайнера — замечать эти ошибки и указывать на них так конкретно, как это возможно, потому что человек, с которым вы работаете не был обучен искать эти типы деталей.
Подайте отчет о баге с скриншотами из живого демо и ваши макеты бок о бок. Прокомментируйте скриншоты детальными описаниями того, что требует изменения. Покажите и расскажите. Я обычно отправляю баг с прокомментироваными «до и после» скриншотами и суммирую то, что требует исправления, как маркированный список. Таким образом, оба, визуально и словесное, описания имеют формат для более быстрого и сознательного движения.
Я даже заходила так далеко, что отправляла улучшения взаимодействия отдельно от полировки визуально дизайна, потому что вы можете иметь разработчиков в вашей команде, которые сильнее в одной сфере или в другой — так что может быть проще разделить работу, если она разбита на эти категории. В целом, разработчики реагируют очень хорошо на списки улучшений, которые они могут методично продвигать и вычитать, когда они готовы. Это немного больше работы для меня, но более подходяще получать изменения с меньшим количеством беготни.
4. Реальные разговоры хороши, но они не могут отслеживаться
Многие дизайнеры из тех, что я знаю, предпочитают разрабатывать детали дизайна лично с менеджером продукта или разработчиком. Это чудесно и может помочь командной сплоченности, но побочный эффект от этого это то, что нет «бумажного следа» (протокола, записей — при. перевод.. Если вы не работаете в команде из двух (вы и ваш разработчик), все должно быть задокументировано для широкого доступа и реагирования команды.
Так что даже если у вас продуктивное личное обсуждение с вашим разработчиком о улучшениях в дизайне, вернитесь к вашему столу для немедленно суммируйте это в письме или отчете о баге. Это дает всей команде шанс среагировать и исполняет роль отчета о принятых решениях. Любое решение, которое не пришло с документированным обоснованием, доступно для изменения любому, когда вещи запутываются к концу.
5. Выпейте пива с вашим разработчиком
Никогда не недооценивайте силу социализации в членами команды. Познакомьтесь с ними и позвольте им узнать вас. Вы можете улучшить доверие и связь, если кто-то почувствует, что вы заботитесь о нем как о личности — а не просто набор навыков, на которые вы можете полагаться, чтобы осознать дизайнерское видение.
Разработчики! Вы же не думали, что вы так легко отделались? Со всеми вещами, которые дизайнеры могут сделать, чтобы облегчить вам жизнь, также есть несколько вещей, которые вы должны делать, чтобы создать лучшие отношения с дизайнерами.
1. Не давайте вашему первому ответу быть «нет»
Для дизайнера нет ничего более разочаровывающего, чем быть возбужденным из-за новой идеи, начинать обсуждать ее и затем быть прибитым к земле до того, как вы действительно объяснили потенциал!
Я обнаружила, что множество разработчиков (особенно те, с которыми я работала годами), обычно отвечают негативно на идеи дизайна и инновации, потому что они требуют «слишком много работы для чего-то, что не выглядит важным». Поверьте мне, дизайнеры понимают, что вы усиленно работаете, чтобы сделать что-то максимально жизнеспособное, что не сломается, если вы посмотрите на это косо.
Но есть причина, почему командам нужны и дизайнеры, и разработчики. Это наша работа — делать интуитивный, веселый и инновационный опыт, который люди полюбят использовать и будут возвращаться к нему. В противном случае, вся тяжела работа разработчика будет ничем.
Дизайнеры могут быть увлеченными весельем новых идей, но вместо того, чтобы говорить «нет» сразу, потратьте немного времени, чтобы понять, почему дизайнер так взволнован из-за этой идеи. Обсудите с ней или другим разработчиком способы добиться того же эффекта с меньшими расходами Если ваш дизайнер думает, что вы энергичный, открытый для новых идей и соглашений человек, вы наиболее вероятно получите ту иконку, которая вам нужна от них в 4 часа ночи в критическом положении.
2. «Fit and finish» — заморочки не разработчика
«Fit and finish» — термин, используемый в автомобильной промышленности. Он означает, что в машине все сделано без погрешностей и отклонений, что машина полностью готова — прим. перевод.
Разные дисциплины считают разные вещи крайне важными. Для отличного дизайнера, внимание к деталям и создание по-настоящему отполированного опыта первостепенно. Эти детали имеют значение, они могут быть трудноизлагаемыми, но обычно влияют на подсознательное отношение пользователя к продукту. Многие маленькие детальные ошибки могут накапливаться и создать ощущение, что продукт не профессиональный или не надежный. Наоборот, хорошо отполированное приложение может создать сильное эмоциональное впечатление, что приложение безупречно спроектировано, но имеет небрежный интерфейс.
Когда дизайнер просит разработчика подвинуть иконку на три пикселя влево или выравнять два блока текста по той же базовой линии, это изменение может показаться не важным, — но набор таких вещей может действительно сделать разницу.
3. Cделайте разбор полетов с вашим дизайнером перед запуском
Если ваш дизайнер старается с вами сотрудничать, не наказывайте его ставя перед фактом новой фичи, даже если вам кажется, что это незначительные изминения. Относитесь к вашему дизайнеру как вы бы относились к любому другому члену команды. Ваш дизайнер вовлечен в успех продукта так же, как и вся остальная команда.
Когда вы делаете разбор с вашим дизайнером, убедитесь, что вы даете ей время ответить, предложить изменения или повториться перед отправкой. Показывание дизайнеру проекта только как «к вашему сведению» — это так же плохо, как отправлять, вообще не показываю вашему дизайнеру.
Надеюсь мой опыт — и подход, который я разработала на протяжении последних лет поможет вам создать сильные альянсы между дизайнерами и разработчиками. Я верю, что в конце концов это приведет к созданию гораздо более мощных продуктов и лучшему пользовательскому опыту.
P. S. Приношу извинения. Действительно поторопился. Сколько не перечитывай, а…
Спасибо всем, кто присылал (и присылает) ошибки и опечатки.
Автор: charlag_khan
