A singleton for your
UserInterface makes only sense when all of the following conditions are met:
having more than one instance cannot be allowed, because that would cause a misfunction in the program if two of those objects exist at the same time
you know for sure you will never need inheritance for
If not both conditions are met, a singleton is either unsuitable or overdesigned. This is pretty often the case in real-world scemarios, that's why Singleton is often considered to be an anti-pattern.
Note also that when there are components depending on the "singleton candidate", passing the latter by constructor injection into the components / classes may simplify unit testing. By this kind of design, it does not make a huge difference if the injected object is a singleton or not. In case all the depending components are implemented that way, the "singleton mechanics" is probably not worth the hassle, since you can make sure there is only one object of the "singleton candidate" in "wiring up" part of the program.