Как разработчики интерфейса могут расширить возможности дизайнеров

Эта статья в основном адресована вам, уважаемый Frontend-разработчик, которому нравится реализовывать пользовательские интерфейсы, но трудно согласовать ожидания с дизайнерами, с которыми вы работаете. Возможно, вас называют «разработчик пользовательского интерфейса» или «инженер UX». Независимо от названия, которое вы носите с собой, ваша работа (как и моя) состоит не только в том, чтобы вдохнуть жизнь в файлы дизайна. Мы также несем ответственность за заполнение пробела между рабочими процессами проектирования и разработки . Однако, переходя этот мост, мы сталкиваемся с множеством проблем.

Сегодня я хотел бы поделиться с вами практическими советами, которые помогли мне более эффективно сотрудничать с дизайнерами в последние годы.

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

Понимание опыта UX-дизайнеров

Большинство UX-дизайнеров (также называемых веб-дизайнерами или дизайнерами продуктов) сделали свои первые шаги в мире дизайна с помощью таких инструментов, как Photoshop и Illustrator. Возможно, они были графическими дизайнерами : их основной целью было создание логотипов и фирменного стиля, а также дизайн макетов для журналов. Они также могли бы быть дизайнерами по маркетингу : печатать рекламные щиты, разрабатывать баннеры и создавать инфографику.

Это означает, что большинство UX-дизайнеров посвятили свои первые дни дизайну для печати, что является совершенно иной парадигмой, чем их нынешний носитель — экран. Это был их первый большой вызов. При работе с печатью дизайнеры заботились о выравнивании пикселей, но на фиксированной области (бумаге). Им не нужно было бороться с динамической компоновкой (экранами). Думать о разрыве текста или состояниях взаимодействия просто не входило в их работу. Дизайнеры также имели полную свободу выбора цветов, изображений и типографики без ограничений производительности.

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

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

Принятие нового образа мышления

Веб-сайты и приложения, которые мы создаем, будут отображаться на экранах самых разных размеров. Каждый человек будет использовать их на нескольких устройствах. Наша общая цель — создать знакомый опыт во время их путешествий.

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

Примечание . Существует онлайн-курс под названием «Дизайн для разработчиков» и книга под названием «Рефакторинг пользовательского интерфейса» — оба отлично подходят для начала. С их помощью вы сможете реализовывать пользовательские интерфейсы с вниманием к деталям и получать значительные преимущества при общении с дизайнерами.

Повышение осведомленности ваших дизайнеров

Вы можете считать само собой разумеющимся, что дизайнеры знают Интернет так же хорошо, как и вы. Ну может и нет. На самом деле, они не должны! Мы, как разработчики, обязаны держать их в курсе текущего состояния Интернета.

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

Научите их коду, а не тому, как кодировать

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

Сядьте рядом с дизайнером, с которым вы работаете, на 15 минут и научите его, как он может сам убедиться в правильности спецификаций элемента и как их изменить. Я нахожу Firefox Page Inspector удивительно удобным для этого.

В настоящее время визуализировать макеты, отлаживать анимацию CSS и настраивать типографику — одно удовольствие. Покажите им готовую к использованию игровую площадку для кода, такую ​​как Codepen, чтобы они могли изучить ее. Им не нужно знать все спецификации CSS, чтобы понять, как работает парадигма макета. Однако им необходимо знать, как элементы создаются и ведут себя, чтобы расширить возможности своей повседневной работы.

Включите дизайнеров в процесс разработки

Пригласите дизайнеров присоединиться к вам на стендап-совещании, принять участие в процессе контроля качества и посидеть с вами, пока вы уточняете визуальные детали своих реализаций. Это заставит их понять ограничения сети, и достаточно скоро они поймут, почему для реализации функции требуется время.

Попросите дизайнеров включить вас в их процесс проектирования

Вы поймете, что они делают гораздо больше, чем «делают вещи красивыми». Вы узнаете больше о процессе исследования и о том, как проводится пользовательское тестирование. Вы обнаружите, что для каждого дизайнерского предложения, которое они вам показывают, несколько других исследований ранее были исключены. Когда дизайнеры запрашивают изменение, спросите о причине этого, чтобы вы могли больше узнать о принимаемых решениях . В конце концов, вы начнете понимать, почему они придирчивы к пустому пространству и выравниванию, и, надеюсь, скоро вы тоже это поймете!

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

