things evolve and change, basics would be there for a long time.
State driven approach is a concrete methodology used in many places and many of the AAA games. There is nothing truly wrong or right imo however state driven approach is a bit more strict and can be a bit harder to get used to, on the other hand results are predictable, understandable, debugable and grants developer maximum control.
Bad news
there would be always something to learn so get used to it
It even can become boring. There is a built in method as demonstrated above post by Epic which works, my approach also works
maybe even sometimes better 
What I think is WRONG is using a wording like “Focus” as UX writing is a (i’ll be a little bit blunt here) absuletely most confusing wording of choice in engine, it really confuses people, it confused me a lot and seems to be its continuing to be more confusing with “Desired Focus” 
I will demo you, will be brief, rest is in your hands. It is pure blueprint also this is not rocket science.
Created 4 input actions specifically for UI
I defined this into a mapping context to keep it simple WSAD for now.
Created a very brief enumaration for my states of interfaces in general
Created a button base widget
In this button created some logic as follows
Over here treated mouse enter leave just cosmetic.
Created 2 events OnButtonStateChanged which passes its state enum
OnButtonInteracted which passes self button widget as object.
Override OnMouseButtonDown and calll OnButtonInteracted
also made a function as SetButtonState which simply sets enum and calls event state change.
Now I have a simple atomic custom element. I shortcut a lot of things so excuse me for that but thing you can do more around it.
I moved to a parent widget, let’s say this is My_Menu_WGT added canvas, verticalbox and some of my buttons.
In simple terms of logic,
I get how many buttons there is and save them as array
I count them
for each button bind to its Interacted.
Create Function SetButtonState :
Which simply iterate all call set state normal
and for index set selected
CreateFunction or Event NavDown/UP
CurrentID (Increment or Decrement) Clamp and Call SetButtonState
You can do wraps etc if you like and make it much nicer.
Additionaly set 1st button as selected on construct
I have another function which is handles the key events, can be like this also if input mode is different can be direct input , think there are some more changes with activatable widget input handling however simply
Get key compare to EnhancedInputSub action If they match Call Up or Down depending on action.
Created widget on my pawn, added to viewport, set input mode to ui and show a cursor.
Results.
Sorry for keeping it simple as possible however this simply demonstrates.
1-Parent is manager
2-Widgets are state driven
3-Atoms don’t care what interacted with them they only know their own status
4-We only focus panel, the rest is history.
Let me know!
Addition
You can also use a hack like this to maintain Input Owner (focus) at your panel if you don’t want to maintain every widgets interaction state however sub widgets in this approach majority of the time shouln’t require a focus.