What I do first is figure out the ROM or disk(c) file format first. That helps me section various parts of the file so that I know what type of data they are as best as possible.
For example, if I was working with a NES/FC ROM. I know for starters that the file has up to three parts. Those would be header,RPG-ROM, sometimes CHR-ROM if the game has it. I also read the header and determine information about the file. For iNES and many others, there are many banks in a file. If you have a mapper 1 (MMC1) game, most of those have 16KB sized banks each about $4000h in size. Doing this will tell you the boundries and that most of the time you cannot easily hack past or outside of that bank. Commonly, a lot of the same information would be in one particular bank. Reset code, interrupts, framework for the entire ROM would be on one. You could have an entire audio music driver on another bank. Title screen and other misc things could be on another bank, etc. You just look around and deduce various things one at a time.
Some basic things you could do first is looking for text in a game. Once you find that and everything else on a particular screen. You can use GameGenie codes to find other data, perhaps stats and other things. You can do a lot of this stuff without doing too much assembly hacking right from the beginning. I didn't know assembly languages when I started. There are a lot of basic things you can do, just look in Getting Started on the left menu.
File system games are more difficult to hack and not usually a beginner's project. But it can be done.
They have various files in the disk(c) that are of various size and you can't change the files unless you know what you're doing.
I suggest that you do some research and then you can slowly figure out how to map out a ROM.