Using Axure RP to Combat Low Fidelity Impotence

Most stakeholders suffer from a condition known as low fidelity impotence. Kyle Adamo shows us the cure, creating a charting prototype along the way that's sure to impress.

Alt Desc

Building chart prototypes is often tedious

Ever had to create a performance dashboard for a group of stakeholders? This was precisely my task this last fall. Using Axure RP and Google Charts API, I was able to create an interactive prototype that helped our team iterate towards a more informed solution.

Most designers might sketch a static mockup and call it quits but I – like many stakeholders – suffer from a condition known as Low Fidelity Impotence (don’t worry, it’s not as bad as it sounds). People with Low fidelity impotence have difficulty understanding designs without an interactive prototype. In other words, they need to know what’s behind every link or button and they get hung up on the lack of ‘sexiness’ in the prototype.

In my case I needed to build a prototype of a performance dashboard portal for our flagship application. Stakeholders needed this dashboard to:

  • Display pie, line, column (clustered and stacked) charts.
  • Display mouse-over hints on chart elements.
  • Provide a method to change chart metrics.
  • Provide a method to change the chart type where practical.

We also work at breakneck speeds, which meant that I needed to get to realistic ‘sexy charts and graphs’ as fast as possible.


I could accomplish this in a number of ways, however, first I always find it important to consider how this prototype will get used. I knew we’d use it in design meetings and to communicate functional requirements to developers as is usually the case. As well, because this is a charting tool, we desparately need to test the viability of the design on real life data. Beyond that we’ll also use it to further refine the sales pitch, value prop and leverage it in marketing teasers to get the customer base excited.

To build something like this in a condensed timeframe is a tall order. I’m lucky enough to be in a position where I have a keen sense of what the market needs, what works for our typical customer data, as well as the limitations of our development budget and skill set. I thought it prudent to take this opportunity to evaluate a charting/graphing technology that we might use when we get to the development stage.

Our application currently uses SSRS (SQL Server Reporting Services) for on demand reporting, so I knew enough about SSRS to rule it out as not being sexy or responsive enough for a dashboard like this. I really wanted the visuals of Highcharts JS but I wasn’t really sure where to start as a non-coder. I’d been reading recently about improvements to Google Charting and Visualization API so I decided to take a look. I eventually chose it because:

  • It’s free. You can’t beat that.
  • It’s publicly accessible.
  • It’s well documented.
  • It can easily connect to google docs data sources (important for building data-bound prototypes).
  • It has a ton of charting options The ChartWrapper class was helpful for a non-coder (hack) like me.
  • If it was eventually chosen for development of production application, leveraging the ever evolving and improving google ecosystem is probably a good move.

Putting the Pieces Together

After reading up on the API and spending some time browsing though their playground, I formulated a rough stategy on how I would use this, along with Axure RP to do my bidding.

A Quick Note About Axure RP

For those unfamiliar with Axure RP, it is a robust software prototyping tool capable of web, desktop and mobile prototyping of any level of sophistication and fidelity. I consider Axure RP a tool for non-coders. If you are skilled with html, javascript, and css, I wouldn’t bother learning Axure unless it is a job requirement. Often, after struggling to force Axure to emulate a common web interaction I often think ‘Why don’t I just learn to f#$%ing code!?!?” Basic application functionality is a snap in Axure, but it becomes increasingly difficult the more dynamic the requirements or your app, such as drag and drop, self healing lists, expandable and collapsible panels etc. All of the modern ‘ajaxy’ web interface stuff is possible with a large upfront time investment, and subsequent prototypes will benefit from the reusable widgets you can create. Any graphic resources that you’ve built in Photoshop or Illustrator are easily imported into Axure, however, from what I can tell, Axure RP creates no reusable code. I gravitate to Axure whenever static wireframes will not do justice to the concept, when the actual interaction with the application is the most important part of the design.

Now lets move on to the rest of the steps in creating this prototype.

Alt Desc

Publish Google Docs spreadsheets

Creating Google Spreadsheet Data

