Axure specification templates Deep-Dive – configuration options

In the first part of this post, I went through the process of creating and refining a word template to suit a generated Axure specification. This really only touched on one tab of the specification generation configuration and the idea of this post is to go over the remaining options and explore their usage.

Lets assume you already have a project to work from that will generate a useful specification and press ‘F6’ or the ‘Generate Specification’ on the toolbar.

I want to explore the available options on each tab of the configuration window and show the effect each has on the generated spec.


Pages – a blessing for BA’s working within an iterative project

So the first tab, ‘Pages’ allows you to select which of the pages within your project you wish to include in the generated specification.


Starting with the first options, there is an option to include the pages section and give it a title and directly beneath that an option to specify whether to include a sitemap and change it’s title.


Then the next section allows you to select what pages will be included in the generated spec. This is particularly useful when developing in an iterative approach where the specification is built a functional area or module at a time. This way you can flesh out the annotations / notes for the relevant pages  and leave out those that are not finished.

When generated in the specification, the following section of the spec is effected by the ‘Pages’ configuration options.


Masters: to repeat – or not to repeat?

Masters in Axure are used to define common elements that appear across the system and allow a centralised governance. Make a change for one master and its applied across them all. It’s a concept that is used in traditional manual specifications but is harder to manage – primarily because it relies on manual processes to apply changes to the relevant areas.

In your specification, you have the option to print out all or a select few masters as you did with pages, change section and heading titles.

The interesting set (the other options are essentially the same as document above for ‘Pages’) are around which masters to generate and whether to generate them once or as they used per page.


The first option – ‘Only List Generated Masters’ is useful if there are masters in the project that are not being generated because of one of the other options in this screen (explained below, but useful for the iterative / modular spec approach).

‘Only Generate Masters Used on Generated Pages’ only includes masters that are are used in the selected pages from the ‘Pages’ tab. If ‘All Pages’ is set on that tab by definition all masters will also all be displayed.

‘The ‘Do Not Generate Masters Set as Custom Widgets’ does exactly that, funnily enough. Some masters can be set to behave like custom widgets and this allows them to removed from the master list if necessary. This could be useful if you are using a master in a different, possibly more dynamic way, than standard masters and wanted to differentiate it from the other masters in the list.

The last option allows you to generate the master in each page that it appears, rather than the standard approach of generate once and reference it when it is used elsewhere.

So that translates to the following rendering in the specification.


Un-ticking the ‘Document Masters in Page Sections’ box displays a nice section at the bottom with all of your masters like the above.


… and ‘Ticking’ the box displays the master as it appears within the page as if it was a normal widget on the page.

The above ‘repeat on each relevant page’ approach may prove useful in situations where the generated specification does not include the whole system context and therefore it may not make sense to list them out separately

Notes – adding extra detail to your specifications

The ‘Notes’ tab doesn’t offer too much additional configuration elements other than whether to include page interactions (‘OnPageLoad’ events/conditions) or not.


Similar to the other tabs of, the main configuration options are around whether you generate all or select few, rename the title or change the order of each notes.


The last tickbox for ‘Include Page Interactions’ determines whether ‘OnPageLoad’ events are generated into the specification or not.

image –> image

Screenshot – to power to present pictures

I find the screenshots within the generated specifications to be one of the most useful features of Axure-drive specifications and a primary-driver for using the tool in my projects.


As such, I find the ‘Show footnotes on screenshot’ option the most useful feature behind the annotations tables and always have it selected. There might arise an occasion where a specification was required where just clean screenshots of the interface was required, free from any overlaid footnote references. This would be a perfect time to use this option.


The ‘Put border on screenshot’ surprisingly does just that, adds a solid border around all screenshots – not a favourite of mine and wouldn’t suggest you use it.

‘Do not scale footnotes with screenshot’ option keeps to the footnote markers the same size when scaling out screenshots. A useful feature if you plan to resize the screenshots,

image –>image

You can see the difference in scaling at not-scaling of the footnotes.

The last option, ‘Apply default OnPageLoad cases’ refers to applying the default ‘OnPageLoad’ event to the screenshot. This is useful when generating from a dynamic prototype which has an ‘OnPageLoad’ condition that you want to capture in the specification.

