The answer is:both.
Before:
The users speak the language of the UI: therefore, any requirement they have, any change request they ask for can only be in the language of the UI, in the language of the user interface.
If a user asks for adding a new method to a class, (s)he knows too much, and usually it's not how the system is actually written, but what is the mental model of the user about the system (and sometimes programming in general).
So, UI has a place in requirement gathering as it's the language the user speaks.
Usability was always tested in the UX industry beforehand, Google for paper prototyping, the "ancestor" of wireframes.
Design phase, in the original software engineering sense was there to reduce the cost of change: it takes much more time to make changes on a half-finished product.
The balance is between how detailed a design should be (how costly a design is) vs how meaningful it is to the user.
Software engineers, like in anything, like to go full-scale. I usually tell them, that you can buy a house in East-Europe from the price of a single sprint (and a brand new car in any country), and that I'm yet to see a customer saying "throw this sprint out for this feature and let's start again in next iteration", exactly because of this: usually, whatever is done in a sprint remains, even if it's suboptimal.
You have to be able to provide designs which are low-cost enough in order to be throwable.
If you do the full UI, that'll costs more, and the customers (or you) will be reluctant to throw it out completely. The less the better.
There are tools to help you make your wireframes clickable. The most usual one is powerpoint, but you can have a look at a bunch of them here.
Also, I usually employ a frontend-first solution, that is, I like to do a clickable, but non-functional frontend first (using javascript mock data stores for example), and wire in backend later, as it's the frontend the user is able to tell the problems with.
After:
Nothing is perfect, so when you have the finished product, you have to check if it does work as intended. Usually, instead of a training, I ask key users to try to do certain tasks on the interface themselves - usually a variation of the user stories / use case scenarios we've agreed on previously and which were used to build the application.
Also, whenever it's possible, I add measurement / monitoring methods to the application, which are turned on for the first few weeks (or, in case they don't take too much resources, always), and create key metrics beforehand on what we'd like to see as an improvement. Whenever there was an older version, the older version gets the same kind of monitoring beforehand, in order to have something to compare with.
For the users, the UI is the system. Interaction-wise, perhaps the interaction flow is a bit more important to get right, than finishing touches on the UI, especially as it's usually the finishing touches which make an application rigid - both in the technical and psychological sense: neither the users, nor the creators can differentiate between that and a finished application, it's stuck in their mind, but they're also stuck technologically to a given solution.