Being able to create live data in a standard google docs spreadsheet was critical for testing the google charts applicablity within the context of our software prototype. While browsing the google charts api, I knew a chart could use a spreadsheet, sub-sheets and cell ranges as a data source so long as it was published. I created the spreadsheet, with smartly named sub-sheets with each sub-sheet representing a variation on the chart widget data. Some sheets were to analyse costs, some were for labor time, some contained monthly trend data etc.

Chartwrapper with Remote Data

Now that I had my data, I could use the tools available in the google code playground to generate html code to render these charts. My assumption was that each sub-sheet in my google spreasheet would require a separate HTML file to render the chart in an Axure Dynamic Panel State. I got to creating my html files with names matching my google docs sheet names.

Alt Desc

Configure your html files to connect to the published spreadsheet data

Creating Axure Dynamic Panel States and Inline Frames

Axure uses something called Dynamic Panels to which you can add items, states and assign properties. In web development terms, a dynamic panel would typically be a div. I built each of my dashboard widgets as a separate dynamic panel, with a panel state representing each chart variation I wished to emulate. For ease of maintenance, I ensured these state names matched my HTML file names mentioned above, as well as the sub-sheet names in my google spreadsheet.

Now, each panel state needed to contain an Inline Frame (iframe) referencing my external html files. I was able to use some of the On-Click Case logic in Axure to define pick list values that would immediately trigger the chart to change as though it were a working application.

Alt Desc

Axure panel states contain iframes referencing the chart embedded html

The Build Out and The Pay Off

I’m a religious time tracker, using a tool called Grindstone 2 to help me understand where my time goes during each day.  I broke this prototype into the logical sections inside Grindstone, and here’s the breakdown:

  • Research: 4 hrs – this included researching charting apis, learning about the capabilities of googles api and learning how to hook this up to spreadsheet data.
  • Building Chart Data: 1.5 hrs
  • Creating Basic Prototype: 6 hrs
  • Creating Dynamic Events to Update Charts: 4.5 hrs
  • Fine Tuning/Revising Prototype: 4 hrs

At about 20 hours to research and build, the end result, turned into a reasonably high fidelity, scalable, data bound prototype which serves countless purposes for our team of stakeholders. Using this prototype we were able to refine the design by identifying ways to streamline much of the interaction. We’ve since moved the date range picker to a 3 part toggle type button containing the most common date ranges – 1 month, 3 months and 6 months – rather than having the user pop-up a modal window to modify that.

Because of the realism provided by this prototype, we’ve been able work with clients to elicit their perspective on our value proposition for sales and marketing, and most importantly we could easily express the required behavior to our development team.

The biggest problem with this prototype is the need to constantly remind our internal team that “This is still fake software, remember?

Axure RP Prototype Using Google Charts & Visualization API

Lead photo by MikeLove

About the Author

Kyle Adamo

