Il est possible de décrire Fortnite comme étant "un jeu vidéo de type battle royale, disponible sur plusieurs plateformes en free-to-play" : en quelques mots, nous avons les éléments principaux de la partie jeu vidéo. Pour autant, il est aussi possible de décrire Fortnite comme le fait Dan Olson dans sa vidéo de 2019 :
Fortnite is first and foremost a storefront.
—Dan Olson, 2019, Manufactured Discontent and Fortnite 7:55
Cette façon de décrire le même objet raconte une toute autre histoire. Il ne s'agit plus d'un jeu vidéo et de ses caractéristiques, il s'agit d'une vitrine pour vendre quelque chose (et faire de l'argent). Partir d'une telle phrase, c'est se concentrer sur la monétisation et la mise en avant des produits à la vente.
La force de la narration est de permettre, au-delà d'une suite d'événements, de transmettre des émotions, des opinions, des idées. Elle tisse des liens entre les concepts, et nous permet d'établir des connexions. Une bonne histoire captive son audience et attire son attention, autant de propriétés intéressantes lorsqu'il est question de documenter un projet.
La documentation raconte l'histoire d'un projet, d'une application, d'un outil. C'est une suite d'histoires qui doivent répondre aux questions que se pose son auditoire : si Fortnite est un jeu vidéo de type battle royale, que voulons-nous dire par "battle royale" ? Réfléchir à chacun des concepts clés permet de révéler les sous-thèmes et de développer progressivement ce qui doit être documenter. Raconter l'histoire d'un projet, c'est aussi faire des choix entre ce qui sera raconté et qui sera au premier plan, et ce qui restera au second plan ou qui sera mis de côté.
Tout cela permet d'arriver à une carte mentale, aussi pratique tant pour écrire et organiser la documentation que pour la lire et comprendre son sujet.
Cependant, si la lecture d'un roman est linéaire, c'est-à-dire qui se commence au début, et se termine par la fin, ce n'est pas exactement le cas de la documentation. Il faut donc savoir identifier lorsque la narration doit être complétée par une bonne organisation en thèmes et en chapitres d'une part, et en références, notes, "voir aussi" et autres encarts qui viennent ouvrir la lecture à d'autres sujets d'autre part.
Écrire la documentation revient donc à commencer par le début, en écrivant une phrase qui décrit succinctement ce qu'est le projet. Cette introduction permet d'identifier les éléments clés du projet, les concepts qui deviendront les thèmes principaux de la documentation. Chaque concept pourra alors être développé dans son propre chapitre, permettant de naviguer d'un concept à un autre. C'est un processus aussi collaboratif et itératif que peut l'être le développement logiciel.
Enfin, si une bonne histoire se termine par une bonne fin, et qu'une bonne partie de Fortnite se termine par une "Victory Royale", la documentation n'a pas réellement de fin. Si la documentation raconte l'histoire du projet, elle ne représente qu'un petit chapitre dans l'histoire qu'elle se doit de servir avant tout : celle de son public.