Два самых важных шага проектирования не связаны с дизайном

01.

Статья

Все мы знаем, что процесс проектирования может быть запутанным. И это нормально.

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

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

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

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

Бриф на дизайн — ваша ответственность

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

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

Не пропускайте такие формулировки:

Добавьте кнопку поиска в нижнюю панель, которая открывает новое окно, в котором пользователь может искать теги, пользователей и статьи.

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

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

Правильные входные данные избавят вас от стресса

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

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

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

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

От этого у меня внутри все теплеет

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

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

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

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

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

Заказчику понравился ваш новый дизайн. Можете ли вы внести в него несколько изменений и прислать мне эскизы? Они включают его в приложение.

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

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

Как я документирую дизайн

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

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

Для производственного дизайна я обычно разделяю форму и функцию на отдельные документы. В идеале спецификация формы должна представлять собой UI библиотеку, дизайн систему или другой тип репозитория на основе компонентов. Чистая форма и стандартизированные состояния и взаимодействия.

Google’s Material Design - одна из самых известных дизайн систем.

Функциональная документация объясняет всю логику, спецификации для функций, Customer Journey Map и пограничные состояния, а также требует специальных аннотаций. Для этой цели я предпочитаю менее строгий формат и обычно использую PDF-файлы, созданные в Keynote. Контроль версий и журналы изменений ведутся вручную. Вероятно, существуют инструменты, которые могут сделать этот шаг более эффективным, но пока я не нашел ничего другого, что давало бы мне свободу в макете и формате, которая обычно требуется для этого типа документации.

Функциональная спецификация UI в формате PDF.

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

Последний совет

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

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

Оригинал статьи uxdesign.cc
Перевод: Александр Лавренюк
Редактор: Валерия Жадан