Annotations – the meat of the specification

As I mentioned before, the annotations are the single-biggest feature of the specification generation in Axure and a feature which turns the product from a useful prototyping application to a platform for managing the specification and design life-cycle.


This tab generates the tables based on the annotations for each page element/widget and provide a very powerful and automated way of generating field specifications.

As with the other tabs, select the annotations that you wish to include and the order in which they should appear. When correctly annotated and rendered into the word template, the above selection of annotations look like the following.


Defining the appropriate annotations to use in your project is another matter entirely and beyond the scope of this post, but the above should give an indication of how it can be used effectively.

Widgets – including dynamic options in the specification

There are likely to many cases where a prototype has been built with specific dynamic features built in that the client really liked and wants in the application. Seeing as they have already been built into the prototype, why not re-use what’s been done and expand on it for the functional specification?

The ‘Widgets’ tab provides such options for including the dynamic properties of widgets such as rollover states, drop-list options, and list box options.


Most of the options are fairly self-explanatory, if you use any of dynamic behaviours from above in your prototypes, then tick the option to include it within the specification.

Examples of such options within the spec are below.


Droplist values are vital if creating a complete functional specification.


Rollover states are also very useful within a specification to give context around a how a particular rollover works and what exactly happens.

If you have read my Replicating AJAX-style lightbox within Axure prototypes post, you should recognize the above rollover definitions.

One really useful feature I routinely use in my specifications is the ‘ Include List of Masters’ option. This provides a small heading and list of all masters used on the current page. Very useful if you are not repeating masters on every page which is normally the case.


The master list (although not styled in the above screenshot) adds the reference back to the pre-defined master and avoids you needing to repeat for each page.

Last but not least – 1 column vs. 2-column formats

The last tab is the ‘Word Template’ options which I detailed in my post, Axure specification templates explored and the only option I didn’t cover in there was ‘Generate Two Column Format’.

This feature does exactly what it infers, generates the specification into two side-by-side columns. To me, the obvious application of this if you are wanting to generate simplified specifications on large paper (A3+) where the field specifications and screenshot are displayed on a single page.


The above screenshot was taken of a two-column format specification.


Wow – that was a lot of content and a lot of detail, so I hope that proves useful to you all.

The aim of these posts is to convince people that using Axure as a platform for managing specifications and re-using prototype work is a very smart solution and can reduce a great amount of rework and increase specification accuracy.

I think my next post will target annotations and what to choose to get a specification both developers, testers and the client can all understand and find useful.


Axure specification templates explored

If you have read my other posts on generating specifications from Axure and the benefits of doing so, then you may want to delve into the world of customising spec templates and the various configurations options.

I am a strong believe in letting the application (in this case ‘Axure’) doing the laborious work for you and therefore increasing efficiency / productivity of your time. Creating a clean and professional looking template for Axure to work with goes a long way to removing the frustrations of writing specifications and allows the BA to focus on the analysis tasks at hand, rather than the idiosyncrasies of MS Word (an all too common problem!).

Most organisations have a standard word template or at least documents that have a consistent style that a template can be derived from, so finding one of these should be your first port of call. Once you have located one of these we shall jump right into the customising your template to fit Axure.

Hit ‘F6’ or click the generate specification button on the toolbar image to bring up the specification configuration options.

The bottom tab ‘Word Template’ allows you select a word template to import or edit the current template and should look like the following.


This dialogue contains the standard word heading and table styles which Axure uses in its template. To start with a pre-existing word template as your base template, select ‘Import’ and locate your .dot or .dotx word template mentioned earlier. This will import the styles and allow you to edit them to fit Axure.

Axure also has some nice professional looking templates you can use a base as well by selecting ‘Import Axure Template’. I would suggest you edit these to suit your purpose/client rather than using verbatim to give a more professional fit.


Axure has several clean-looking templates to select from.


The imported Axure templates give some great examples of how word templates can be used to generate great looking specifications, as demonstrated by the table style above.

Editing your base template

Once you have imported your template, either your company template or an imported Axure one, it pays to edit the styles to better fit the needs of your project and/or client.

To do this, select ‘Edit’ from the ‘Word Template’ tab of the specification configuration window shown above. This will open the word template and allow you to edit the relevant styles.

