If the pixelation wasn't in the sources you had, then it was probably introduced by the video encoder you used to export. (Presumably Apple's h.264 encoder, creating a .mov with an h.264 video stream, as opposed to one of the many other video codecs that the mov container can hold.)
Video encoding always trades off CPU time vs. bitrate vs. quality. Using more CPU time can get better quality at the same file size. Different encoders (x264 vs. mainconcept vs. apple vs. IDK what else) will have worse or better achievable tradeoffs. x264 is the best H.264 encoder for pretty much everything, esp. if you care most about final quality per file size. It's free and open source, so there's no reason not to use it.
Look for a slider to turn up the CPU usage and/or bitrate until the resulting encode is high enough quality. I'm not going to go into any more detail, just google for video encoding guides to find out more.
edit: As stib points out, you might well be in a situation where your output file is going to be transcoded before broadcast, in which case you should just turn up the bitrate as high as is reasonable, to minimize generation loss. Prores has no advantage over h.264 for this purpose, though. Your file will be decoded once, at full rez, in order. Prores is intra-only, and can decode faster at reduced rez, but gives up quality per bitrate in order to gain those features. h.264 and prores both support bit depths higher than 8bit per component (subject to encoder/decoder support), which may be relevant if the TV station that will broadcast it wants to mess with the colors during transcode. If they won't, then the small compression advantage of 10bit h.264 is of low value, given how much slower x264 is when encoding at higher than 8bit.
prores is (slightly) lossy, but as far as I know, h.264 at the same very high bitrate will be even less lossy. You can even use x264 to produce lossless h.264, if the people you're sending it to can decode it.
If you were sending it to people that were going to do something and save that as prores themselves, then using prores yourself might make sense. I think I read that prores is designed to stop losing quality for multiple generations of transcoding.
If you're going to permanently archive the output file, spending some more CPU time (and using x264) to get good quality per bitrate might still be useful. But if you're instead archiving the FCP project and sources, then that doesn't matter.
end of edit
If you don't want to set up x264 for Final Cut Pro, or export lossless and feed that to x264, then similar controls for the h.264 encoder that comes with FCP probably exist. I don't use FCP, but this is really a video-encode-quality question, so I'm answering anyway. An answer from a FCP user would probably still be useful.
BTW, one case where x264 isn't the best choice is encoding a movie for your mobile device or something where you're only going to watch it once, and large filesize doesn't matter. Then a GPU encoder like Intel quicksync can throw enough bitrate at the video for it to look good enough on a tablet or phone, but be smaller than the dvd or blu-ray source.
If you're doing "encode once -> watch many", like for broadcast, it makes sense to use as much CPU time as you can, to get the best quality for your target filesize (2pass mode). Or to get the smallest filesize for your target quality (CRF mode).
