Как добиться успеха в качестве дизайнера в гибких командах: примите несовершенство

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

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

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

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

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

Вывод

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

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

Изображений

© Интерактивный дизайн Фонд, CC BY-SA 3.0