September 4, 2017 - No Comments!

Approaching Axure Part 1: What Sketch Users Should Expect

Sketch + inVision are a deservedly popular combo for making hi-fi designs and prototypes.  But I want to wave the flag for Axure RP, a powerful – and so, complicated – prototyping tool.

Axure can take you far beyond simply linking designs together with hotspots to rapidly developing a proper prototype with advanced interactions and functionality.

But all that ability means Axure needs a bit of an introduction for people used to Sketch, and that’s what I want to do here: help you approach its somewhat uninviting experience so you feel happy enough to explore its features a bit more.

This first part is a high level talk through what to expect, in the next part, once you’re prepared, I’ll walk you through a brief example project.

The First Time...

In the summer of 2015 I opened a program called Axure RP for the very first time, failed to quickly make a nice looking wireframe, then promptly closed it.

Today, this almost allergic reaction is what Sketch users suffer when they dip their toe in to the Axure water.

But I am now a seasoned Axure user thanks to a day job making extremely advanced prototypes for companies such as Unilever, so have come to respect Axure as an incredibly advanced tool that shouldn’t be overlooked by designers.

To that end I’d like to offer some quick pointers for users coming from Sketch.

Not so much in-depth how-to’s as an initial translation of things you’re used to in Sketch, and how they work in Axure.

Hopefully this acclimatises you a little bit, calms down your allergic reaction, and so encourages you to explore Axure more in your own time.

For this part I’ll just talk you through approaching Axure so you know what to expect.

In part two I’ll walk you through what we’ve talked about with a brief demonstration project.

First part talk.

Second part walk.

1. From Sexy to Clunky

There’s no escaping the simple, smooth, sexiness of Sketch.

This is Sketch. Just so damn sexy.

The way it handles retina, its balanced interface and its wealth of plugins that expand its power at your control.  Very Apple-y.  Very Sexy.  Deservedly loved by designers.

Axure is made for Windows first then ported for the Mac, and – somewhat ironically for a tool used to create wonderful experiences – it can be an unwieldy and effortful experience.

From resizing the application window to its slightly bare menu bar, you’ll find it lags and is generally a bit clunky to use.

But I’m afraid this is a trade-off we must accept (also they are gradually improving its Mac performance).

Because Axure is so powerful, its interface and experience by necessity have to be a bit complicated.

Put up with its looks to reap the rewards of what it can do.

This is Axure. Very powerful and so a bit clunky.

2. Creating and Previewing

With static wireframes, hi-fidelity mock-ups or even simple prototypes of linked-together screens, you create and judge your work within Sketch.

One moment you’re creating Shapes on your Artboard, then you zoom out to get an overall feel for how it looks before zooming back in for more work.

You both create and judge your work in the app.

Axure is a prototyping tool, with your final interactive outputs used in a web browser (more on apps later).

Because of this, you create your work in Axure but then preview it in a web browser (ideally Chrome).

Create in Axure.

Preview in Chrome.

You create in Axure but preview and judge your work in a browser.

This is fundamental to understand because your Axure project will contain elements that will hide, change size, flip around – all sorts of cool stuff.

In your Axure workspace these will all take on their starting properties for the user’s experience (a hidden box that reveals itself when a button is clicked will just be hidden while you work).

Axure also colours certain elements yellow, pink and blue (I’ll avoid details for now) so that your creative workspace looks very different to the experience ultimately created.

Certain elements in your interface will be tinted and obscured. The browser properly shows the resulting creation.

The only way to preview and judge your creation properly is in the browser.

3. Pages Not Artboards

Continuing with the browser-based output, Axure produces webpages for the user of a prototype to interact with and navigate through – and so you work with these pages, not artboards.

In Sketch you can have multiple pages each of which can house multiple artboards.

In Axure, one page in your workspace equals one webpage in your generated experience.

You don't work with Artboards in Axure, only pages. 1 Axure page = 1 webpage.

A quick note on SVGs and Vectors

