UI specs should capture the following pieces of data: consistent terminology, pixel-level measurements, annotated screenshots (see prior post on how to create accurate images for specs), behavioral descriptions beyond the obvious or “for free” stuff, with cross-references where appropriate and useful between depedent specs.
Tables and spreadsheets do NOT make for good spec content or layouts as they tend to be hard to read.
Indeed, specs should be considered “designed artifacts”, not simply last minute or post-mortem writing thrown together at the end of a prototyping phase. Per schedules, the spec writing should occur somewhat in parallel, with engagement with the spec writer and devs, QA, UI designer, prototyper, etc.
Chunking and spacing the text and imagery properly is necessary to achieve that delicate balance of creating a document that is easily scannable and comfortable/inviting to read at length. Extensive prose text is not recommended. Avoid “should”, “could”, “would”, and any explanations/rationale–this is not a defense but a statement of what is to be. In effect, a recipe or cookbook so that if a disaster wiped out the company, then a remote dev team can rebuild the product from the specs (presuming that the documents are backed up somewhere!)