Мы можем использовать разные инструменты, но мы должны говорить на одном языке

Теперь, когда мы начинаем немного лучше понимать рабочий процесс друг друга, пришло время для следующего шага: говорить на одном языке.

Взгляд за пределы редактора кода

Как только вы начнете обращать внимание на свое окружение, вы будете лучше подготовлены к решению проблем. Познакомьтесь с бизнесом поближе и будьте готовы слушать, что говорят дизайнеры. Это сделает вас членом команды с большим вкладом в проект. Сотрудничество в областях, выходящих за рамки нашей компетенции, является ключом к созданию конструктивных разговоров и взаимному доверию.

Использование систем пользовательского интерфейса в качестве контракта

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

Возможно, вы уже знакомы с концепцией на основе компонентов. Однако некоторые дизайнеры могут воспринимать это не так, как вы. Покажите им, как компоненты могут помочь вам создавать пользовательские интерфейсы более эффективно. Распространите это мышление, а также попрощайтесь с похожими, но не одинаковыми именами: заголовок против героя, информация о ценах против селектора цен . Когда часть пользовательского интерфейса (также известная как «компонент») создается, постарайтесь использовать те же имена , чтобы они могли быть отражены как в файлах дизайна, так и в файлах кода. Затем, когда кто-то говорит: «Нам нужно настроить виджет приглашения предложения», все точно знают, о чем идет речь.

Признание реального источника истины

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

Держите долг под контролем

Итак, вы знаете все о техническом долге — это происходит, когда стоимость реализации чего-то нового высока из-за того, что мы использовали ярлык в прошлом, чтобы уложиться в срок. То же самое может произойти и с дизайном, и мы называем это дизайн-долгом .

Вы можете думать об этом так: чем выше несогласованность UX и UI, тем выше долг (технический и дизайнерский). Одно из наиболее распространенных несоответствий заключается в наличии разных элементов для представления одного и того же действия. Вот почему плохой дизайн обычно отражается в плохом коде . Все мы, как дизайнеры, так и разработчики, должны серьезно относиться к своему дизайн-долгу.

Доступность не означает, что она должна быть уродливой

Я очень рад видеть, что мы оба, как разработчики и дизайнеры, наконец начинаем привносить доступность в нашу работу. Тем не менее, многие из нас по-прежнему думают, что разработка доступных продуктов сложна или ограничивает наши навыки и творческий потенциал.

Напомню, что мы не создаем продукт только для себя. Мы создаем продукт, которым будут пользоваться все люди , включая тех, кто использует продукт иначе, чем вы. Примите во внимание, как отдельные элементы могут быть более доступными, сохраняя при этом ясность и согласованность текущих пользовательских процессов.

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

Предоставление ценных отзывов дизайнерам

Неизбежно, что вопросы будут появляться при просмотре дизайна. Однако это не повод начинать жаловаться на ошибки дизайнеров или на их амбициозные идеи. Дизайнеры здесь не для того, чтобы сводить вас с ума, они просто не всегда интуитивно знают, что вам нужно для выполнения своей работы. Правда в том, что в прошлом вы тоже не знали об этом, так что наберитесь терпения и используйте сотрудничество как способ обучения.

Чем раньше обратная связь, тем лучше

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

Объясните абстрактные идеи простыми словами

Помните, я сказал, что производительность не была проблемой на предыдущих работах дизайнеров? Не волнуйтесь, если они не знают, как создавать оптимизированные SVG для Интернета. Столкнувшись с дизайном, который требует загрузки большого количества разных шрифтов, объясните им, почему мы должны свести к минимуму количество запросов, возможно, даже использовать преимущества переменных шрифтов. Помимо более быстрой загрузки, он также обеспечивает более стабильный пользовательский интерфейс. Если дизайнеры не стремятся учиться, избегайте использования слишком большого количества технических терминов при объяснении чего-либо. Вы можете рассматривать это как возможность улучшить свои навыки общения и прояснить свои мысли.

Не позволяйте предположениям превращаться в решения

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

Не делайте обходные пути самостоятельно