Once the word document is open, create some text to identify all of the Axure styles, apply the styles to each line and update them to how I want them to look. I shall demonstrate with screen shots below.


Here i have typed out Heading 1, 2 etc and them applied the style to the relevant text to see how they look. To display the style window like above in Word 2007 simply click the ‘expand’ button on the bottom right hand corner of the ‘quick style’ panel, as shown below (button highlighted in orange).


Now all the styles are visible, we can apply changes and them save them back into the styles for the template, which is read by Axure.

How do we do this? Lets see!

Lets take ‘AxureHeading’ for an example. I want to make this more prominent by giving it a horizontal line underneath and making it much larger.

Select the text for ‘Heading 1’ and click ‘Manage Styles’, a small button on the bottom of the ‘Styles’ panel, shown below.


Then ensuring ‘AxureHeading1’ is selected again, choose the ‘Modify’ option on the style panel, as shown below.


Now all the available options for that style are shown and here you can change whichever formatting option of the heading that is required. For the horizontal line under the heading, select ‘Format’ –> ‘Border’


and make sure the bottom border is applied to the paragraph, as shown below.


Now once the heading style is saved and applied the ‘Heading 1’ text on our template, it should look something like the following (or should apply whatever other formatting you applied to the template).


This process should be repeated for each Axure style and once you are happy with all your styles, save the template and return to ‘Axure’ to generated a spec and see how your new template looks.

Quick pointer: Make sure you delete the ‘Heading 1, 2 etc’ text that we put in the template above before you save. If you forget to do this the text will end up in all of your specifications and look out of place!

Table styles – the sometimes-tricky part!

If you have ever worked with Word table styles before you will know how fiddly they can be sometimes and other times it just seems to work as it should. I’m by no means an expert on the subject but I can at least run through updating a table style with some standard formatting for use in your Axure specifications.

As before, edit the specification by selecting ‘Edit’ from the ‘Word Template’ tab of the specification configuration options.

Create a small table to see your table style in action.


Now in Word 2007, there is a dedicated table ‘design’ ribbon which I’ll be basing it off, but if I have time ill go back and document how it looks in 2003.

Select the table and the ‘Design;’ ribbon should appear at the end of the ribbon.


The currently used table style is selected in the table style pane; right click it and choose ‘Modify Table Style’. This will bring up a similar window the style editor in the previous step, but with some formatting options relevant to tables (no surprises there!).


Have a play around with various formatting options in the style editor and be sure to apply different styles to the different parts of a table using the ‘Apply Formatting To’ dropdown. This allows styles to be applied to headers, alternate rows and columns and can make your tables look very smart.


I normally give the table header a coloured shade, bold/centred text and then give the ‘even banded rows’ a grey-ish fill to make them a bit more readable.

Play around with these until you have the look your after and then save the template again. Generate a new specification to see how it looks with your content and repeat as necessary.

Headers, Footers and Common Elements

Adding automated information to the headers and footers is another good way of adding professionalism and useful context to your specifications. Using Word features like Fields and Quick parks can add dynamic content right into the document without any editing.

Without going into too much detail about use of fields in Word and what not, I’ll just quickly go through some things I add to my documentation templates.

Start by editing the header/footer by double clicking where the header/footer lies. This opens up the header/footer editing pane.


In the above screen I have page number and total page number fields, the document title field and the date field. Ill quickly go over how to add the page number / total page number into the footer as an example.

Type the word ‘Page’ into the footer control and then select ‘Insert Quick Parts –> Fields’


From the fields window, select the ‘Page’ field and choose the number formatting.


That should input the current page number into the footer. Then type the word ‘of’ after it so nit looks like the following.


Then click the ‘Insert Quick Parts –> Fields’ option and select the ‘NumPages’ field and number formatting again.


and it should look like this.


That explains the process of adding page numbers, and its beyond the scope of this post to detail all the useful word tricks and fields, but I might follow up with a more advanced / detailed post on the matter.

Refine and Perfect!

I’ve shown you to how to customise and refine your Axure template to your needs, the next step is to refine and customise the template to your needs as many times as is required.

Once you have a solid base template to work from, it wont take you much to modify it to suit project per project or client per client.

From prototype presentation to functional specification

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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.