Ускорение реализации прототипов
Как оптимизировать процесс проектирования интерфейсов, чтобы разработчики могли быстрее реализовать нарисованное?
Решение в лоб: разговаривать с разработчиками словами через рот (буквами через чат). Авось сами и расскажут, чего им не хватает и где жмет. Как частное решение — принимается. Но если попытаться чуть-чуть развить и обобщить, все становится не так однозначно.
Сами вы в вакууме!
Отдельно взятый разработчик в вакууме далеко не всегда заинтересован в скорости. Вместо ответа мы рискуем получить критику предложенных решений. Что поделать, все разбираются в политике и дизайне. Критика может быть и конструктивной, но, скорее всего, она будет не про скорость, а про качество.
Альтернатива — разрешить разработчику вносить мелкие изменения в решение дизайнера. Да что там «разрешить», на практике это встречается достаточно часто. Где-то очевидная ошибка, которую проще поправить, чем возвращать коллеге. Где-то надо логику поведения элемента додумать, потому что технические ограничения, дольше обсуждать.
Лазить руками в результат чужой работы в общем случае не зазорно (слышим крики негодования со всех сторон). Если руки мытые и есть голова на плечах, то это действительно может повлиять на скорость. Быстрее самому сделать, чем запускать процесс допилок и правочек. Но тут нужна страховка, чтобы не получилось письмо дяди Федора. И ей могла бы стать дизайн-система.
И хорошо, когда эта дизайн-система есть, но в общем случае она опять не про скорость! В общем случае скорость начинает расти тогда, когда дизайн-система уже реализована в коде. Прикручивание ее к конкретной платформе для конкретного проекта — само по себе проект и дополнительная нагрузка на разработку.
Понятно, что универсального решения для всех-всех-всех не будет. Придется не только поговорить через рот, а еще и вместе поработать над одной задачей и эмпирическим путем узнать, какие проблемы возникают у конкретных людей. Выделить среди них те, что про скорость, и затыкать их — инструментом, процессом, повышением компетенции людей или чем-то еще.
Как у людей
Совсем с нуля придумывать схему взаимодействия дизайна и разработки, конечно, не нужно. Можно подсмотреть, как это устроено у других. Ниже речь пойдет про Одну Большую Компанию, которую мы в силу NDA и прочих страшных букв назвать не можем. Вот как всё устроено.
- У дизайнеров есть кликабельный прототип. Заведомо неполный, потому что нет смысла исчерпывающе прорабатывать состояния экрана. На этапе проектирования еще неизвестно, пойдет ли конкретная фича в ближайший релиз или нет.
- У всех есть бэклог с юзерстори.
- Когда юзерстори попадает в релиз, соответствующий кусок прототипа прорабатывается уже детально. Дополняется всеми артефактами и состояниями. Прямо в JIRA загружаются иконки, скриншоты, ссылки на конкретные элементы.
- Разработчики разрабатывают. Естественно, появляются вопросы, вылезают ограничения. Что не получается сразу вместе разрулить, откладывается до следующего релиза (или убивается, как решит владелец продукта).
В изначальном прототипе все фичи проработаны только на бизнес-уровне, чтобы заказчик сказал «угу». Технические нюансы, обработка исключений, сопряжение фич с уже существующими — не проработаны. Заказчик это знает, но до момента оценки трудозатрат на очередной спринт его это не особо волнует.
А вот потом наступает самое интересное. Начинается дизайн-сопровождение релиза, которым занимается, внимание, бизнес-аналитик. Он сообщает разработчикам, как себя ведет каждая кнопочка, фишечка, плашечка, и вообще имеет полное право «колбасить мелочи по прототипу». Проектировщика к этому делу тоже привлекают, но только тогда, когда без него вообще никак.
Собрать прототип, протестировать, презентовать стейкхолдерам, передать в разработку, ответить на вопросы вида «а это что и как работает» — всем этим занимается бизнес-аналитик.
А чем занимаются проектировщики? Младшие создают сложные кликабельные прототипы, так как знают Axure или Sketch от и до. С адаптивом, загрузкой данных, свистульками… Старшие заботятся о паттернах поведения, изучают лучшие практики, ищут новые способы решения интерфейсных проблем, занимаются поддержкой и развитием дизайн-системы.
UX — про пользовательский опыт, бизнес-аналитика — про бизнес. Ну не чудо ли?
Когда подрядчик внешний
Если разработка случится когда-нибудь потом и чьими-нибудь силами, то особенно не разгуляешься. Все, что может сделать UX-подрядчик, — выдать документацию. Максимально подробную с учетом ограничений по времени и бюджету.
Если разработка вот-вот уже случится, то лучше заложить дизайн-сопровождение хотя бы в минимальном виде. Объем работы по сопровождению сильно зависит от разных факторов, но в любом случае это не драматически влияет на бюджет. Иногда и десяти часов не набирается.
Для водопадной команды — сессия вопросов и ответов, после того как разработчики прочитают ТЗ и потыкают в прототип. Для гибкой истории — несколько часов при планировании итерации и еще немного по ходу пьесы.
В любом случае — поговорить с заказчиком, что поможет ему максимально быстро превращать дизайнерские решения в код.
Это одна из публикаций по мотивам наших обсуждений в рабочем чате. Здесь нет готовых решений и однозначных выводов. Могут быть спорные тезисы и аргументы без пруфлинков. Абсолютно точно есть собственный опыт и, надеемся, полезные мысли для самостоятельного размышления.