Kyle Adamo is obsessed with the web, as well as being the VP of Product at Windmill Software in Toronto. Their flagship web and mobile app, TheWorxHub, is used by thousands across North America and the UK. You can follow Kyle on Twitter as @drawtheweb


  • Avangelist Reply

    being a daily user of Axure I think it is an over-rated and overly cumbersome tool for building prototypes.

    I do have a coding background on a front-end level and I would much prefer to build simple frameworks that I could build my prototypes into the only good part of it for me is that it allows you to document the parts of the prototype with extensive information but that is only of use if you use those tools within your company.

    It’s a little like photoshop – the average person uses 10%

    • Kyle Adamo Reply

      I can’t disagree with you there. Axure is often cumbersome, especially for modern web UI patterns. For a non-coder like me, I’m pretty diligent about building widgets that are generic enough to be reused in other projects. Also, Loren Baxter’s blog provides many downloadable widgets that people might find useful. The amount of time invested in building those widgets was likely significant, but highly valuable to future projects.

  • Petar Subotic Reply

    Well, your high-fidelity prototype is of basically one screen and I must say I love all the rich interactions. However, imagine advocating this approach to someone who is building something much more extensive, like an entire system.

    Problems with that scenario are as follows. First and foremost, Axure is just too slow. Yeah, you can import masters, set dynamic … blah blah blahs, but no way man, just too slow on development, revisions ( . . . ). And you can’t even re-use the code? Boo! Okay you’re not a coder, so that one can slide.

    Fidelity levels to some extent come from knowing your audience and their expectations, granted you were probably presenting to some big-wigs, so all the interactions and pretty colors can be justified.

    However, prototypes are… well prototypes, they are incomplete, sketchy versions of the final product. They don’t need to be high-fidelity, they are not meant to.

    But what if someone clicks on a part that hasn’t been built out yet? Huh? Well, nothing happens! It’s a prototype. If they want to explore features that are not yet built out, remind them of expectations and use the opportunity to explore how the users envision the particular pattern or behavior.

    As far as your “biggest problem” : did you “prime” your audience?

    • Kyle Adamo Reply

      In a perfect world (which I rarely live in) prototypes are sketchy versions of the final product, however, there are numerous reasons why that sometimes doesn’t work:

      – If there is no money for development, and you need to impress the person controlling the purse strings, be it a CEO, VC or partner

      – In cases where stakeholders suffer from low fidelity impotence, as was my case

      – When you’re selling vaporware. This happens, especially in the enterprise space where the sales cycle is long. Prospects can, and will, pre-purchase or agree to not buy a competitor until you’re done development. Having a slick prototype is often the only way to keep them engaged

      Of course I always start with balsamiq level mockups, or hand-drawn components, but those are mostly for my eyes only.

  • JAllen Reply

    Excellent example! I recently ran into a similar need and was able to marry the Google tools with the Axure inline frames. It was a fortuitous find. I agree with you, though. The more rich and robust the interaction of the prototype, the more you might as well just code it.

  • Brinda Reply

    Learn all about Mockuptiger you can host it on your domain, desktop, switch between hand drawn look, change fonts and prototype dashboard mockups with data.

  • Matt Reply

    I recognise this affliction, I am a fellow sufferer.

    The cure, I have found, is to be really honest with yourself about the likely benefits of persisting with an Axure prototype, relative to spending more time communicating your intentions by other means and/or just getting someone else to code it for you.

    Any really complex interaction or flow is almost always likely to be more efficiently prototyped using actual code than Axure.

    The wisdom of setting out to prototype in Axure has a definite outer edge of reason. Beyond it, you’re just trading time and efficiency for retention of control.

  • Nora Reed Reply

    Very nice n very informative article. i would appreciate this all writing. thanks for all this sharing :)

  • Caroline Reply

    Kyle, have you checked out They offer UI libraries that are low fidelity and high fidelity so you can choose your poison :) You can switch from wireframes to pixel perfect with just a few clicks and make the prototype interactive. They’re not a tool but complement to Keynote, PowerPoint, or OpenOffice. Very popular among entrepreneurs because of the high fidelity aspect you talked about, but also because there is no code required to make them interactive.

  • Eric Reply

    Kick-ass use of Axure!

    Although I agree with some the comments regarding Axure’s limitations, I think that they are far too negative and miss the value of this tool. It fits perfectly in my own workflow between sketches and final comps/actual code. It gives me the ability to spread-out designs across each page’s massive canvas, allowing for very quick iteration and comparison between design options or design states.

    And as you’ve noted, there are many stakeholders who need to “see it to believe it”… They won’t invest development time unless they are sure that it feels right.

    With help from your tutorial, I’ve pulled a proof-of-concept together in <1hr! I can't wait to dig in and start to make it look more polished, like yours. Thank you so much for the inspiration, Kyle!

    • Kyle Adamo Reply

      Thanks for the feedback Eric. Have fun prototyping! The new Axure beta looks even more promising as well.

  • Abhi Reply

    Great example.
    But How did you get the Chartwrapper reference to your iFrame? I see you directing it to dropbox? I couldn’t really get that part.

Leave a Comment on This Article