It's clear to me that as a BA you don't want to get into UI design. What is unclear is who is responsible for user interaction design? If you leave it to the engineers they will tend to design user interaction that is system-centric, not user-centric - a recipe for user discontent. You've seen this before: systems where frequently executed tasks take the user many steps to complete because the functions weren't well-placed in the right screens with the right linkages to other screens. So unless your organization has a user interaction designer who knows what they're doing, I'd rather see the responsibility fall on the BA than a developer - the BA is much closer to the user and understands what they're trying to accomplish in their work.
I like testing mockups on users to validate requirements which means, as Chris pointed out, that you have to think about separating UI elements from requirements. I've successfully documented a highly user-interactive system the following way:
1. Create a crude Visio drawing of the user-tested mockup screens and clearly point out that it's for illustration only to graphically show how functions are grouped. I make it ugly enough to get the point across that I'm not trying to do UI design.
2. Under each screen drawing I document a user-centric "focus area" which is a textual description of the functions in each mockup screen. I can even add related business rules and UI advice from the user tests such as how fields should be named. Simple example (o = system invoked function, . = user invoked function, > = link to other focus area):
Focus Area: Enter account information
Functions
. Enter or change customer name and address
[here you can also specify the fields, how fields should be named, # of characters, etc.]
o See available account managers
Business Rule: only show account managers assigned to the customer zip code
. Assign account manager to customer
Links
> Enter new order
> See past orders
Business objects
Customer
Account Manager
3. Provide use cases that show the dynamics of how users use the functions in the focus areas and in what order. The focus areas provide a system "floor plan" of grouped functions and the use cases show how users move about in the system to get something done.
The focus areas are what communicate the functional requirements, but it also includes elements of interaction design: how functions should be grouped to coherently support a task and how users want to navigate the system.