Когда вас просят реализовать слишком сложный дизайн, не говорите «это невозможно» и не начинайте самостоятельно реализовывать его дешевую альтернативную версию. Это немедленно вызывает трения с командой дизайнеров, когда они видят, что их проекты не были реализованы должным образом. Они могут отреагировать гневно или ничего не сказать, но чувствовать себя побежденными или разочарованными. Всего этого можно избежать, если мы объясним им, почему что-то не получается, простыми словами и предложим альтернативные подходы. Избегайте догматического поведения и будьте открыты для совместной работы над новым решением .

Сообщите им о методах Graceful Degradation и Progressive Enhancement и создайте вместе идеальное решение и резервное решение. Например, мы можем улучшить макет с flexbox на CSS Grid. Это позволяет нам уважать основную цель функции и в то же время наилучшим образом использовать веб-технологии.

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

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

Мыслить за пределами идеального государства — вместе

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

Чтобы избежать этих пробелов, согласуйте с дизайнерами требования сценария:

• Худший сценарий
  Сценарий, в котором происходят худшие возможности. Это помогает дизайнерам отказаться от фиксированного контента и позволить ему быть изменчивым. Что произойдет, если заголовок содержит более 60 символов или если список слишком длинный? То же самое относится и к противоположному, пустому сценарию. Что делать пользователю, когда список пуст?
• Состояния взаимодействия
  Браузер — это больше, чем просто зависание и кликание. Есть куча состояний: по умолчанию, наведение, фокус, активно, отключено, ошибка… и некоторые из них могут происходить одновременно. Давайте уделим им должное внимание.
• Состояние загрузки
  Создавая что-то локально, мы можем использовать моки и забыть, что на самом деле для загрузки требуется время. Сообщите дизайнерам об этой возможности и покажите им, как заставить людей понять, что загрузка не занимает много времени.

Принимая во внимание все эти сценарии, вы сэкономите много времени на переходах туда и обратно на этапе разработки.

Примечание . Скотт Херфф написал отличную статью о том, как исправить плохие пользовательские интерфейсы, которые сделают нас на шаг ближе к доступному продукту.

Принимайте запросы на изменение

Разработчики известны тем, что не слишком радуются тому, что кто-то находит ошибку в их коде, особенно когда это ошибка дизайна, о которой сообщил дизайнер. Вокруг этого много мемов, но задумывались ли вы когда-нибудь о том, как эти ошибки могут усугубить как качество опыта, так и ваши отношения, когда эти ошибки дизайна небрежно игнорируются? Это происходит медленно, почти как засыпание. Понемногу, а потом все сразу. Дизайнеры могут начать говорить: « Это всего лишь крошечная деталь», пока не нарастают безразличие и обида и ничего не говорят. Тогда ущерб уже нанесен.

Эта ситуация двояка: и для ваших сверстников, и для вашей работы. Не позволяйте этому случиться. Работайте над тем, что окрашивает вашу реакцию. Быть «придирчивым» дизайнера может быть неудобно, но это также может быть поверхностной интерпретацией инженером внимательности и энтузиазма. Когда кто-то говорит вам, что ваша реализация не идеальна (пока), отбросьте свое эго и покажите им, как вы признаете их тяжелую работу по совершенствованию конечного результата.

Время от времени отключайтесь от записи

У всех нас есть задачи, которые нужно выполнить, и планы, которые необходимо завершить. Тем не менее, некоторые из лучших работ происходят неофициально. Он не будет зарегистрирован на доске TO DO , и это нормально. Если вы найдете дизайнера, с которым у вас хорошие отношения, прокрадитесь в его рабочее пространство и вместе исследуйте новые эксперименты. Мало ли что оттуда может выйти!

Заключение

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

Эта статья была бы невозможна без отзывов многих замечательных людей. Я хочу поблагодарить дизайнеров Жасмин Мейер и Маргариду Ботельо за то, что они помогли мне поделиться сбалансированным взглядом на недопонимание между дизайнерами и разработчиками.

Связанное Чтение на SmashingMag:

• «Дизайн для разработчиков», Мэйсон Джентри
• «Работаем вместе: как дизайнеры и разработчики могут общаться, чтобы создавать лучшие проекты», Рэйчел Эндрю
• «Как Frontend-разработчики могут помочь преодолеть разрыв между дизайнерами и разработчиками», Стефан Калтенеггер
• «Какие подкасты стоит слушать веб-дизайнерам и разработчикам?» Рики Онсман