This is a good way to shoot yourself in the foot though, you can encounter problems with cooking if you use string references, but fail to do things like load the assets when cooking. So make sure as long as you’re doing this that it’s loaded in the CDO of some class loaded when cooking, or loaded via some other code executed during cook, or that the folder containing your widgets is setup in your project settings as one to always cook.
In order to avoid this, some people create UPROPERTY’s of TSubclassOf<SomeClass> or TAssetSubclassOf<SomeClass> and make blueprints that configure all the asset references. Like maybe subclassing UGameInstance, exposing all your configurable UI properties there, and then subclassing it as a blueprint for configuration. It’s a handy way to decouple the C++ code from the asset/referencing. In case you’re avoiding blueprints entirely due to perf concerns, data only blueprints (blueprints that just override and configure property values), are not really any different in terms of speed than their C++ counterparts.