With the current Axure RP 8 version, this also means that all assets created and viewed in the resulting webpages are rasterized.

There is a pen tool to create vector shapes, and you can import SVGs, but for the time being these will all be rendered as PNG files in the browser.

For version 9 they are working on creating SVGs, but we'll have to wait and see.

Back to the Axure Page: Absolute Zeroes

Axure's pages and the resulting webpages also means there is an absolute zero on the workspace’s x and y axis.

In your Axure workspace you cannot scroll up below a y value of 0, and you cannot scroll left below an x value of 0.

What’s placed at a certain co-ordinate on a page in Axure will render on the webpage at those co-ordinates.

Your workspace has absolute zeroes in the top left corner. You cannot scroll beyond them.

This also means that the bottom of the created webpages is the bottom of the lowest most element, and you won’t be able to scroll below them in-browser.

There is one caveat here: Axure can ‘centre’ your creation in the horizontal middle of the browser window.

By default it aligns your creations to the hard left of a browser window.  This sucks and doesn’t look nice.  One option (which should be the default) is to centre your creation’s width in the browser’s window.

Axure can horizontally centre your creation in the browser window. Handy!

4. “Adaptive Views” = Responsive Design

On a single Sketch page you may well have an artboard for different browser widths or device screens.  This is nice as one look at Sketch’s canvas shows you the responsive design.

As noted before, Axure makes prototypes that must be used in browser to be understood.

So in Axure’s workspace you create and configure Adaptive Views that are global across all pages.

Adaptive Views are akin to browsers being responsive to different widths.

The method is to begin mobile first, and then you manipulate the same elements to appear correctly for each browser width you need.

No duplication of content and work across multiple artboards.

You don’t use separate pages for separate views, you instead use the same elements for different widths of a page.

Upon previewing this in a browser, as you expand/shrink the browser’s width, you will see the relevant views appear.

You see your responsive views in browser as you change its width.

So there’s the downside of not being able to see all of your responsive designs in one ‘look’, but this is surely outweighed by being able to create an actual responsive prototype with the efficiency of working with ‘one set’ of elements.

5. The Viewport Tag for the Responsive Web on Phones

So far I’ve talked about webpages and browsers for desktop – what about designing for smartphones?  What about crafting pixel perfect apps, not just the mobile web?

Let’s continue with Adaptive Views.

A typical example would be to design three views: mobile, portrait tablet, and desktop.

To put numbers to these views we would have widths for our designs of 320, 768 and 1200 pixels wide respectively:

A basic starting point for different pixel widths across devices.

The trouble today is that the actual pixel dimensions of (flagship) smartphones are two or three times what they were some years ago – while the physical dimensions of the screen have only grown a fraction.

To give you an example, the original iPhone was 320 pixels wide and 2.4 inches across.

The latest iPhone 7 Plus is 1080 pixels wide and 3.07 inches across.

That's a pixel increase of 238% but only a physical width increase of 28%.

TL;DR: Tons more pixels are being crammed in to only a slightly bigger space – but our thumbs and fingers have remained the same size.

So how can we design for an actual smartphone pixel width of, say, 1080px if it makes sense for our mobile Adaptive View to be 320px wide?

The key is the Viewport Tag.

This allows you to design for the smallest of mobile widths (320px) and larger mobiles will display this Adaptive View in the context of their viewport width.

The viewport width is kind of like the ‘sensible width’ – what the pixel width would be without the crazy high pixel density of modern phones.  The sensible width makes sense to our eyes when you compare screen sizes in front of you.

For example, my Nexus 6P has a pixel width of 1440 – almost as wide as my laptop’s screen of 1920 pixels – but my phone’s screen is just under 3 inches wide, while my laptop screen is just over 13 inches!

This all sounds and looks much more sensible if you use my phone’s viewport width of 411 pixels.

Comparing the pixel width and size of my phone vs . laptop doesn't make sense to our eyes. Viewport width is more sensible for us to 'get'.

