Дизайн в высоко-итеративной среде

У религий всегда есть ярые последователи, поэтому я не буду говорить об Agile с большой буквы, а то мало ли. Будем просто говорить об эджайле как о высоко-итеративной среде, где главная мера — работающий продукт.

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

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

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

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

Говоря иными словами, в то время как с тактикой ведения боя у команды все хорошо (эджайл, собсно), то со стратегией бывают проблемы, проколы, непонятки. Например, один из продуктов, над которым мы работаем уже третий год, до сих пор болтается в вакууме поиска product/market fit. Потому что со времени запуска куча всего поменялось на практическом уровне, но остановиться и осмыслить это, сделать какие-то выводы, почему-то не хватает времени. Все погружены в конверсии попапов, а вот для чего, зачем, что потом вообще делать с этой конверсией и так уж ли она нужна — никто не знает. Количество итераций никак не переходит в качество. Ведь нельзя останавливаться, у нас еще куча попапов не сделано.

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

В итоге прорабатывается не конкретный сценарий целиком, а лишь какая-то отдельная его часть, отдельный кейс, ну или просто нужен фейслифт. С точки зрения разработки продукта, опять же, подход наивернейший. Но необходимо иметь какую-то карту сценариев (user journey так называемый), чтобы понимать контекст происходящих изменений — ведь в системе каждое изменение неизбежно влечет за собой другие изменения, и если вовремя не понять или забить, то весь workflow рискует стать работой по латанию дыр.

Чтобы держать работу по проекту на плаву, моя дизайн-команда работает по принципу прошлое-настоящее-будущее. Вот прямо на три колонки расчерчиваю листик и пишу таски в соответствующие колонки.
Прошлое — это ревайз завершенных работ, запущенных в продакшен. Тут, конечно, коллективная лепта: трекер для багов открыт для всех))) В какие-то моменты — это самая обширная часть работы, в какие-то трекер, слава богу, молчит (ну да, не люблю я говно колупать, не люблю, что поделаешь).
Настоящее — проработка текущей итерации, грубо говоря — воплощение задумок в жизнь. А у нас все такие идейные..))
Будущее — это рисерч, проектирование и планирование работ. Моя отдушина.

Кстати, о практике. Одна из действительно крутых вещей в agile — возможность свести deliverables к минимуму. Особенно документацию. Ну надо заметить, что я люблю писать документацию, просто в таком workflow в ней просто нету надобности. Ну и дизайнерские макеты тоже сведены к минимуму, хотя, конечно, во многом это зависит от стиля работы команды и ее, так сказать, наполнения. В целом достаточно делать дизайн на lo-fi уровне, а корректировки на лету вносят фронтэндщики.

Это то, о чем так говорят последние пару лет — мол, дизайн-макеты как таковые умирают, и всем дизайнерам срочно нужно учиться кодить. Насчет умирают — не умрут, конечно, в ближайшее время по понятным причинам, но факт остается — для дизайн-работы над продуктом два главных инструмента — это листик-и-карандаш и фронтэндщик. А по поводу второго я просто кину вам цитатку as true as it can be.

When’s the right time for a designer to learn to code? Whenever you start feeling like not knowing how to code limits what you can achieve.

Sascha Greif

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

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

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