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.


Replicating AJAX-style lightbox within Axure prototypes

In a post the other day I detailed how to replicate the always popular AJAX-style autocomplete functionality within Axure. In a similar vain, I wanted to replicate another popular AJAX-enabled function, the ‘lightbox’. Lightboxes are becoming increasingly popular on the web and by doing the legwork up front, you can easily drop a lightbox widget into your prototype to quickly demonstrate an idea to a client.

For those who aren’t familiar with the term lightbox concept, it is based around magnifying a thumbnail image to a larger, viewing-friendly size, while also hiding the background content from view. An example can be seen below.


The image has been enlarged and displayed within a dark frame to bring out the contrast of the bright image.

Modern web lightboxes also have gallery-style navigation controls built into the image to allow scrolling through a series of images with a ‘forward’ or a ‘back’ arrow. This way you can stay within the enlarged lightbox view and navigate through an entire album of images.

All of these functions are incorporated into my Axure widget, including the all important ‘close’ button and done in a user-friendly way that replicates modern design standards.

Let us begin

Now that I have set the scene, let us delve into how to build the widget in Axure.

First we need a placeholder page to store the thumbnail images and I like to add a few other page elements to make the demo look a bit nicer. My demo page looks like this:


See nothing too flashy; just a set of three thumbnails, a title and introduction.

Next we need to drop on a dynamic panel which will hold our lightbox and fill our viewing window. This needs to overlap the whole page and be brought right to the front (right click panel –> Order –> Bring to Front ).

This panel will be blank by default (i.e. not shown) and then a state for each image you require. In my example above, we require 4 states ( default + 3 image states).


Leave the default blank and open up the second state which I’ve named ‘display image 1’.

This state should have the same image as the thumbnail in the centre of the screen, at a size almost filling the screen (from top to bottom). Then use a rectangle shape with a fill colour of a dark grey or something similar all around the edges of the image. It should look like my example below.


You cant see it in the above screen but I have another dark rectangle shape below the image as well, in the same proportion as the top border.

Repeat this for the other two panel states, but changing the image to the relevant thumbnail image.

The flash part – navigating through a lightbox gallery

While the above may be sufficient for your needs displaying a single image at a time, most lightboxes out there in the real world have controls overlayed over the images to navigate.

To replicate this in Axure I have used a few tricks to capture the rollover action and display a button only on rollover – just like you’d find on the web.

First, if your using Axure 5.6 like me, your able to use a brand new feature of this build called ‘Slice Image’. Now you can slice an image within Axure without having to resort to cutting up your image in a photo editing tool like Photoshop or Paint.NET.

To do this, right click the image within the first lightbox state and select ‘Edit Image –> Slice Image’. You should be presented with a crosshair style cursor which to use to carve up your image into sections. For our purpose, we want to split it right down the middle, leaving a little section at the top (the reason for which will be revealed shortly).


I also split the top right ‘section’ of the image in half vertically again, but that isn’t required at this stage (or easily done at the end).

Now what we have is essentially four separate images, where we can assign different behaviours to each.

What we want to do now is give each section a different rollover image that is the same image + an icon overlayed. That icon will either be a ‘forwards’ arrow, ‘backwards’ arrow or a ‘close’ symbol depending on the section of the image. The fourth section can just be left blank or assigned to another action I haven’t thought of!

Making the rollovers

At this stage you might be worried that making these rollovers is a bit tricky? Not at all!

My process for adding an icon and setting it as they rollover is easy. All you need is the ‘Axure Icon Library’ available from the resources section of the Axure site and an image editing tool like Photoshop or the freely available Paint.NET (I use the later for licensing reasons!)

Now I drop the icon on to the relevant part of my image and copy both the icon and the base image to the clipboard and paste them both into Paint.NET (or your preferred tool – MS Paint works fine). Your ‘paste’ should look like the following.


If you look closely, you can see the blue arrow to the left of the image. Save the image as a .JPEG and return to Axure.

In Axure, setting a rollover image is easy, and seeing as we have made it already, we just need to point to it and its done.

Right click the relevant section of the image and click ‘Edit Image –> Edit Rollover Image’

Select ‘Import’ and choose the image you saved from the previous step.


Using the ‘preview’ option is a good way to make sure everything lines up correctly.

You need to repeat this for each image, so that each lightbox image has three rollovers – forward arrow, back arrow and close. I use the following icons from the Axure Icon Library.


Once all of the rollovers have been added, its time to add some actions to them so they become useful.

Adding actions to the rollovers

We have the lightbox, we have the rollover images and finally we need to make those buttons we added actually DO something.

Achieving this is not as simple as I had hoped but wasn’t long before I figured out a way.

The complexity comes because  the button is only on the rollover image and as its not in a dynamic panel, there isn’t a way of assigning it an action. We also want to only perform the action on the ‘click’ action not the mouse rollover, so I needed a way of mashing the two together

Luckily Axure provides us a workaround in the form of variable.

I created a variable called ‘RollOver’ and the idea is that when the Rollover action is fired, the variable is set to ‘true’, and when ‘false’ when it isn’t.

Then on the click action, create an event to change the panel state to the desired action (either return to hidden, show image 1, 2 or 3) BUT with the condition of RollOver=’true’.


Lets walk through it.

On the image section your working with first, assign the following action of the ‘OnMouse’

Set the variable RollOver to ‘true’ (a condition is not required for this action)


Now that the rollover status can be captured, we can assign an event to specifically the rollover image with the button.

Create an ‘OnClick’ action for the same image section as before, but this time give it a condition and an action. The condition will check to see if rollover is ‘true’ then change panel states to the relevant state.

Mine looks like this.

The condition.


and the action.


The above action is for the ‘next’ button of image 2, so the logical action is to display the panel state for image 2. The close button should always return to the default (hidden) state, and the previous and next buttons should move logically to the correct image in the order.

Ultimately you will end up with three rollover images per image, each assigned an appropriate action. Repeat the above step for assigning an action to the rollover for each of the 3 sections, for each of the images (or lightbox states).

My screen flow looks like following.

image image

Start with the thumbnails                  –> Show lightbox with first image and next rollover

image image

Clicking next icon displays image 2        –> Clicking next again displays image 3.


Notice the ‘close’ symbol in image 3, it closes the lightbox.

There is one other action you should add for the sake of completeness and that is setting the rollover value to ‘false’ again for the ‘OnMouseOut’ action. This will be disable the click event when the rollover is not shown. I won’t detail how this is done – if you’ve made it this far it should be fairly intuitive as to how to do this – if not ask me to add it in!

All finished!

There we go, all finished! As with my other AJAX-replicating widget, all the work is done up front and only needs to be modified with different images / rollover images in order to customize this to your prototype.

I have this widget as part of my custom library and just drop it on to a project as necessary. I have even found it useful when in interactive sessions where I drop it on to a page to illustrate a discussion point or design concept.

Hope you found the above useful and as with my other AJAX-autocomplete, I have not uploaded the .rp or .rplib files but can do if anyone requests.

I’m working on a Axure AJAX-toolkit for various widgets so will bundle them together and offer soon!

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.