Axure tips to create wireframes, prototypes, and user interface specifications

Axure RP is a wireframing, prototyping, and specification software tool aimed at web and desktop applications.

This article descrbies some tips to productively use Axure.

Common Axure library (and use of masters)

It’s interesting to provide an Axure file containing a repository of commonly used layouts, elements, flows, default dialogs. Make the Axure file available to the team via your document/filesharing tool. Authors of wireframes can use these elements to compose their wireframes / prototype.

Axure master elements

Axure master elements

You can define the items in the Axure file as a master element. Choose the appropriate drop behaviour for each master:

  • Place Anywhere:
    The elements defined in the master are fixed, but a user can place the master anywhere on a page
  • Lock to Master Location:
    The elements defined in the master are fixed and the location of the master on each page is fixed
  • Break Away:
    The user can change the elements defined in the master and the user can place the master anywhere on a page
Axure master drop behaviour

Axure master drop behaviour

The granularity of the content of the master will determine the drop behaviour:

  • You can define a master per UI element
  • You can define a master for a group (e.g. a page layout, heading, body, footer, etc.)


  • When defining a separate master for each individual UI element you can set the drop behaviour to “place anywhere
  • When defining a master for a group of UI elements, such as a page/screen layout, heading, footer, you can set the drop behaviour to “lock to master location” – as these elements typically have a pre-defined location (make sure the location is correct in the master with respect to the page).
  • Note when user should be able to change the content (e.g. the text label), you should set the drop behaviour to “break away” (otherwise users are not able to customize it). Of course, users must apply some discipline to not alter the composition and the positioning of the individual elements in the master.

Axure Team projects (+ versioning control)

In case you have a team collaborating and working simultaneously on same Axure file, it’s recommended to use a concurrent versioning control system. In case you don’t have this available you can choose for a versioning control of the Axure files on a file/document management system.

Versioning of Axure files

Versioning of your Axure files can be achieved using any common document management tool (e.g. SharePoint). In this way different versions of the file are kept – take care this concerns a version of the whole Axure file – meaning when you want to revert back to an earlier version of a specific element or page, you will need to manually collate old and new.

Note regarding management of Axure files on SharePoint. We have noticed you need to manually check-out your RP file before you can open the file directly from SharePoint in Axure. Avoid keeping and working on a local copy! When done with the modifications manually check-in the file.

Sharepoint check-out

Sharepoint check-out

Keeping track of changes in Axure files

It’s always interesting to have an overview of the changes in the wireframes available in the Axure file itself. This overview can be part of the Axure Word export.

There are 2 approaches:

  1. In the beginning of the Axure file add a page with a table detailing each update. Set the width of the table to more or less match the width of a default text document. Break the table at the row where you want the table to continue on the next page. Fill the table with useful info, e.g.:
  • Date of update
  • Description of changes; referring to the wireframes names/titles
  • Author of update
  • Review/approval of update
Axure table change log

Axure table change log

Advantage: an overview of all changes – disadvantage: the reader needs to locate each updated wireframe in the document.

  1. At the level of each wireframe, add a page note to describe any changes done on the wireframe. You can create a custom page note field “Change log”, this will appear as a separate subsection for each wireframe in the Axure Word export.

5 page note - add change log  5 page notes - change log

— Axure page change log

Advantage: the changes are described on the level of the wireframe – disadvantage: reader needs to scan the full document to find all updates

You can combine both approaches; and use a common identifier to trace the changes; e.g. the date of change with an additional ID. In this way, the reader has an overview of all changes in the general table and a wireframe-specific trace of the change per wireframe. Of course, authors of wireframes will need to exercise some discipline to consistently describe the changes.

Annotating wireframes

The objective is to correctly, consistently and concisely make notes on the wireframes.

We most commonly annotate all the on-screen elements and the user actions.

Sometimes it’s also required to additionally annotate:

  • On-screen text labels (in a specific language)
  • Analytic tags

Page note

Write a short a note for each page: a short descriptive text explaining the essence, the user story, etc.

Page style

Set the default page style. A practice is to avoid any visual design elements in wireframes. Set the font to a neutral font and font style (not bold, not italic) and set the page color to black & white.

Axure page style

Axure page style

Axure default page style

Axure default page style

Customize fields

Axure customize fields

Axure customize fields

