Как сократить количество исправлений дизайна на этапе разработки: наш опыт
Команды разработки зачастую сталкиваются с проблемой, когда приложение необходимо возвращать на этап проектирования UI и UX — пользовательского интерфейса и опыта. Мы в red_mad_robot не стали исключением — иногда внезапные и срочные «переделки» интерфейсов сильно задерживают и удорожают процесс разработки продукта.
Отличная исчерпывающая статья на тему краевых сценариев, но от заголовка ожидала более широкого взгляда на проблему. Возвраты задачи в дизайн на этапе разработки не всегда связаны с непродуманностью краевых сценариев, есть еще масса причин, часто дизайнеры отложив работу на какое-то время, начинают смотреть на нее новым взглядом, возникают улучшения, появляются изменения в макетах, и хорошо если о них предупреждают разработку:)
В статье упоминаются только кейсы из мира кровавого энтерпрайз и подход api-first, то есть проектирование интерфейса основано на заранее известном контракте между фронтом и бэком. Есть еще мир стартапов, в котором чаще встречается подход design-first, когда техническое решение выбирается исходя из требований UX. И там есть свои нюансы.