Дизайн в школе против дизайна в реальной жизни.

Как новый дизайнер UX прямо из школы, мое портфолио было заполнено красиво оформленными проектами (если можно так сказать), которые следовали одному и тому же линейному процессу. Я начал с исследования пользователей, идентифицировал персонажей, создавал идеальный и доступный дизайн взаимодействия с пикселями и проверял все свои решения, проводя тестирование удобства использования и дополнительные исследования пользователей. Я был вполне уверен, что прошел обучение, необходимое для того, чтобы стать младшим дизайнером в реальном мире. (Спасибо DesignLab!)

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

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

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

Когда вы устанавливаете хорошие рабочие отношения со своими инженерами, это золото.

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

Ответ на этот вопрос сводится к тому, что «время - деньги». Теоретически можно создать любую технологию, функцию или продукт, если бы у нас было бесконечное время и ресурсы. Мы могли бы спроектировать в вакууме, а затем попросить инженеров построить то, что мы хотим.

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

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

Участие в процессе

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

Это заняло некоторое время, но лучший способ, который я нашел для этого, - это заранее выяснить, где вы вписываетесь в процессы друг друга. Вы привлекаете инженеров к своему планированию? Вам следует! Потому что, опять же, все можно построить, но вопрос в том, какой ценой. Понимают ли они, почему вы приняли определенные дизайнерские решения? Им следует! Потому что тогда они будут уполномочены и мотивированы искать разумные решения. Объясняют ли они вам, почему они дали определенную оценку времени и усилий для конкретных функций? Им следует! Таким образом, вы можете решить, когда действовать, а где идти на компромисс. Привлекают ли они вас к производству продукта? Им следует! Вы должны следить за тем, чтобы товары, отправляемые людям, чувствовали себя и вели себя так, как вы планировали. Если вовлекать друг друга на ранней стадии и чаще, меньше сюрпризов, меньше конфликтов и, честно говоря… больше удовольствия! Крайне важно установить позитивные рабочие отношения с инженерами в вашей команде, чтобы создать лучший пользовательский интерфейс для людей, для которых вы разрабатываете.

жаргон

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

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

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

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

Слияние - после того, как код ветки был протестирован и проверен (см. PR / CR, тестирование и QA ниже), его можно «объединить в мастер», то есть добавить в код, который пользователь будет видеть внутри продукта. Новая версия приложения создается на основе этого нового мастер-кода и развертывается в производственной среде, то есть отправляется в мир для использования пользователями. Пользователи могут загрузить новую версию моего приложения для выпечки из App Store или Google Play и теперь могут выбирать из сотен вкусов, цветов и форм посыпки!

В моей команде в Nexar есть фраза, которая гласит: «Нет дизайнера - нет слияния». Инженеры должны показать дизайнеру новую функцию или функциональность, прежде чем она будет снова объединена с мастером, чтобы убедиться, что она соответствует тому опыту, который был разработан и определен.

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

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

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

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

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

PR / CR - после определения того, что их новый код работает правильно и готов к слиянию с мастером, инженер открывает запрос на вытягивание (PR) или проверку кода (CR). Посредством PR дополнительные инженеры в компании будут проверять код, чтобы убедиться, что он логичен, стилистически соответствует кодовой базе компании и соответствует требованиям будущего. У компаний и команд есть много разных протоколов для PR.

QA - на этапе обеспечения качества (QA) новая версия продукта тестируется, чтобы убедиться, что он ведет себя в соответствии со спецификациями группы разработчиков. QA не смотрит на сам код, а, скорее, проверяет то, что увидят пользователи. Контроль качества часто является последним этапом процесса перед объединением кода в мастер.

Инженерные спринты. Есть так много отличных статей о спринтах и ​​множество различных методологий спринтов. Вкратце, спринт - это ограниченный период времени, в течение которого выполняются определенные инженерные задачи, от планирования и написания кода до тестирования, PR, контроля качества и, наконец, развертывания новых функций или функций в продукте.

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

Спасибо Ади Розен, Чен Казаз и Шмуэль Ламм за их вклад в эту статью.