Define custom widget notes fields (and group these in a set if applicable) as required. Remove fields you will not use. (click on “Customize” in widget interactions and notes)

Consistent shape names

Axure shape names

Axure shape names

Define consistent shape names; agree upon some convention, e.g.

  • Button_
  • Title_
  • Subtitle_
  • Headline_
  • Copy_
  • Link_
  • Checkbox_
  • Radiobutton_
  • Module_

Define user interactions

Axure widget interactions

Axure widget interactions

When creating an interactive prototype, you are defining the interactions using the widget interactions given in Axure (OnClick, etc.)

In case the output format of the pre-defined interactions is not sufficiently explanatory, write a user action description in the field “description” or in a custom-added field “user interaction

Annotate elements once

No duplication of the same annotations on multiple pages: annotate elements only once in a logical order. Elements defined in a master should be annotated in the master.

Annotate different states

When applicable define different states using dynamic panels; or simply describe the different states in the page.

Renumber all footnotes on each page

Axure renumber all footnotes

Axure renumber all footnotes

This option ensures a top-down incremental footnote numbering. Apply this option whenever necessary (e.g. before exporting). This option needs to be applied per page.

Widget property: Auto fit width and height

Axure widget properties and styles

Axure widget properties and styles

In the pane “Widget properties and Style”, enable the option “Auto Fit Width” and “Auto Fit Height”. Otherwise when not fitting the width and height to the element, you will get unnecessary floating footnote numbers – as illustrated below.

Axure floating footnote number

Axure floating footnote number

In case of text label or paragraph spanning multiple lines, you obviously cannot set it to auto fitting the width.

Axure text without autofitting width

Axure text without autofitting width

Screen-size responsive

Axure (since v7.0) has the possibility to define the layout of the page/screen for different screen sizes. In case of responsive design (web or app); always use this feature!

Axure adaptive views

Axure adaptive views

The advantages include consistency of annotations, forced to adhere to responsive principles, automatic export of different screen sizes.

Define the adaptive views – apply the mobile (phone) first principle:

  • Take portrait phone as the base
  • Define additional views such as tablet landscape and tablet portrait – set these views to inherit from base or otherwise as fitting your needs
Axure responsive landscape tablet

Axure responsive landscape tablet

Axure responsive portrait phone

Axure responsive portrait phone

Axure responsive portrait tablet

Axure responsive portrait tablet

Axure Word export

  • Pages: select page or “Generate all pages”
  • Adaptive views: select views or “Generate screenshot for all views
  • Widget tables: select fields to be part of the table. Add new tables if you want to list separate tables containing specific fields

    Axure widget tables

    Axure widget tables

  • Define your own Word template, just ensure [[INSERT AXURE SPEC]] is defined in the body of the Word template

    Axure new Word template

    Axure new Word template

  • Set to user built-in Word styles to have numbered chapter headings
Axure word export

Axure word export


Thanks to Antoine Wagon @awagon6 to share some great Axure tips & tricks.

Displaying a sprint planning using a Gantt chart

Displaying a sprint planning using a Gantt chart

Gantt charts have been invented and developed by Henry Gantt in the 1910s. These charts became more widely used by the US military during the Word War I. Project managers typically use Gantt charts to visualize the project planning, it visually shows the start and end date of tasks, plus any dependencies. A Gantt chart greatly visualizes how project phases or tasks are to be executed in consecutive order – of course certain tasks or group of tasks can be executed in parallel.

My eyes hurt when I see project manager visualizing an incremental and iterative project using a Gant chart.

It looks like this:

gant chart

What do we see?

  • Iterations have a fixed duration (by definition)
  • When iteration A ends, iteration B starts (by definition)
  • The schedule pre-defines X number of iterations (unknown by definition – unless you need to meet a fixed deadline)

It gets worse when the project pre-defines the scope of each iteration – clearly not the intention. The team (together with the product owner) defines and selects the content of the iteration (sprint) during the sprint planning; the team will define the tasks to achieve and construct those items.

I believe the common preference by the community and teams is to visualize tasks and dependency using a visual board (on all levels: team, release …) and burn-down charts as information radar to communicate progress.

I stumbled upon this article entitled “How to use Gantt charts for your agile project”.

Do you use Gant charts in your projects?

Daily (stand-up) status meeting = GIFTS

Daily (stand-up) status meeting = GIFTS

