I couldn't say there's really any right answer here since this has to do with design, and there's always a million different ways to program something, so I'll just give you some of my thoughts on the matter.

I understand what you are hoping to do, but truthfully, I would personally create a third class to create and store device resources such as shaders, and maybe a fourth class to store the materials.

Again you can do it however you want, but if you put dx12 specific code inside your UI, then your UI is stuck with using dx12. If you put this UI class into another program like you want, and it uses another graphics API, you'll end up doing a lot more re-coding of the UI class.

Another thing is it is quite possible that other systems may benefit from using the same shaders that the UI class is using, so if your UI class is keeping those shaders to itself, the other system will have to create and store its own version of the same shader, where you will then have multiple copies of the shader, when you could just have one.

I know you want a reusable UI class, so that is why i'm suggesting the above. You want to make your classes as specific as possible to what they do though.

So with the above suggestions, I think you should be able to solve your problem. I can't understand why it's obvious the frame structure can't hold any of the data that the UI class has, so there's really not much more advice I can give without knowing more of your actual design, since there are so many ways you could do this. 

I realize I haven't quite answered your question exactly yet. My answer to should your UI class have it's own frame data, I would say no. Really the only need for having more than one frame of data is for double or triple buffering, which has to do with rendering. Like i mentioned above, you shouldn't have your actual device (rendering) code inside your UI class. Your "Frame" structure can copy the data inside your UI class if needed for a frame, then next frame will copy the new data.