When designing a dungeon, I'll first pick a theme (e.g. lava temple), a general layout (e.g. a tower) a key item for solving puzzles (e.g. bow and arrow), and a core dungeon mechanic (e.g. changing water level)
At this early phase I'll also consider some puzzles, enemies, and obstacles that would suit this combination.
I'll then start creating a 2D map/graph (something like the picture below) while also writing a story of the player navigating the dungeon beat-by-beat. E.g. "I used X item to solve a puzzle, which rewarded a key. In this room I also noticed a door I can't reach yet. I suspect it might lead to that room with the chest I saw before. I head East."
If the dungeon is nonlinear, this story can split off in different directions which need to be designed as well.
The goal is to tell the full story of the player navigating the dungeon from beginning to end, in a way that's logically sound, prevents softlocks and frustration, etc. At this point I don't worry about what the obstacles / puzzles / bosses actually are. I'm just focussing on the logical order of their completion.
Once I'm happy with this sequence of rooms, keys, locked doors, barred doors, key items, and puzzles - then I'll move onto 3D modelling. The layout of the dungeon will change drastically when converting to 3D, but I try to keep the big story beats the same.
At this point I can playtest to check my logic actually works.
Then I go through designing each room, adding puzzles, enemies, secrets, etc, always careful to keep the macro-level sequence logic intact. The way I design an individual room would be worthy of its own thread. But then it's just lots of polish and playtesting!
Wow. Can you breakdown your process for your level design? Is this a blockout/grey boxing? Play testing is no hassle and then making changes is no hassle, right?