Программист и дизайнер: 4 секрета крепкого “брака” от сооснователя Preply.com

О том, как избежать сложностей в рабочей коммуникации между представителями “творческого” и “прикладного” миров, DesignTalk.club рассказал Сергей Лукьянов, сооснователь и designer известного международного маркетплейса для поиска репетиторов Preply.com.

serge-lukyanov-product-design

Вот уже четвертый год я работаю в качестве дизайнера над образовательным проектом Preply.com в команде лучших профессионалов. Вместе мы преодолевали первые сложности, меняли прототип продукта, где-то теряли деньги, затем их привлекали. Костяк команды Preply построен по принципу 3H: Hustler (маркетолог и человек-оркестр Кирилл Бигай), Hacker (программист Дмитрий Волошин) и Hipster (дизайнер, то есть я). Последние два – диаметрально разные специализации, которые объединила вера в проект и его будущее. Делюсь лайфхаками о том, как дизайнеру общаться с программистом во благо общего проекта.

Будьте готовы к «трудностям перевода» – куда же без них. Что дизайнеру кажется «проще простого, легче легкого», на деле программиста оказывается не таким уж и очевидным и быстрым процессом. Признаться, мы, дизайнеры, часто придумываем “космические корабли”, на построение которых программистам нужно жизнь положить, чтобы довести продукт до необходимого вида. “Вот тут всего лишь так сделать” – это “всего лишь” не всегда подразумевает пустяковую задачу. Консенсус, иногда компромисс внутри команды всегда лежат в основе успешного бизнеса. Для того – дизайнер и программист внутри проекта должны быть друзьями, коллегами, заинтересованными в сотрудничестве, а не конфликтующими сторонами. Не стоит думать, что вы по разные стороны баррикад: ищите общие точки соприкосновения, интересуйтесь. Например, программист может научить дизайнера возможностям различных технологий, дизайнер программиста – хорошему тону поведения интерфейсов, внимательности к внешним деталям.

Уважайте личное время и пространство друг друга. Наверняка с каждым случалась ситуация, когда во время максимальной озадаченности к вам внезапно подходил человек, задавал какой-то банальный вопрос вроде «а ты не видел переходник?» и точно также внезапно уходил, оставляя за собой сбитую мысль и растерянность. Конечно, все это он делал не специально, но, как говорится, «осадочек остался», в данном случае профессиональный. Научно доказано, что после отвлечения программиста ему необходимо около 15 минут, чтобы вернуться в контекст своей задачи.

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

Приучите себя к тому, что у каждого свой стиль работы.  Когда-то я общался об этом со своим знакомым программистом из Google, и мы пришли к тому, что если сравнить работу дизайнера и программиста с пылесосом, то программист тщательно пылесосит сантиметр за сантиметром и, как правило, не возвращается к тем местам, где он уже прошелся. Дизайнер же пылесосит гораздо хаотичнее, набрасывая общую картину, а затем подбирая мелкие детали – в рунете такой стиль встречается как метод прогрессивного джипега. Не стоит забывать, что дизайнер и программист – это “персонажи” из двух совершенно разных миров.

Избегайте принципа «у каждого своя песочница», который грозит безразличием участников к конечному результату рабочих процессов. Дизайнер может молиться на свои красивые макеты из сказочного мира, но обязан возвращаться в реальность, беспокоясь о том, что получится на выходе и как помочь программисту довести результат до ума. Программист имеет право гордиться своим умным невидимым алгоритмом, но должен заботиться и о видимой части продукта – именно с ней взаимодействуют пользователи.

385603686

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

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

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

Позначки:

Залишити відповідь