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.
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
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.
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:
- 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
Advantage: an overview of all changes – disadvantage: the reader needs to locate each updated wireframe in the document.
- 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.
— 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.
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
Write a short a note for each page: a short descriptive text explaining the essence, the user story, etc.
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.
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
Define consistent shape names; agree upon some convention, e.g.
Define user 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
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
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.
In case of text label or paragraph spanning multiple lines, you obviously cannot set it to auto fitting the width.
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!
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 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
- Define your own Word template, just ensure [[INSERT AXURE SPEC]] is defined in the body of the Word template
- Set to user built-in Word styles to have numbered chapter headings
Thanks to Antoine Wagon @awagon6 to share some great Axure tips & tricks.