Как дизайнеры, легко раздражаться на разработчиков. Возможно, они не могут правильно выровнять кнопку; или эта функция, которую вы сочли критически важной для вашего UX, просто находится слишком далеко в списке невыполненных работ для вашего комфорта.
Реальность такова, что нас раздражают разработчики в основном потому, что мы не понимаем их мир. То же самое касается и непонимания разработчиками дизайна — они тоже очень раздражаются на нас.
Я знаю это, потому что я занимал обе должности, потратив большую часть своей жизни на проектирование и разработку для Интернета.
Мы все в чем-то виноваты в этом. Как дизайнеры, мы надеваем наши шляпы с голубым небом и создаем дизайн в свое удовольствие, не задумываясь о технических последствиях.
Это не обязательно означает, что мы должны ограничивать себя; но это подчеркивает важность соблюдения рамок проекта и обеспечения согласованности в вашей команде.
С учетом сказанного, могут быть случаи, когда предоставленная вам область просто недостаточно детализирована. Вы начинаете изобретать функциональность или компоненты и часто можете продать это бизнесу без каких-либо технических консультаций. Это опасно и может легко привести к ползучести объема и конечному продукту, который задерживается или превышает бюджет.
Другой вероятный сценарий – это когда вы представляете шоу одного человека, проектируя в изоляции. Вы ожидаете, что плоские дизайны, которые вы передаете, будут идеальными в пикселях, но это вряд ли когда-либо бывает так. Ваш разработчик не заботится о пользовательском опыте — и это совершенно справедливо, потому что это не их работа.
К сожалению, многие компании недостаточно зрелы в своем подходе к проектированию, чтобы избежать подобных сценариев. Инженерные разговоры слишком часто наполнены жаргоном, который дизайнеры не понимают, что приводит к неоднозначным результатам. Проектирование также иногда включается в процесс, когда инженерные работы уже выполнены и когда практически невозможно внести какие-либо изменения в конструкцию.
Преодоление этого разрыва может потребовать от нас, дизайнеров, немного больше знаний о разработке.
Это не значит, что дизайнеры должны быть инженерами полного стека, но я твердо верю в то, что у меня есть базовое понимание некоторых технических концепций. Это уменьшит трения, поможет вашей команде производить лучшие продукты и, в конечном счете, сделает вас намного лучше в вашей работе. Данные и структуры данных
Данные являются краеугольным камнем любого приложения. Большинство приложений могут использовать так называемые операции CRUD: Создание, чтение, обновление и удаление. Эти операции используются для управления данными, но проблема в том, что функции или вызовы API должны быть написаны для каждой из этих операций, а часто и для каждого набора данных.
По мнению дизайнера, добавление изображения аватара в раздел профиля кажется простым делом. На самом деле, однако, разработчику необходимо написать полный набор операций CRUD для этого элемента дизайна. В дополнение к этому им необходимо написать код, чтобы связать этот аватар с вашим профилем, предоставить резервное изображение и управлять тем, где файлы хранятся на сервере. Это небольшое изменение дизайна могло занять у вас пять минут, но могло легко добавить день или два к спринту.
Существует также вторая часть этого: где хранятся фактические данные для этого изображения профиля. Обычно разработчики разрабатывают базы данных, которые легко масштабировать, но иногда мы можем вносить изменения в структуру, разрабатывая новые функции.
Я сам очень виноват в этом. Я разработал веб-приложение, которое позволяло вам находить специальные предложения на основе местоположения. После некоторых отзывов пользователей я понял, что нам не хватает очень важной функции: Настройка одной и той же акции для разных магазинов. Как дизайнеру, эту проблему было очень просто решить: мне просто нужно было добавить несколько кнопок в серверную часть и разделить один из процессов администрирования. Однако для разработчиков это был настоящий кошмар.
Реальность заключалась в том, что базу данных пришлось перепроектировать, а административные процессы перестроить — я не мог себе этого позволить, и мой проект вышел из бюджета и потерпел неудачу. Это было не потому, что разработчики не знали, что они делают, а потому, что я изменил область применения.
Важно, чтобы мы знали об ограничениях, когда дело доходит до проектирования базы данных приложения, а также кода, необходимого для чтения и записи этих данных. Подумайте о том, как части данных связаны друг с другом; и помните, что каждый фрагмент текста, который вы добавляете в свой дизайн, должен где-то находиться в таблице базы данных. Создание активов и производительность
Большинство разработчиков довольно серьезно относятся к производительности своих приложений — я сам одержим и считаю каждую миллисекунду, которую я сбриваю, достойной победы шампанским.
Производительность является ключом к хорошему пользовательскому опыту, а это значит, что производительность вашего продукта – это в такой же степени ваша работа, как и работа разработчика. Мы как дизайнеры несем ответственность за передачу ресурсов и прототипов, учитывающих производительность приложения, и это возможно только при глубоком понимании технологии, для которой вы разрабатываете.
Изображения – это один из видов активов, который многие дизайнеры не передают должным образом. Может возникнуть соблазн увеличить этот ползунок качества до 12 при сохранении JPG, но в конце концов ваши пользователи пострадают из-за этого. Например, большинство тем WordPress не изменяют размер изображений при загрузке или использовании их в производстве. Да, вы можете решить эту проблему с помощью одного или двух плагинов, но почему бы просто не сохранить его правильно с самого начала?
Есть несколько очень полезных инструментов для тестирования размеров изображений (а такие сервисы, как Google PageSpeed Insights, даже предлагают сжатие). Запустите свой живой сайт с помощью этих инструментов и предоставьте разработчикам соответствующие сжатые изображения.
Еще одно соображение – SEO. Что-то простое, например, семантическое присвоение имени вашему файлу, может оказать огромное влияние на рейтинг поиска вашего проекта. Может показаться нелепым называть это миниатюрой’a-photo-of-an-apple-on-a-cutting-board.jpg “но Google на самом деле читает эти метаданные.
Наконец, это применимо не только к изображениям, но и к видео. Предложите сторонний сервис, такой как YouTube или Vimeo – ваши разработчики будут любить вас за это, так как он выполняет всю тяжелую работу за них.
No, I can't improve the performance of your full page transition on IE6.
Еще одна вещь, в которой мы виноваты, – это чрезмерная анимация. Конечно, этот переход может показаться плавным и сексуальным на вашем iMac Pro, но как насчет остальной части вашей аудитории, которая может использовать старые ноутбуки? То же самое относится и к другим устройствам, таким как мобильные телефоны или старые планшеты.
Анимация может сильно усложнить код, так как разработчикам может потребоваться реализовать дополнительные библиотеки для его выполнения. Кроме того, это может добавить ненужный объем — например, для расширенной анимации формы потребуется HTML-холст, который часто является навыком специалиста.
Важно, чтобы анимация была продуманной и содержательной. Это гарантирует, что разработчики реализуют только ту анимацию, которая соответствует опыту вашего конечного пользователя.
Вы можете прочитать больше о создании значимой анимации здесь или прочитать больше об анализе производительности здесь. Техническое исполнение
Когда я ношу шляпу разработчика, я иногда получаю проекты, которые трудно реализовать; и это часто происходит потому, что дизайнер не до конца понимает, что связано с реализацией. CSS и JavaScript, например, имеют свои ограничения — есть только некоторые собственные мобильные функции, которые нельзя использовать для Интернета. Затем нам также необходимо рассмотреть такие вещи, как поддержка браузеров, а также усилия, необходимые для обеспечения совместимости дизайна с другими браузерами.
С учетом сказанного, большинство проектов являются исполняемыми, речь идет просто о поиске компромисса между областью применения и тем, что лучше для пользователя. Глубокое понимание CSS и Интернета поможет этому процессу и уменьшит трения между вами и вашими разработчиками.
Убедитесь, что ваш процесс является гибким по своей природе — регулярно регистрируйтесь у разработчика, чтобы подтвердить, что ваш проект является исполняемым и находится в пределах области действия. Создание быстрых прототипов – отличный способ продемонстрировать свое мышление, и часто ваши разработчики могут использовать его для создания собственных прототипов. Это отлично подходит для совместной работы и позволит избежать этих ошибок в дизайне.
Наконец, никогда не показывайте окончательные проекты клиенту, не убедившись, что они являются исполняемыми и находятся в рамках вашего проекта. Фреймворки или библиотеки CSS и JavaScript
Bootstrap стал поворотным моментом для многих веб-профессионалов. Это позволяло разработчикам создавать веб-сайты без дизайнеров и позволяло дизайнерам разрабатывать на языке, понятном разработчикам. В некотором смысле Bootstrap был одной из первых систем проектирования для Интернета и позволил улучшить сотрудничество между командами.
Bootstrap использует концепцию, называемую предварительной обработкой CSS. Это позволяет разработчикам разделять стили пользовательского интерфейса для разных компонентов в своих собственных файлах. Это также позволяет им абстрагировать определенные свойства как переменные, особенно если они многократно используются в нескольких компонентах.
React, Vue и Angular (все фреймворки/библиотеки JavaScript) используют очень похожие методологии. Эти управляемые данными одностраничные прикладные инструменты позволили разработчикам создавать масштабируемые веб-приложения, которые являются очень модульными по своей природе. Компоненты разделены на свои собственные функциональные файлы и часто также содержат стиль (CSS).
Понимание этой концепции разделения задач позволяет дизайнерам абстрагировать свою дизайнерскую работу в маркеры дизайна, что создает общий язык, понятный как дизайнерам, так и разработчикам.
Этот общий язык является мощным инструментом, который исключает жаргон из разговора. Это позволяет дизайнерам участвовать в определении масштаба проекта и планировании спринта. Между вами и вашим разработчиком не возникнет никаких сомнений, когда вы попросите их изменить кнопку с “маленькой” на “большую” в качестве компонента и это соответствующий стиль, абстрагированный. В конечном счете это может привести к созданию системы проектирования, которая позволит развертывать дизайн в масштабе. Заключить
Я не говорю, что дизайнеры должны быть хардкорными разработчиками, но небольшое понимание имеет большое значение. Учитесь у разработчиков и помогайте им учиться у вас, чтобы мы все могли создавать лучшие продукты.
Оригинал: “https://dev.to/aryasoni98/why-designers-should-understand-how-developers-work-26h6”