Елена!
Как разработчик, я перехватил ваш вопрос у Николая, чтобы ответ был из первых рук.
Чтобы не терять время, пока не готовы макеты, разработчики собирают прототип с теми стилями и дизайном, что есть, либо вообще без них. Чтобы разработчики могли собрать прототип, им нужно понимать задачу: что мы пытаемся сделать, в чём полезное действие, как выглядит идеальное решение, какие ключевые «двигающиеся» части решения. На эти вопросы отвечает понимание задачи — документ, который пишут дизайнеры ещё до дизайна.
Покажу на примерах, как связаны понимание задачи и прототипы:
В издательстве бюро
В понимании задачи: облачный редактор книг (Карандашик) убирает технический барьер, стоящий перед авторами книг, перенося редактирование исходного кода книг из Гита и текстового редактора в браузер.
Прототип: готовый редактор кода (CodeMirror) разворота в браузере, автоматически сохраняющий изменения по мере ввода.
В лекциях бюро
В понимании задачи: дать студентам возможность получить знания, собранные бюро, но дешевле, без геморроя и в своём режиме (at your own pace), предложив им новый продукт «Лекции».
Прототип: голая страница лекции с дефолтными стилями и кнопкой «Купить», ведущей в «Учебный кабинет» со списком документов, разбитых по главам.
В издательстве бюро
В понимании задачи: помочь людям тренировать переговорные навыки на разных кейсах, отработать кемповские приёмы без социального давления и страха ошибки. Для этого сделать интерактивную книгу‑тренажёр на движке издательства бюро.
Прототип: переговорный виджет, использующий стили «балунов» из другой книги издательства бюро без анимаций и интерактива.
В советах
В понимании задачи: обеспечить быструю модерацию и публикацию свежих комментариев, снять с советчиков нагрузку по модерации комментариев. Решение: пригласить модерировать комментарии избранных членов Клуба уважаемых советчиков, рассказать им о правилах модерации.
Прототип: голый список комментариев к совету с кнопками «Разрешить» и «Утопить».
Иногда имеет смысл начать собирать бэкенд до дизайна. Часто в таких случаях польза в разведке: становится понятно, какие есть ограничения и упущенные сценарии, как они повлияют на дизайн, что придётся пофлексить. Такой же подход работает в приложениях и фичах, в которых большая часть работы приходится на бэкенд, а интерфейс — просто вишенка на торте из сложнейших алгоритмов и высшей математики.
В школе бюро
Когда обновляли учебный кабинет, разработку начали со спецификации и бэкенда. Оказалось, что бэкенд тестов должен поддерживать такое количество сценариев, что для его разработки не хватит и шести недель. Решили пофлексить тесты, скрутив старую их версию с новым движком, и выделить их переделку в отдельную итерацию.
В билингах бюро
В каждом продукте бюро есть свой билинг, отвечающий за продажи и автосписания. Когда разрабатывали билинг издательства начали с бэкенда — билинга и автосписаний. Прототип не имел дизайна и интерфейса: билинг списывал деньги в «песочнице» и писал в лог. Когда дизайн был готов, за неделю вкрутили все необходимые письма и подтверждения в билинг.
В издательстве бюро
Когда разрабатывали бэкенд прототипа облачного редактора книг, поняли, что с такой архитектурой легко делать превьюшки отдельных разворотов. Учли это в дизайне, добавив в правый верхний угол «живую» превьюшку разворота, ведущую на соответствующий разворот в книге:
P. S. Интересный момент. План в книге, видимо, из старых времён, когда дизайнеры бюро не просили разработчиков писать спецификации — программистский вариант понимания задачи — до начала разработки. Но даже в этом случае подход остаётся тем же: параллельно со спецификацией разработчики собирают бэкенд и обновляют спецификацию с учётом того, что разведали.