Эдуард Тибет

В принципе, коллеги выше уже основную часть сказали. Добавлю от себя:
1. Концепт системы и ТЗ - Аналитик.
2. Планы работы и контроль их выполнения - ПМ
3. Эксплутационная документация (руководства разного типа и вида, FAQ, HOWTO и т.п.) - технический писатель.
4. API, SDK reference, архитектурные документы - либо технический писатель (если он высокого класса), либо разработчики.
5. Постановка работ по документированию (типы документов, исполнители, docflow между членами команды и.т.п.) - в больших компаниях технический писатель уровня Lead. В маленьких стартапах - у кого больше опыта.
6. Тест-планы, тест-кейсы - группы тестирования (либо лид, либо наиболее опытный)

Для справки предыдущих участником треда: заказчики в 98% случаев НИЧЕГО не делают. Это правда жизни. Т.е. они скажут "хочу это и это", но построить из этих слов грамотную систему - см. п.1

Doxygen?

Первый вариант: по связке: SCM - выгрузка на диск - генерация - web-server. Правда, здесь онлайн документирования не будет - только документирование в коде.

Второй вариант: SCM - выгрузка в docbook - комментарии в XML Editor applet (прямо на сервере) - генерация - web-server. Но опять же с онлайном в чистом виде (как в wiki) не будет - только через выполнение апплета на клиентской машине.

Да, и еще... забыл добавить. Тот ресурс, который вы привели, использует статику. В нем нет возможности обновить онлайн.

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

Вам надо:
- красиво и кратко (презентация)?
или
- информационно и содержательно (документ)?

Все это реализовано в технологии единого источника (single sourcing technical documentation). Это функция т.н. content reuse. Термины Docbook, DITA - знакомо? Но это НЕ вики системы. Мне известно только об одном подобии этой функциональности в Confluence (и то, там она сильно урезана, т.к. не является структурированной информацией с семантической разметкой).

Но, есть ли сервисы или решения, которые помогают в этом?

doxygen?
swagger | blueprint | RAML (for REST API)?
single sourcing technical documentation?

Вы сначала определитесь, что вам надо...

Предположу, что одно из следующих:
1. Внешнее представление - т.к. шрифты заголовков, шрифт основной части, логотипчики и прочие няшные графический штуки.
2. Структуру, включая названия разделов и порядок их следования.
3. что-то еще... (что??)

Ну и главный вопрос - ЗАЧЕМ вам дизайн? :)

В больших компаниях (или при отлаженных процессах) этим занимается т.н. Технический писатель (Technical Writer). Далее я вам подскажу, как надо делать "по уму" без разных XP-техник и т.п. Прислушиваться к советам или нет - будете решать сами.

В вашем случае, думаю, брать TWR смысла нет, т.к. коллектив маленький/процессы еще не отлажены. Вы, конечно, можете взять TWR для постановки процесса документирования в вашей компании, но специалисты этого уровня - это Lead Technical Writer и его расходы на него будут сравнимы с уровнем разработчика. Сразу же говорю, что никакой студент-техпис вам работу не поставит.

Чтобы понять, что и как вам надо делать, попробуйте сами себе ответить на следующие вопросы. Я адресовал их другим участникам:
Как документировать существующее решение?
https://toster.ru/answer?answer_id=658763
https://toster.ru/answer?answer_id=658763

Имейте в виду, что некоторые участники в тех тредах с трудом анализируют информацию :)

Можете опубликовать ответы на заданные вопросы здесь, и я постараюсь подсказать вам возможные решения.