So long as enough contiguous space is available to install the desired Linux distro.
You can't do this all on the same drive, because you need a place to copy the documents directory to. You need to delete the NTFS partition to create the place to copy the files to, but by the time you've done that, the Documents are inaccessible. You could do it in memory, feasibly, if you create a RAMdisk and are lucky enough to have enough memory for all your documents, but then you're still gambling on not running out of memory during the install.
So it is possible to copy the documents on the same device, and it's possible to even automate the process, but it's not possible to do it reliably or safely, and the reliability is so low that it's not worth even offering the possibility. If somebody has a handful of gigabytes of documents, it's already a nonstarter. To be safe you'd demand the user make a backup onto another device anyway, in which case they might as well do that and then copy the files into a fresh install themselves
It's not just shrinking and copying over to the new `/home` because of the locality of the data. If your NTFS partition is taking the entirety of the disk (minus EFI and system partitions), shrinking it will then make it take up the first X% of the disk. Then you have to make the linux installation on the last (100-X)% of the disk, copy the files over, and then when you delete the NTFS partition, your Linux filesystem is on the last half of the disk with a big blank unallocated area on the beginning. BTRFS or LVM2 could help a little bit there, but that's far from ideal in any case.
Probably the best approach would be to shrink NTFS, create a new partition at the end of at least the right size, copy the files over, then wipe the NTFS partition, install Linux as the first partition (after system/EFI and such), then copy the files into the user's home, and then remove the documents partition. That's still not super reliable, though. You are at the mercy of your documents sizes, filesystem fragmentation (remember, even if your filesystem is mostly empty, you might not be able to shrink if fragmentation is in a bad place. You could defrag, but then the install time can balloon up many hours for the defrag process alone, just to shrink a filesystem that you're going to delete anyway), how big the Linux install will end up being, and many other factors. You'd have a lot of people who simply can't copy their documents over on install who will be simply SOL. I can't think of a situation where this kind of thing wouldn't be better served by just telling the user to backup their documents to a USB drive and move them back afterward, because many people are going to have to do that anyway.
I like to preserve the ability for the user to boot to the original Windows they have become familiar with, so they will have continued access to their local files using established permissions, apps, bitlocker, etc. Going forward on their own time at their leisure.
Shrink that old NTFS volume quite a bit, which the user won't be using that much more anyway, and make a new NTFS partition for W11. Pay attention to the usual optimizations like no hibernation or auto Daylight Savings adjustment and nothing beats dual booting the regular NT6 way. I also disable bitlocker for the Windows install process once that became the default, this must be carefully reserved for intentional deployment with the user's involvement afterward. Then in remaining space on a third major partition, install Linux to a single dedicated EXT-formatted type {0FC63DAF-8483-4772-8E79-3D69D8477DE4} volume.
Usr, swap, home, etc will all be there in one place (not unlike Windows which most often is confined to a single main partition itself, utilizing only the boot files located on a separate dedicated boot volume), and Grub will point to the still-existing functional NT6 bootloader when you need W10 or W11.
You create the new Linux {0FC63DAF-8483-4772-8E79-3D69D8477DE4} partition in Windows beforehand, which does a good job of alignment on SSDs, and leave the intended Linux partition unformatted. In Diskpart SET ID={0FC63DAF-8483-4772-8E79-3D69D8477DE4} to categorize a selected ordinary Windows OS partition as a blanket Linux partition instead, regardless of whether either one is formatted yet or not. Once the Windows system is OK (multiboot or not), then boot to the setup USB of the chosen Linux distro instead, and if everything is nominal the established boot volume will be autorecognized, you can choose the target unformatted space for your root, making no other choices for things like USR, Linux will install to that single target partition and it will just work. Linux goes onto its own partition, never touches Windows at all, nor anything in the \EFI\Microsoft folder. In this case Linux merely replaces the \EFI\Microsoft-seeking \EFI\BOOT\bootx64.efi, one single file (which you can "easily" back up once you gain access to the EFI folder :\), with an identically-named \EFI\BOOT\bootx64.efi which instead seeks a \EFI\ubuntu folder, for instance.
Where the \EFI\ubuntu folder is its own boootfolder autocreated during a ubuntu install process. Not much differently than the \EFI\Microsoft folder that was autocreated during the initial NT6 installation process. Where additional Windows versions installed later to other partitions do not create additional \EFI\Microsoft folders, but instead adds a bootmenu entry within, pointing to the newest Windows install as the new default. Leaving previous Windows installs as non-default entries.
You also may have to put adequate focus on the EFI subfolders on the SSD so they can handle the boot process completely, without any dependency on the actual UEFI firmware boot entries within the mainboard, but with some optimnized settings this just works too as soon as the Linux install is complete. Regardless it often may be best to delete the mainboard entries themselves once this is confirmed. But different mainboard UEFIs can have different approaches to the settings needed for this to work to your advantage. UEFI may be stupidly more complex than BIOS, but there are still not that many different settings compared to most user software and it doesn't take that much effort to become more familiar than the average person. After all this time has passed, the bar is still very low due to so many mainstream users recoiling in absolute learned fear at the thought of even looking at their BIOS settings. Not a problem for a true tech noob if they put their mind to it, but when does the average noob get around to that? I thought so.
In an ideal UEFI implementation proper firmware entries are autogenerated from what is found on the SSD. But sometimes only when there are no existing entries in the UEFI or anything else unexpected, and not often will unused entries be autoremoved properly once a particular SSD has been intentionally disconnected and is no longer part of the system. UEFI Shellx64.efi can be your friend which is like DOS only simpler, but few go there either. If you can do a hello world in any language you can probably remove unwanted entries with a UEFI shell though. Can also be accomplished from the command line in Linux or Windows but Shell is easier.
If you do get a wild hair and manually put back the original \EFI\Microsoft-seeking bootx64.efi file back into the \EFI\BOOT\ folder, to replace a Linux version of bootx64.efi, well the PC will again act like there in no Linux at all then. No sign of Grub will exist and Windows will naturally not natively see the files on the EXT volume.
Upon startup a Linux-seeking bootx64.efi proceeds to Grub in the \EFI\ubuntu folder, where Linux is the default but you can choose to (multi)boot Windows as the main alternate choice any time you are at the Grub bootmenu. Because Windows bootloader is detected and autoadded to the Grub bootmenu during Linux install from the beginning. Additional versions of Linux installed to further partitions will become the new default in Grub. To get Windows to be the default in Grub you have take action yourself though.
If you then install an additional Windows version, or re-install Windows in many nominal ways, it will usually overwrite the Linux-seeking bootx64.efi with a Windows-seeking version, and then it acts like there is no Linux any more either, but Linux is still there untouched assuming you always correctly direct any Windows or Linux installs to a single partition at most, without overwriting, formatting or deleting anything else, especially not re-partitioning of any kind.
This is all provided you have almost every single option on the Linux install routine very carefully chosen to achieve this exact scenario. Once you determine the settings it's a breeze to get there every time.
Unfortunately there can be a big difference between distros as to how to get the settings right so serious rehearsal using SSDs containing no valuable data is a must :\
When the time is right, any OS on the drive can have its ethernet & wifi devices disabled once it is no longer being effectively secured from network threats. So the user doesn't accidentally go on the web with an OS that they shouldn't.
Sure is a lot easier to just discard everything on the SSD, turn it over to Linux completely and kill 'em all, but it's not for everybody and some people do really well with a transition piece or two.
Can't help thinking that should be in a bigger font. It's a shame there doesn't seem to be a away to install Linux and keep your Documents directory at least. Is that due to file systems?
[Yes, yes, backup to memory stick/external drive but I'm talking about for your average person on the street]