The Unix/Linux way of dealing with partitions is quite different from the Windows way. In Linux, most programs and their related files have pretty rigidly-defined locations, set by their authors or packagers. Typically, program binaries go in /bin, /sbin, /usr/bin, or /usr/sbin. Shared libraries go in /lib or /usr/lib. System-wide configuration files go in /etc, and user-specific configuration files go in the users' home directories. Support files (graphics, sound clips, etc.) go in various locations depending on the file type. This is all defined in the Linux Filesystem Hierarchy Standard (FHS).
Most (but not all) directories in the FHS may optionally be split off onto separate partitions. Thus, if you have enough knowledge (or good advice) to predict how much stuff will go into particular directories, you can split your installation across disks by assigning particular directories to reside on particular disks.
You haven't provided enough information for me to know how much space you'll need in particular directories, but speaking in general terms, most desktop/laptop Linux installations consume roughly 15-40 GB, without considering user data. The real space-gobblers on such installations tend to be big user files -- digital photos, MP3 collections, .iso image files, and especially videos. These are all user files, which go in the /home directory. Thus, splitting off /home is often a top priority when you need to trim the size of a main Linux partition. Beyond that, you could split off directories like /var, /tmp, and others; but without knowing a lot more about your expected configuration, it's hard to make specific suggestions. 20 GB might be enough for your needs, once /home is split off; but I can't be sure of that.
OTOH, some uses put lots of files elsewhere. The /var directory tree is often huge on certain types of servers, for instance. Your question implies you might be installing Windows programs for use with WINE, and that's another exception to the usual rules -- depending on how you configure WINE, those binaries could go just about anywhere. (Personally, I wouldn't install lots of big programs for use with WINE, but that may be just me. IMHO, WINE is best used for an occasional program, and preferably for small ones, not for multiple big programs. If you need to run multiple big Windows programs, I'd recommend running them in Windows, not in Linux.)
All of this is necessary background so you can understand why your main question about installing Linux programs to NTFS is not very meaningful. Linux programs are scattered about in such a way that the only way to fully install most Linux programs on NTFS would be to use an NTFS root (/) filesystem, and that simply will not work. In principle, you might be able to get away with using NTFS for some obscure subdirectory somewhere; but Linux tends to want to adjust ownership and permissions in many of its directories, so even if you found a directory in which you could use NTFS, that might not hold when you install some new package. If you're planning to install big packages using WINE, though, you could set aside some directory for that purpose, mount an NTFS partition there, and configure WINE to use that directory as if it were C:. AFAIK, Windows programs run from WINE can run from NTFS just fine. Using your actual Windows C: partition in this way might be inadvisable, though; WINE might make changes to its configuration that would not be good. (OTOH, I'm not a WINE expert, so maybe there's a way to do this reasonably safely. Sharing OS boot partitions is always at least a little risky, though.)
Another option you might consider to work around the limited space you have on your SSD is to employ Logical Volume Management (LVM). This tool enables you to combine multiple partitions (physical volumes, or PVs, in LVM-speak) into volume groups (VGs), and then split these VGs into logical volumes (LVs). One advantage is that the resulting LVs can be sized differently than the PVs, so if you've got two smallish partitions, you can combine them together and create one LV that spans both of them. In your case, this would be useful to fit a root (/) filesystem of, say, 30 GB on a combination of the 20 GB of SSD space you've got and 10 GB of space on your HDD. Access speed would be highly variable, but this might be better than putting the root (/) filesystem entirely on the HDD.
Yet another option might be to employ bcache. This is a method of using an SSD as, essentially, an extra-large cache for a hard disk. I've played with bcache a bit, but I'm not an expert on it. The claim is that it can produce speeds that approach those of an SSD over much larger disks. In principle, you could use the 20 GB of space you've got on your SSD as the cache for the bigger space on your hard disk.
static-binarysoftware, how common are statically linked binaries on linux?