Een dagelijkse status meeting maakt inherent deel uit van het Scrum framework. Ook zonder toepassing van Scrum, is een dagelijkse status meeting heel nuttig. Andere benamingen voor de status meeting zijn: “huddle meeting”, of kortweg: “daily”, of “stand-up”. In het Scrum framework is de officiële benaming: “Daily Scrum

De objectieven van een dergelijke dagelijkse meeting zijn het bespreken van:

  • De stand van zaken van het werk
  • Verbetering van het team
  • Communicatie in het team bevorderen

Kenmerken van een dergelijke meeting:

  • Frequentie: dagelijks (dat is de gewoonte)
  • Tijdstip: wat past voor iedereen in het team (op zich in het tijdstip niet zo belangrijk, dit kan elk moment van de dag – zolang iedereen aanwezig kan zijn)
  • Duur: maximum 15 minuten is een goede duur tijd. Het is belangrijk dat de deelnemers niet afdwalen naar het vertellen van een verhaal, of het bespreken van oplossingen. Te lange conversaties of het langdradig vertellen, moet men op een vriendelijke manier een halt toe roepen. Het verduidelijken van een vraag of onderwerp kan natuurlijk wel. Het feit dat mensen blijven rechtstaan, zorgt er voor dat er blijvende aandacht is en de voorziene tijd beter respecteert. Een facilitator kan in het oog houden dat de meeting telkens tijdig start en eindigt.
  • Locatie: zo dicht mogelijk bij de locatie van het team (indien er mensen op afstand participeren – kies een vergader locatie met de noodzakelijke communicatie middelen: tele-conferencing, video conferencing)
  • Wie neemt er deel? Iedereen van het team. Iedereen is verondersteld spreken. Een facilitator kan in het oog houden dat iedereen aanwezig is in de meeting. Een facilitator kan aanduiden wie er spreekt, of we passen een sequentiële spreekvolgorde toe, of een random spreekvolgorde (vb. door een balletje rond te gooien). Een random spreekvolgorde verhoogt de aandacht van de aanwezigen 🙂 en maakt het leuker.

Er zijn vele interessante technieken – tips & tricks om een dagelijkse status meeting levendig te houden; een interessant artikel hierover is dit: “It’s not just standing up

Een volgend acroniem is leuk om de essentie van een dagelijkse status meeting te vertellen:


Good start

De meeting is een goed begin voor het team – een goed begin van de dag – uiteraard als de meeting ’s morgens plaatsvindt :-). De meeting mag geen dagelijkse sleur worden of het aframmelen van de status. De meeting dient energie te geven! Een boost om de dag te beginnen en nieuw inzichten in te behandelen problemen of taken.


De doelstelling is verbetering. Verbetering van het werk dat het team levert, verbetering van het functioneren van het team zelf. Het zeggen van problemen, zonder effectief naar oplossingen te zoeken heeft weinig meerwaarde.


Focus op het werk, niet zozeer de mensen. De doelstelling is om de status van het werk te (gedane werk / werk nog te doen) bespreken, niet te focussen op de activiteiten van elk individu.


De status meeting is een meeting voor het team om zichzelf te informeren en beter te organiseren, het is absoluut geen rapporteringsmeeting! Vermijd dat een manager de meeting als een rapporteringstool gebruikt.


We bespreken de status van het werk en eventuele problemen of belangrijke zaken. Dit wordt typisch gedaan door het beantwoorden van 3 vragen per individu:

  1. Wat heb ik gisteren gedaan?
  2. Wat wil ik vandaag doen?
  3. Wat zijn de problemen die ik heb die me belemmeren om mijn werk te doen / taken af te handelen?

Een suggestie is om team members eerst de 3e vraag i.v.m. problemen te laten beantwoorden – zodanig dat hier voldoende aandacht aan gegeven wordt.

Visueel board

Een aanrader (must-have) is een board om zaken visueel bij te houden. In zijn eenvoudigste vorm maken we een “improvement board”, die de besproken problemen lijst. Vervolgens dient het board om bij elke status meeting de problemen te herhalen en te zien of er voortgang is voor een oplossing.

Een andere vorm is een planning / taken board. In dit geval zal het board alle taken weergeven met hun huidige status en eventuele problemen.

Voor het opmaken van een taken board, verwijs ik naar dit artikel met voorbeeld.