Turning on the Viewport Tag essentially gets your phone to render the sensible width’s version of your designs.  (Phones with actually sensible pixel dimensions are unaffected and render them sensibly too.)

Your phone will scale up the 320px view to fit its 5 inch screen, for example, rather than rendering a 1:1 pixel view and leaving most of the screen blank.

Turning on the Viewport Tag scales up a 320px design to fit a higher pixel density screen.

This can be confusing to understand, but I won’t try to explain it any further here.

This method works well for prototyping a responsively designed prototype.  Different users can use various devices, or squish the browser to their heart’s content, to ‘get the idea’ of how the final product should respond.

But what if you don’t just want people to ‘get the idea’ – you want them to use a pixel perfect, ultra sharp and good lookin’ design for an app?

6. Apps & ‘Retina’ (x2, x3) – Making Axure Look Good

As mentioned before, Sketch works seamlessly when designing for retina and so making ‘stuff look good’.

This is handy as a UI designer’s job description is apparently something to do with high fidelity designs.

A common complaint against Axure is that it’s really hard to make things look good.

This is kind of true, but remember that Axure is a tool to make prototypes and not to create final design files and handoff assets to developers.

That being said – Axure can absolutely be used for high fidelity app prototypes that do look good on phones, including ‘retina’ devices.

You still create your app prototype with Axure pages, but if you want to develop your experience for previewing on one device only (e.g. my Nexus 6P) then you wouldn’t activate the Viewport tag as described above.

I would design my pages with my 6P’s native pixel dimensions (1440x2560px) and when I view my prototype on my 6P … voila! App screens that fit my phone screen and have beautifully crisp shapes, colours and gradients.

Turning off Viewport and designing 1:1 for a high pixel density device produces crisp images that make 'stuff look good in Axure'.

Of course, the prototype would then not quite fit to other devices, but that’s the trade-off you’re making in designing high-fi for one particular screen.

You may be wondering why you can't just work with vectors and not worry about these rastering problems.

But remember my SVG note above in section three: currently Axure rasterizes all elements in the workspace, even vector shapes, and so you must work with pixels not paths.

So – how do we actually go about getting our prototype on to screens and devices?

7. Sharing Prototypes and Axure’s Output

Axure doesn’t need inVision or a plugin as a method to share your prototypes, it simply has a service and app called Axure Share.

Once you’ve signed up, you can publish your prototype to Axure Share directly from Axure.

You then get a URL (that can be password protected if you wish) to share with colleagues, stakeholders and users.

They can leave comments on a page in general, or something specific.

Axure Share is the easiest way to output and manage your created prototypes.

You can also get the Axure Share app for your phone.

You then view your prototypes through this app rather than a web browser, giving you the ability to hide status bars for a true full screen app experience with no browser chrome distractions.

The companion app is perfect for realistic full screen device experiences.

If your work’s infrastructure allows it, you can also create a full HTML directory for your prototype.

This will create an index of folders and files that you then upload to a place of your choosing, and share that URL instead.  (This option means you can’t use the Axure Share app method on your phone.)


Hopefully this little talk has softened you up and prepared you for what to expect when it comes to approaching Axure for yourself.

It’s not sexy, but it is powerful.

You work in pages to make webpages.

Though you can work with vector shapes, these are ultimately rasterised as PNG files in the browser (fingers crossed Axure 9 allows us to publish SVGs).

Pages can be responsively designed with Adaptive Views.

The Viewport Tag allows you to show these responsive designs properly on phones.

Or you can design with pixel-precision for a certain device and ignore Adaptive Views and the Viewport Tag.

Finally, Axure Share is the service and app that’s easiest for demonstrating your final prototype.

Walking the Walk

In my next post, I’ll put these points I’ve talked about in to action and you can walk with me through the Axure workspace with a demonstration project.

Published by: willjohnsnow in UX
Tags: , , , , , ,

Comments are closed.