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

05.05.2020
Posted in blog-article
05.05.2020 admin

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

Мастрид для всех дизайнеров 📚

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

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

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

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

Почему?

Аннотации к дизайну, которые сделают ваших разработчиков счастливыми, изображение №2

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

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

Аннотация vs документация

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

Когда?

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

  • Отображение ошибок и пограничного состояния
  • Описание внеэкранного опыта
  • Обоснование для дизайна
  • Отслеживание изменений и решений

1. Показ ошибок и пограничного состояния

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

Аннотации к дизайну, которые сделают ваших разработчиков счастливыми, изображение №3

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

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

2. Описание внеэкранного опыта

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

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

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

3. Обоснования для дизайна

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

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

Аннотации к дизайну, которые сделают ваших разработчиков счастливыми, изображение №4

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

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

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

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

Аннотации к дизайну, которые сделают ваших разработчиков счастливыми, изображение №5

Давайте аннотировать!

Как аннотировать?

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

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

Введение в аннотационную систему

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

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

Системы дизайна облегчают ваш труд

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

Аннотации заботятся о мелочах

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Contact

Давайте работать вместе!

Пишите нам и найдем точки соприкосновения, может станем партнерами, а может поможем вам зайти в нашу чудесную нишу

Вы разработчик?

Пишите! Нам постоянно нужны новые кадры, либо можем помочь в продвижении вашего приложения

Новичок?

Поможем быстро войти в нишу, не тратя годы на понимание

Давно в нише?

Рады будем пообщаться как на темы whitehat, так и blackhat тематики ^_^ + всегда есть что обсудить по поводу рекламных сетей

ПИШИ В TELEGRAM!

Contact