Три вещи, которые нужны продуктовым командам от дизайнеров

Аудио перевод статьи
0:00
0:00
Аудио перевод статьи
0:00
0:00
·

Сопоставление вариантов, которые предоставляет GOV.UK Notify командам для брендинга их электронных писем

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

Вот они:

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

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

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

Визуализировать идеи 

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

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

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

Эта работа имеет важное значение на двух уровнях:

  • Позволяет убедиться, что у всех в команде есть общее понимание идеи
  • Улучшает понимание командой проблемы: если ваша идея не решает проблему, значит, это что-то говорит о том, насколько хорошо вы понимаете проблему

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

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

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

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

Реализовать идеи 

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

Вот почему полезно хоть немного научиться программированию, а также знать как отправлять pull-запросы (pull-requests — запросы на включение сделанных вами изменений).

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

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

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

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

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

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

Заботиться о сохранении смысла

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

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

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

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

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

Итак, самый сложный, но самый важный вклад, который может сделать дизайнер, — это сохранить целостность продукта. Ян Богост говорит, что роль дизайнера заключается в том, чтобы “делать вещи еще более такими, какие они есть”.

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

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

Вы не можете делать все сразу

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

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

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

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

Источник:
designnotes.blog.gov.uk
·
comments powered by HyperComments