For a dual boot configuration, you might as well not copy anything over. You'd be better off mounting the Windows partition in the Linux install. There's not a great reason to dual-boot for non-technical users, though. The point is to end up on a system that works for them, not to have one that works for them and a derelict system that they don't know how to remove, and that can destroy their dual-boot setup if MS decides to push an update that overwrites the boot loader, leaving them unable to access the Linux install.
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.
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.