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.

Updated – AJAX-style autocomplete v2 .rplib available for download

I’ve had lots of positive feedback around the outcompete field for Axure RP and as promised I have packaged up into a master .rplib file for easily dropping on to your prototypes.

The updated version has a nicer transition and rollover effect and uses the name ‘Davidson’ as a base for completing the name (i.e. type ‘da’ and watch the suggestions menu drop down).

Download the following link and load into Axure:

AJAX-style auto complete file .rplib

Load into Axure via the ‘Widgets’ pane and selecting ‘Load Library’ from the drop down


Locate your file and then you should see the widget available in your Widget pane.


Drop that on to your prototype and away you go.


Using raised events for mixing up your masters

I’ve been playing around with making my current prototype more usable and dynamic in the last few days and have come across a cool but not well documented feature of  ‘raised events’. Essentially it allows you to add flexibility to your master’s in able to change page by page, and allow you to capture events fired inside a master (im sure there are more/better uses of raised events!)

I want to quick run through my scenario to demonstrate how you can capture an event within a master and apply it at the page level.

First up I have a ‘Logged in user’ style master consisting of two stages of dropdowns for  logged in user and ‘company’. Ultimately what I want to demonstrate is when I select a new option from the dropdown list (held inside a master)

Without this notion of ‘raised events’ there is no way of capturing the ‘OnChange’ action for the dropdown within the master, on the page you want to update.

Let me demonstrate with pictures below:

The user select’s his company from the following dropdown (which is contained within a master

Choosing an option for this drop down changes the text label with the selected option – pretty basic web application behaviour.

So changing the drop down changes the value of the bold company name in the text label above.

All of this seems relatively easy so far, but because the drop down is stored in a master within axure, there is no way of accessing the ‘OnChange’ variable from within the page (and therefore no way of telling when the user changes their selection in the dropdown.

The way of getting around this to use a ‘Raised Event’ within the master, which creates an action that can be captured on each instance of the page.

Let me demonstrate. First let’s show the page in the axure workspace.

The pink (red-ish?) section indicates the dropdown part is contained within a master; the rest of the page is directly editable.

So because we want to capture the action of user selecting a different option in the dropdown, the only we can do this is within the master itself, NOT the page.

Now we cant access the text label on the previous page within the master (and we may wont do different things on different pages), so we need to create a ‘raised event’ to capture the value of selected option and store it in a variable.

Add a variable (I call mine ‘selectedEmployer’) from the ‘Manager Variables’ option on the ‘Wireframe’ menu.

Now we have a variable, we can store the value of the selected dropdown option when the ‘OnChange’ action fires.. and also fire the special ‘Raised Event’ action so we can call it from our pages.

Alot to take in? Lets walk through it.

For the ‘OnChange’ action of the drop down list (within the master),  add an interaction case, and switch to advanced view (can do in basic view, but screens reflect advanced view)

For the action we want to do two things: captured the value of the selected dropdown value and store it in our variable AND fire a ‘Raised Event. The two actions in Azure you need to do this are:

‘Set value of variable and widget value(s) equal to value‘ AND

‘Raise Event’

First, set the variable to the selected dropdown value.

The logic should be fairly straight forward but is shown above for reference.

Next we need to create and fire a ‘Raised Event’

All we are doing here is creating an event that can be captured when the ‘OnChange’ fires, as we have no way of capturing the ‘OnChange’ action when we leave the master. Confused why we need this? All will be revealed when we try to access the action next.

Head back to the page we are working on and select the dropdown master within the page.

We can see the name of the ‘raised event’ we create and fired in the previous step (mine’s called changeEmployerName)

Now all we have to do is get the value stored within our drop down and do what we want with it on the page.

So within the ”changeEmployerName’ event, we want to create an action with the following condition:

‘if selected option of Log on Bar/Employer dropdown equals “[Value]”‘ – obviously changing [Value] to the appropriate value for your context

What you do once you have the value is up to you, I normally set the state of a dynamic panel show the result on the page, but there are many more applications.

Hope this helps when trying to make your prototypes more dynamic and like-like!