How to prototype Axure complex form behaviour

Modular event-handling in Axure with nested conditions

There are quite some reasons not to prototype complex user interfaces
and use code instead. But since not everyone is able to code (fast),
Axure is trying to solve this gap by providing a prototyping software with a
basic scripting language that is meant to be used in a visual way — by
selecting the interface elements you have built and adding some logic that is
triggered by events like clicking or scrolling.

Unlike other prototyping software, you are able to use variables, conditional
logic, math, functions, and expressions within Axure — which makes the
learning curve pretty steep for beginners if you like to do more than just
wireframes. On the other hand, you can achieve another level of
interactivity with advanced input handling like form validation, text
recognition or calculations. There are only two problems: first, the logic is
bound to a visual reference. You cannot define functions that can be called
from multiple points within your application. This is crucial for forms that
trigger complex functions like field combination errors or a submit action
that validates a complete form. Second, you cannot nest conditions. This is
again crucial for validation patterns with multiple, dependent factors like:

  1. A field must not be empty.
  2. If 1.) is true, check if the maximum amount of characters is not greater than

The only solution so far is to use the built–in event–handling mechanism in
combination with isual code blocks. Sounds strange? It might be if you look
at it for the first time, but the results are pretty amazing in terms of
maintenance, scalability and prevention of code duplication considering the
restrictions of Axure.

Nested conditions

Wen you are prototyping complex validations and their display
options, you will probably be dealing with form components. And in
most cases, it will be an input field that brings along a set of rules and
restrictions. The real fun begins if several input fields are dependent from
each other — meaning if you you type in something in one field, the other
field might be invalid. That is one of the cases where nested conditions come
in handy. Let′s have a look at Axure:

In this simple example, we have two cases when clicking on an interface
object, e.g. a button: we validate an input element if its input is not empty
and if the input is less than five. If the input element is not empty, it
becomes blue. If the input is less than five, it becomes red. Now let′s have a
look at the second example:

The code is the same, just the order of the cases is different. What will
happen in the first example if we type a “3” in our input field? It will become
red. What will happen in the second example? It will become blue. Axure
chains cases (which are kind of a function with an optional condition) and
that creates an unwanted level of complexity we don′t like to deal with. Until
today, constructs like nested cases which would solve these kind of problems
are not available in Axure. It could look like this:

But there is a workaround — we can fire an event within the same case that
targets a different location: a visual code block!

Visual code blocks in action

Enough theory, lets get our hands dirty and build a real prototype in
Axure (you can grab the Axure file here). The inputs are material design
form components
with a basic address validation pattern:


  • Must be a number
  • Must be exactly 5 characters
  • Postcode/town combination (if both field are not empty)

  • Postcode and town must match (postcode must be “80539”, town must be “Munich”)
  • Form (on submit)

  • Postcode must not be empty
  • Town must not be empty
  • Postcode/town combination must match
  • There must not be any error

Here is how the Axure file looks like:

Screenshot of an Axure project with a form and visual code blocks

And here (link to Axshare) is how the form looks like in action. The
demonstration is split up into two parts: field & fieldset errors on the left,
global form errors on the right.

The idea behind visual code blocks is not new if you think of Quartz
from Apple or VVVV. For Axure, there are some approaches with
Dynamic Panels
, but to create “clean code” (within the scope of Axure) and
remove duplicate code as far as possible (keep it DRY), we need a different
approach. Think of visual code blocks as functions that are triggered by
events of the user interacting with the prototype. Unlike binding the logic to
the form components, it is outsourced to a dedicated block that can be
triggered and chained from multiple points — that is exactly what is
currently not possible in Axure. To provide some guidance, the visual code
blocks have different colors and labels, each dedicated for a special intent:
TRIGGER, CHECK, SHOW, HIDE. Basically, this pattern follows the object
oriented pattern (splitting display and logic) and the delegate event model
(having event sources and event handlers/listeners)— again, all within the
scope of Axure, which is quite limited.

Example of visual code blocks

Visual code blocks in detail

Before going a bit deeper, let me tell you that visual code blocks are just a
pattern. You are not bound to the naming, colors or functionality. You are
free do adopt the idea of externalizing and nesting logic in Axure — that is
what visual code blocks are all about: a convenient workaround.

The magic begins when you trigger an action in your prototype (here:
OnLostFocusof the postcode input field). Instead of listing the actions within
a case (here: Field not empty), another event (here: OnClick) is fired at a
visual code block (here: postcode errors).

Triggered event on a visual code block

As you can see in the next screenshot (TRIGGERs in green), according to the
postcode validation pattern defined above, besides setting the error message
to default or “”, the postcode field is validated against a postcode length error,
a postcode number error and a postcode town combo error pattern on other
visual code blocks (CHECKs in red). It may seem a bit complicated at first to
externalize the logic in another visual code block for each validation — but
as such, you are able to trigger the validation patterns from other triggers,
e.g. when validating the complete form on submit.

TRIGGER postcode errors block

Each error validation block contains the logic, in this case a numeric
validation pattern. If the validation pattern does not match, an error is

CHECK postcode number error block

To externalize the display logic (SHOWs/HIDEs in purple) to separate visual
code blocks seems again complicated, but you will benefit from kind of a
model/view/controller principles (without the model) where you can trigger
and control the view from any location in your prototype.

SHOW postcode error block

You can see that it makes sense for the following example (postcode town
combo error) when you have to define logic for more than one form

CHECK postcode town combo error block

With the visual code block pattern, you can achieve complex conditional
logic in Axure. Nevertheless, take care that Axure is a prototyping tool that
is not really meant for this kind of complexity — and that you should discard
your prototypes as soon as possible and replace them with real code. Just,
you know, there′s not always a developer around…

Pro tip while exporting or previewing your prototype I am pretty sure you
want to hide the colorful visual code blocks. Instead of hiding each block
with Hide when the OnPageLoad event fires, just group all the blocks
together and Hide the group. That′s it.

Happy prototyping!

If you enjoyed this article, please recommend below. And if you have any questions, please let me know!

Original post you can find here:

Social Share