Ускорение реализации прототипов

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

Альтернатива — разрешить разработчику вносить мелкие изменения в решение дизайнера. Да что там «разрешить», на практике это встречается достаточно часто. Где-то очевидная ошибка, которую проще поправить, чем возвращать коллеге. Где-то надо логику поведения элемента додумать, потому что технические ограничения, дольше обсуждать.

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

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

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

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

1. У дизайнеров есть кликабельный прототип. Заведомо неполный, потому что нет смысла исчерпывающе прорабатывать состояния экрана. На этапе проектирования еще неизвестно, пойдет ли конкретная фича в ближайший релиз или нет.

2. У всех есть бэклог с юзерстори.

3. Когда юзерстори попадает в релиз, соответствующий кусок прототипа прорабатывается уже детально. Дополняется всеми артефактами и состояниями. Прямо в JIRA загружаются иконки, скриншоты, ссылки на конкретные элементы.

4. Разработчики разрабатывают. Естественно, появляются вопросы, вылезают ограничения. Что не получается сразу вместе разрулить, откладывается до следующего релиза (или убивается, как решит владелец продукта).

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

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

Собрать прототип, протестировать, презентовать стейкхолдерам, передать в разработку, ответить на вопросы вида «а это что и как работает» — всем этим занимается бизнес-аналитик.

А чем занимаются проектировщики? Младшие создают сложные кликабельные прототипы, так как знают Axure или Sketch от и до. С адаптивом, загрузкой данных, свистульками… Старшие заботятся о паттернах поведения, изучают лучшие практики, ищут новые способы решения интерфейсных проблем, занимаются поддержкой и развитием дизайн-системы.

UX — про пользовательский опыт, бизнес-аналитика — про бизнес. Ну не чудо ли?

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

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

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

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