Хотя, мне кажется это применимо не только в случае, если нет респондентов. Респонденты - это информация из “первых рук”. В вашем случае их заменяет группа мозгового штурма. Все остальные процедуры (структурирование сценариев, их пополнение и ранжирование) тоже имеют место быть в “обычном”, скажем так, проекте.

> конкретно мыслить всегда гораздо проще (=быстрее) и более естественно для людей.
Думаю, что это индивидуально. Лично мне привычнее размышлять на высоких уровнях абстракции (формализуя эти размышления в документе об образе и границах проекта), а потому уже постепенно спускаться к деталям (user stories, use case, usage scenarios, wireframes), оглядываясь на рамки, зафиксированные ранее (которые, естественно можно раздвинуть при необходимости).

> Если мыслить сразу абстрактно, то имеется большой риск улететь совсем в иные дали и размыть представление о продукте (отрываемся от конкретной деятельности).
Для того, чтобы не забыть о рамках можно использовать изначально формализованное представление об образе и границах продукта, которое, на мой взгляд должно создаваться в первую очередь (по крайней мере для того, чтобы оценить целесообразность, необходимые ресурсы и риски).

P.S. Ещё мне не совсем понятна терминология, то что вы назвали “сценариями” очень похоже на use case, в процессе первого прочтения я даже хотел предложить заменить представленные на рисунках “Деревья” на UML-диаграммы прецедентов.

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