Not surprised to see no answers here so far. Most people skip all this work (and learning) and use the framework which directly gives you the structures of the game client’s user interface.
The approach used in that framework is based on the CPython memory layouts. That is convenient because you can take the offsets as defined in the CPython source code.
For the parts specific for EVE Online, I see a description of the UI tree at Advanced Do It Yourself Memory Reading In EVE Online - #3 by Arcitectus
That post is from the pre-64-bit era, so some of the offsets might have changed in the meantime. Since the low-level reading implementation is open-source, reading that source code seems a reliable way to learn how it works: Sanderling/implement/read-memory-64-bit at 13891fe2031f4bf1d5b022818b9c0103e5e6668c · Arcitectus/Sanderling · GitHub
The Elm debugger is more for the application side of things. For the part up to getting the UI tree, I don’t see a use for the Elm debugger, because that part happens before the values arrive in Elm. I see two flavors of Elm inspection tools: One is the ‘Elm debugger’ coming with the compilation of the frontend in the alternate UI for EVE Online: This is the one we use to inspect changes to the parsing code. Parsing is what apps do after getting the UI tree, to provide a more convenient API to developers: bots/guide/eve-online/parsed-user-interface-of-the-eve-online-game-client.md at main · Viir/bots · GitHub
The other kind is the general Elm inspection tool, not limited to frontend apps but used to inspect bots and other apps. This one is mostly work in progress for now.