Mobile prototyping - dynamic panel or pages


I am currently building a prototype for mobile where I am using one page with a dynamic panel and a state in it for each page. I will have quite a lot pages in the prototype - about 30 pages.

It is easier for me to build it using one big panel since there is no reloading (=data gets reset) + it’s a faster experience and more mobile like experience for the user.

But will the amount of pages and content make it very slow?

Also, I need to have a functioning “back”-button which is easy with different pages, but is it possible with a dynamic panel instead?

Most threads I’ve read about this topic seems to be about panel being more complex to build - this is not the case for me and no issue. So what I’m wondering is if this will be to slow at the end and if back-button is possible to solve.


Having done both, here are my thoughts on this:

  • Using panels instead of pages can be super fast and seamless if you don’t have a lot of a states.
  • 30 detailed panel states (“pages”) will probably be slow, your prototype will take some time to load.
  • If you use panel states the phone’s/browser’s back button won’t work. You’ll have to implement your own back button (track panel state and dynamically set the panel back to the previous state if not linear progression through states).
  • While ugly, using pages will probably be faster and load times will be spread out over the interaction with the prototype, instead of a huge load up front.
  • The page might also just be slow and janky if you cram all that on one page.
  • How complex is your prototype? If 27 of 30 of your pages are nothing more than text then using panels is probably fine. If every page is a complex workflow then pages might be better.

Judging solely on the “30 pages” requirement, I’d say don’t do panels, but it’s possible you have other requirements that would make dealing with the panel states headache worthwhile (lots of data and state to preserve, for example).


Thanks for the answer, it’s really appreciated!

  • Back button this will be a problem anyway right, unless I make all 30 pages into different pages (which is not possible, both due to loading times and data would be to difficult). I have a built in backbutton on some pages - this button will need to go to different pages depending on where the user comes from.

  • You write “instead of a huge load up front”, does this mean panels are mainly slow at first load but gets faster after that? The prototype will be used for usability testing and only from one phone if that makes any difference.

  • Fairly complex, each page has different content with interactivity and buttons - not much text.

  • The purpose of the prototype is to explore the navigation - there’s a lot of going back and forth between pages, and lots of exploring meaning that it’s important the switching between pages is fast (many different routes to take)

Many thanks,

Yes, the back button will be an issue anyway if you’re trying to preserve state with global variable because of how Axure handles globals. Using the back button would cause you to lose state in many cases.

As for up front load, I mean that if your entire (giant) prototype is on a single Axure page then that page will probably take noticeable time to load when first opened. It might even still be slow to use afterwards.

Sounds like in your case using panels for pages will be easier (but will still probably be challenging).

Pages for main screen, Internal screen can be dynamic panels