Hi Jimbo,

The key thing in use cases is to not refer to any UI design constructs, that is: 

• Don't refer to buttons: e.g. instead of "user presses the Send button", say something like "user instructs system to send the e-mail"
• Don't refer to other UI controls: e.g. instead of "user selects the state from the dropdown", say something like "user specifies the state for the address" 
• Don't refer to screens/pop-ups/pages: e.g. instead of "systems displays the login screen", say something like "system requests user to provide authentication information". 
• etc. 

The way I teach analysts to keep the use cases design agnostic is to have them imagine that they are building a system where the interface between the human (actor) and the system is voice (no keyboard, no mouse, no screens, etc.). If you keep that in mind, the way you specify the interaction between the system and the human actor will become less design centric.

For example: a use case for authentication login might look like this:

1. User requests access to the system
2. System requests for user identification and pass code
3. User provides the requested identification and pass code
4. System validates that the user is allowed to access the system
5. System notifies the user that access has been granted.

Hope this helps!
- Adrian