Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.

Пусть попробует структурные карты Константайна

Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.
Начал изучать Фаулера и как он пишет, что в основном применял uml для создания эскизов. Надеюсь это что-то подходящее.

А разработчики будут при этом пользоваться диаграммами?

Или для них нужна другая форма представления?

Любая крайность - губительна.

Если вы работаете по модели Agile, то и хранение знаний (требований) выстраивайте по этой модели.

Диаграммы могут дополнять текстовое описание, но чтобы его полностью его заменить - необходимы колоссальные усилия по их созданию и поддержке, которые в итоге никак не окупятся.

Используйте диаграммы там, где это уместно, при описании каких-то сложных процессов, для визуализации картины вцелом.
А там где возможно - используйте текстовые описания, на сколько это возможно.

С дизайнером проще всего будет общаться с помощью макетов экранов и описания требований к интерфейсу, тут UML вовсе не обязателен.

А разработчики будут при этом пользоваться диаграммами?

Или для них нужна другая форма представления?

В ближайшей перспективе нет. Буду представлять в виде user stories и описанием в хранилище знаний.
Интересно, почитать где-то про прототипирование можно?

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

Для полноты описания рекомендую в состав историй включать сценарии:
http://2015.secr.ru/lang/ru/program/submitted-presentations/bdd-by-example-russian-bylina-written-in-gherkin-language

Для полноты описания рекомендую в состав историй включать сценарии:
http://2015.secr.ru/lang/ru/program/submitted-presentations/bdd-by-example-russian-bylina-written-in-gherkin-language

Сценарии в формате BDD используются в первую очередь для автоматизации проверки Acceptance Criteria у User Story.

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

В ближайшей перспективе нет. Буду представлять в виде user stories и описанием в хранилище знаний.
Интересно, почитать где-то про прототипирование можно?

Для общего ознакомления советую статью: http://www.bridging-the-gap.com/using-wireframes-or-prototypes-to-elicit-analyze-and-validate-software-requirements/
Так же в книжке Вигерса есть отдельная глава, посвященная прототипам: "Прототипы как средство снижения риска".

Обзор инструментов прототипирования можно поискать на хабре или в гугле.

Судя по общей динамике этой беседы, единственное лекарство, которое вам поможет - делать свои задачи так, как считаете нужным. После десятого раза начнет получаться (а может и раньше, ели сообразительный))). Я 12 лет назад именно так начинала свою карьеру аналитика (через 8 лет после ее начала моя зарплата выросла примерно в 7 раз). Так что не бойтесь, бить за ошибки вас никто не будет (увольнять, думаю, тоже вряд ли - ведь найти нового и трудоустроить это лишний геморрой для компании)))