Аннотации к дизайну сделают ваших разработчиков счастливее

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

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

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

Аннотации к дизайну — краткие письменные пояснения, предоставляемые с результатами дизайна, чтобы определить и описать аспекты проекта, — Дэн Лачапель в «Основах Дизайна: Составление аннотаций к своей работе«.

Зачем делать аннотации?

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

Аннотации на экране входа

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

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

Аннотация к дизайну в сравнении с документацией

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

Когда давать аннотации?

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

1. Отображение ошибок и пограничных случаев
2. Описание закадровых процессов
3. Приведение доводов для такого дизайна
4. Отслеживание изменений и решений

1. Отображение ошибок и пограничных случаев

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

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

Включение и выключение состояния ошибки с помощью аннотации

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

2. Описание закадровых процессов

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

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

Ссылка на проектную документацию с помощью аннотации

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

3. Приведение доводов для такого дизайна

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

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

Проведение обоснования дизайна в аннотации

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

4. Отслеживание изменений и решений

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

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

Отметка об изменении даты в аннотации к дизайну

Давайте делать аннотации к дизайну!

Как давать аннотации?

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

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

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

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

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

Розовая кнопка переключения

Системы дизайна упрощают это

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

Аннотации это мелочи

Аннотации могут помочь, но они не могут объяснить все. Они могут охватывать детали, но общая картина часто заключается в проектной документации. Хотя я использую аннотации, чтобы вспомнить детали, я полагаюсь на указания по разработке дизайна, чтобы охватить весь контекст.

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

Источник