Q - Shoud the UI Spec be done in MS Word, Visio, or Both?

A - All of the above are acceptable. I personally do my Navigation Maps and Paper Mock-ups in Visio.  I personally find it more effective to insert any other necessary text into some text boxes on various pages within the Visio doc.

Q - Is the UI Spec Template a true template that I can just paste or insert my content into?

A- The "official UI Spec Template" is primarily an example for the benefit of those who do not know what a good UI Spec should look like.

Q- Why can't I use the template as a starting point for my projects UI Spec document?

A - The template IS a good starting point from a investigation and discovery (educational) standpoint. It is difficult to provide a template in the truest sense of the word [as in "insert your content here"] because format varies depending on the needs of the project and the skills of (and tools available to) the UI Architect.  Some UI Analysts may prefer to do the entire document in word, some may prefrer to do separate diagrams in Visio, and some may prefer to use a combination of Requisite Pro and Rational Rose.  To further meet the development community's needs by supplying an easily re-useable template, [as in "insert your content here"] we have also provided UI Spec docs and site maps / navigation maps HERE,

Our UI Dev Home on Support Central: Template_User Interface Specification_GEPS

on this support central site, from actual GEPS development projects.  These documents tend to be quite detailed (legnthy) and this is why the "short and sweet" official UI Spec template is provided more by way of concise example, and not as a working "copy in your content" template.

Q - Do I have to paste all of my Visio diagrams into the Word template in order to meet the PMM 4.0 requirements for proper UI Spec documentation?

A - No.  You must have a Navigation Map (tends to be a Visio tree structure taking a horizontal page format).  You must have a Paper Mock-up (user views or wireframes: tends to be a Visio document in a vertical page format allowing for developer annotation below the 'virtual' screenshot or mock up rectangle above).  You must have developer notes regarding role-based access, alternate workflow paths, and traceability information (referencing Use Case number: heading and sub-chapter from Functional Spec which the given page mock-up refers to).  You can go through the pains of cutting and pasting all your separate diagrams and documents into a single MS Word document [as was done for the official template] if you find it advantageous; however, it is equally acceptable to provide several separate documents as components of an overall "UI Design Doc." 

Q - How do I present the separate Navigation Map and Wireframes document as a single cohesive "UI Spec Document?"

A - This integration of separate docs is typically done only after sign-off,  by printing out hard copy onto three-hole punch paper and inserting them together into a single "UI Design Doc" 3-ring binder.  During the UI review sessions and subsequent revisions and sign-off, the docs are usually presented via screen-sharing in sametime conference sessions and by providing links to a UI Spec section of the project's functional spec & design documentation Quick Place.  It is simply not practical to paste both horizontal and vertical orientation diagrams into a single text based (word processor) format; especially when the primary essential content is either Visio diagrams or Rational Rose diagrams with appropriate textual annotation.

Q - I'm still unclear on what the hard deliverables are for the PMM 4.0 UI Spec requirements.

A- It's all about three deliverables: 1) Navigation Map 2) Wireframes [or paper mock-ups] and 3) electronic Prototypes [actual working html models].

Q - Any further clarifications or advice regarding writing good UI Specs?

A - Follow the PMM 4.0 methodology "how to" docs posted on Support Central at:

Reginald Acloque and Stephen Sapinski's Official PMM 4.0 Site

An Important Note: It is natural for these documents to be delivered in separate pieces because their review and sign-off is required at different phases of development.  The Navigation Map comes early on - in SDPM, immediately on the heels of BRD; and FOR BEST RESULTS, Navigation Map workout sessions (at least 2, 1 hour sessions) should be held in person (not via sametime) with business initiative leaders (as a card sorting exercise) after the BRD has been approved.

Wireframes happen only after the functional spec / use case documentation has been approved, and these iterative review sessions (held one feature module at a time) are typically held via sametime and tele-conference.

Wireframing can begin in tandem with functional spec writing; but as business requirements are getting re-written and new use cases crop up, the scope of what needs to be mocked up is inevitably changing, and this will require a longer Design and Architecture team involvement.