Не буду спорить, но если бы действительно было все так хорошо, то все не было бы так плохо. Боюсь, там слишком много маркетологов.

Но Вы только что сами говорили, что после дизайн-макета уже ничего не переделывается.

Верно, ибо это очень накладно, т.к. разработчики всегда забиты на 200%

Конечно если цифры показывают что что-то не так, то либо эксперимент сворачивается либо вносятся какие-то мелкие изменения на процент пользователей

В общем, мне не очень интересно, как построено проектирование интерфейсов в mail.ru. Ибо их интерфейсы говорят сами за себя, а значит там особо нечему учиться. Да и вы многое прояснили. Это у многих компаний крупных так. Тот же гугл в общем целом не блещет. Фасад еще ничего, а копнешь поглубже, в какие-нибудь настройки...

Не нужно сравнивать какие-то эксперименты, которые вы можете просто свернуть (наверно, по-этому разработчики так заняты) и наши проекты. Наш заказчик, знаете ли, не поймет, если мы свернем его проект.

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

В общем... не следует перекладывать схемы работы между совершенно разными бизнесами.

Согласен что эксперименты и пр. аналитика для конвеерной разработки (я этим термином определяю компании занимающиеся разработкой для третьих лиц) не применимы.

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

Как такового правила, ничего не переделывать нет, просто такие ситуации возникают крайне редко.

А заказчик платит за верстку прототипа?

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

Я правильно понимаю что прототип это внутрненняя разработка, которая не демонистрируется заказчику?

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