I am in complete agreement with your desire to avoid making design decisions within use case specifications.  This is certainly one of the hardest things to do and at times it may even seem unavoidable. Looking back at my work, however, I find that usually I am successful at avoiding most design related information.

The following information presumes that you are developing the use cases very early on in the process to capture requirements.  Screen design should come later, though when working with business representatives they seem to want to see screens right away. 

To avoid design decisions remember a few things. First, use cases and screens are not a one to one relationship.  A system use case describes a series of actor/system interactions to achieve something of standalone value for the user.  So a single use case will often, if not usually, span multiple screens within a system.  There should be no reference to or knowledge of these screen to the reader.  It's just "the system". Second, while the system will display information to the user/actor you don't need to specify what controls are used.  The actor will provide certain information and the system will do something or make a decision based on that information.  Then, it may present some information back.  Exactly how the user sees that information you don't need to get into.  Third, don't allow the logic of the system use cases to get too overly detailed.  Remember, they are not the only artifacts you will be creating.  They are to capture functional requirements in a way thats easily understood by the business.  If you get too detailed you defeat the purpose of creating use cases.

I know a lot of this sounds easy, but is actually very difficult in practice.  Another tip that I have found helpful to keeping design out of my system use cases is to first start by creating business use cases.  Describe the processes in term of the business and busines workers as if none of the process was automated by a system.  Moving from a business use case to a system use case, i.e. replacing parts of the business use cases with user/system interactions, help get you going on the right track.

Finally, a comment about developing use cases simultaneously with screen mockups.  This is often done so that the business can visualize how things will work.  If you must go down this path then understand that keeping design out of your use cases will be much more difficult.  You as the analyst will inevitably start thinking about controls and screens.  Just make sure you don't include them in your use cases.  This makes use case maintanance unbearable and eventually your use case model reflects far more than functional requirement.  They begin to restrict your developers.

Hope this helped.  I know some of this may seem generic.

Thanks for the advice!  I came from the development side of the house, so I think I automatically think about how the screens would look.  I am trying to change my mindset when doing the business analysis and that is why I am looking for tips. 

Would any of you be able to post an example of a use case you have done in the past?  It would help me to see the kind of language that you use to describe the interaction between the user and system in a full example...what the user does and how the system responds.

Also, lets say that the users require that all changes to account status get tracked and they need to be able to see the status history.  Would you specify in the use case that allows a user to change the status of an account the following :  "...the system records the status change, including: old status, new status, date, and user."?

Thanks!