This post has already been read 4050 times!
Building a prototype for a presentation is a great way for clients to ‘visualize’ your design concepts and impress on that first meet and greet. Mocking up a quick design prototype in Axure from RFP or tender requirements is quick and easy, and most importantly, reusable!
Traditionally creating such a prototype has limited reuse and then only if built with reuse in mind. The advantage of using Axure is that the prototype can then be reused to generate a fully fledged functional specification.
Using Axure’s amazing specification generator and the user interface built for the prototype as a base, the additional detail required for a detailed functional specification can be quickly added.
Defining the specification fields
Every project is different, each specification is different and consequently most functional specification templates will be different. My usual practise of finding out what is required from a functional specification is to come up with what I think is an appropriate template and sit down with the technical lead project and find out what he and his team need.
There should always be enough specific detail captured in the fields you define that the development team can build the application to specification (not a reality in a lot of organisations but certainly a good mark to aim for).
The ‘base set’ I tend to use are shown below.
Then depending on what technology the project is working with and the requirements of the development team, additional fields will be added to further refine the specification.
Defining what annotations are available, select the ‘Customize’ option on the Annotations pane to bring up the ‘Customize fields and views’ screen.
So how does the above information look in a generated spec? Lets see!
The detail is formatted within a data table with a number reference back to the annotated interface above it.
This table can be changed, or a supplementary table added beneath it, by changing the ‘Word 2007 Specification’ options
Non-user interface components? No problem!
Parts of your system will not have a user interface and the assumption is an Axure-generated specification will omit them entirely. Not true!
With a bit of forward planning such sections such as permission-ing, back-end systems and integration points, can be dealt with in Axure without the need of a user interface.
Rather than building your interface first and annotating field specifications from that, ignore the field elements on use the ‘Page notes’ or create additional annotation fields specifically for non-interface sections. When generating the specification, Axure has the option to ignore fields that are blank thus removing it from all the other pages.
To add more ‘page notes’ to your project, select ‘manage notes’ from either the ‘Wireframe’ menu at the top, or the arrow on the page notes & interactions pane at the bottom.
From this interface you can add as many ‘note’ fields as necessary. I tend to add one per section as if i was creating word document manually.
Then to ensure they are generated in the specification, check the newly added notes are included in the ‘Notes’ section of the specification configuration, as shown below.
Ensure ‘Show Note Names’ to pull the headings through
And once the specification is generated into a word document, it looks like this (ignore the styling – we can jazz up the boring default word styles anytime!)
Annotated screen and user flows
I have also used this approach to providing context to screen flows within a specification by providing business and validation rules alongside the process flow.
Advantages of generating the specification
So why generate a functional specification you ask? What advantage is there over writing one from your favourite template?
- Consistency across screens – Consistency of business rules, field specifications and even naming conventions across multiple user interfaces can be quite an overhead when working manually with a large specification of 50 pages or more. Axure provides ‘masters’ for defining reusable content, select lists of predefined options for maintaining consistency and automatic numbering of all annotations.
- Save time, copy-and-paste! – Many fields tend to be repeated across screens with slight differences that can be defined once initially and then copied onto the required screens. This action retains the details defined for the field when copied cutting the work down to only the changes required.
- Automatic field numbering – Axure handily numbers all annotated fields automatically as you define them providing with an unchanging number reference for each user interface. (They can renumbered again later but they will never be updated by Axure). Axure also prints these field ‘numbers’ on the screen generated in the specification to give a quick reference to where it appears in context.
- Select lists! – although strictly speaking another measure of consistency, defining field annotations as select lists allows further governance on allowed types and reduces the amount of rework required when working across a distributed project team. It also has the benefit of being much easier and quicker to use – further enhancing time efficiency!
Tracking changes across generated specs
A handy pointer I’ve come to learn when dealing with generated specifications.
- If you rely on Word’s track changes functionality like I do for reviewing documents, then generating specs will not allow you to ‘track’ the changes as a completely new document is created each time.
- To get around this, I use another powerful Word function, ‘Compare’. Ensure you save the new and existing copies of the specification separately, and from within the ‘Review’ ribbon of Word 2007, select ‘Compare (not Combine!)’. Select the old and new document and compare away!
- This has helped identify deltas (changes) in generated documentation in other software as well, not just Axure.
Hope the above was useful – it is a wee bit more detailed than my posts to date, so hope it wasn’t too much to take in.