Being a GB/GBC you are likely not going to file names, extensions and such. They can make life far easier when you have a nice folder called lvl or something similar.
You can trace your way to level data (for graphics but what tracing sessions involve, albeit many will have graphical frontends if you want, https://www.romhacking.net/documents/361/
). If it ends up governing where a given tile lands on screen (or even is being animated) then you can go up and up until you find what put it there and where it found what to do that from.
You can also go the other way and eliminate things. If you know what is text, music, graphics and the CPU code* you don't tend to have many other choices. At this point a bit of corruption or fiddling can be the thread you pull to unravel the whole thing. Memory editing can be useful here too -- a ROM might be megabytes in size but RAM tends to only house stuff the game cares about at the time, possibly while keeping everything else the same. Find it here and search the ROM for it, or trace it back up.
*for very simple games it might be buried in the CPU code much like very simple/low text games might bury it in there.
Hex editors are very crude tools. If you are using one then you had really better just be doing a very minor change, or something you can essentially do with a find and replace or copy and paste. For a level edit I would expect it mainly if you already know the format and just want to shuffle something a few rows over, or stick another thing in there.
As for how it is organised. You usually only have a handful of ways 2d (and many 3d) levels are organised. Much like game consoles don't usually have the grunt to do proper collision detection they cheat and have things do it for them. I like to think of them as layers -- one for blocks, one for pickups, one for enemies, one for hazards... though occasionally one or all of those will be merged together (it is not unreasonable at all as a game coder to have enemies and pickups in one "layer"). For 3d stuff then the graphics are usually separate from the thing that determines where the level actually is (I am sure we have all fallen through a level at some point), and further things like where the actual track is in the case of racing games, though as the dev will have a nice thing to just generate it at the same time this can make things a bit harder there.
Beyond that there are two main approaches for each method. One is exhaustive where the level format paints each and every part of it much like each pixel makes up a tile and you can't just do nothing even if you want it blank. The other will see it use some kind of coordinate system to tell it where a given type of asset needs to be relative to something (screen, level, sub level, camera...), systems that support some measure of scrolling also tend not to have things be screen relative and can be any coordinate system the dev cared to cook up (and for 3d it gets worse -- https://www.youtube.com/watch?v=kpk2tdsPh0A
Once I have an example of at least one of those I usually blank it as best I can and then build a list of what each value does/creates for that thing. Same idea as many use for making a table for text, or filling out the odd bits of punctuation, really.
Of note here. If a sequel on the same or related system has a user made level editor have a look, if a PC port happened have a look. If the game has its own inbuilt editor then have a look there too.
Skills pre requisites. If you have those then you have more than enough to make a dent here in quite a few games. There might well be something out there that sees you have to learn something more to make a start with it, something someone else more versed in hacking might not, but I would say the vast majority are within your purview at present. Worst you will probably do is overload the game by putting too much on screen or in the level and running out of resources.
More generally, and for the random forum searcher that might find this at some point in the future, then the idea of data representation needs to be on lock. If you can do assembly as far as tracing it can help but at the same time if you somehow find where a piece of level data is housed then you can figure out much of what you care to know in sensible timeframes by brute force, indeed after finding it I still usually use brute force (read trying every value) and noting what it does rather than playing with a debugger. If I know I have a given level I will obviously also look at what it has and try to match it to the thing I eventually see on screen**.
Savestates, as usual, can be a dangerous thing if you notice the level is in memory and want to try poking it there. By all means give it a go but much like text you risk having the game already having done all it needs to do with it by the time you come to prodding it.
**for many things I encourage using cheats to speed a process up but I have limited uses for them here -- if you find an inventory code for a common item like a potion you don't then have to play 400 hours to get a rare drop item if you can just increase the numbers. For level editing then some kind of cheat to change the player location can help build up a complete level image or put them in interesting locations to help with this seeing on screen business.
I have some worked examples for a DS game in http://www.romhacking.net/forum/index.php/topic,14708.0.html
, though it is a game with a level editor I could abuse a bit to help out.