Consider your end-user when you are approaching the UI specification. Agree with your end-user (developers) on the areas of focus, e.g. Visual styles specification vs. functional specification, levels of the details and what are they used to.
Understand what is the “core” and what is the “nice to have”. A good way of doing this would be projecting the impact on the user experience if something was implemented incorrectly.
Also think, what do you want to include for yourself or your design team, so that when a new designer is joining and designing an additional feature – instead of fishing for small use cases using tests accounts – they can just open your documentation and get a quick snapshot of the situation.
Hopefully, you don’t have to write visual specs (there are plenty of design tools that eliminate the need for this hand-off process between design and dev).
When writing functional specifications, your main goal is to capture the logic of events and user flows. For that, diagrams with rich comments is a good start when describing complex user flows. When describing screen interaction, make sure you are focusing on the outcome rather than context, e.g. single choice option vs. radio button. The decision on the radio buttons vs select menu is not necessary to be captured in functional specs since it might be affected by the observed usage later and evolve from one to another.
If you are writing full and detailed documentation: It is a good idea to have an index for your specification, and a search. Organize your content by application sections and features, so that it is easier to navigate them later. Use references and links to avoid redundant content, in cases when the same feature appears on many screens.
