The Blog

Prototyping: Axure vs. Rails

In my quest to conquer the prototyping arena, I’ve met a tool called Axure a couple of times now. Since I want to do prototypes using my favorite tool, Ruby on Rails, I thought I’d better check out Axure to see what the competition is.

I’ve tried to compare the two approaches and line up the pros and cons in the context of the other. Here’s what I found:

Axure Ruby on Rails
  • Scoped documentation(1)
  • Commonly used (known and tried)
  • Little technical skill required
    • drag and drop
    • standard elements
  • Reusable prototype (html, css, js)
  • Real interaction with real data
  • Proof of concept on key features
    • data harvest and integration
    • real, branching workflows
    • search and faceted navigation
    • data aggregation
    • relational mapping
  • Throwaway prototype(2)
  • Time consuming when high complexity/fidelity
  • Requires programming/specialist skills

(1) Axure has a neat set of documentation features, providing context and team scoped documentation – notes can be attached to each element and marked with eg. “customer” or “developer”. Nice – I might have to come up with something to counter that.

(2) I heard that Axure can actually export html/css, which means that the development phase could benefit from reusable design/markup elements. So I downloaded a trial and made a quick prototype, consisting of standard elements. I then exported it to look at the generated html. All very easy. But the generated html/css was worse than I had feared. A mixture of upper- and lowercase tags with a ton of inline styles and all positioned using inline-styled divs with a transparent image inside. I was choking. No competition there at least.


First and foremost: there’s something more general in this comparison, than just Axure vs. Rails. I think it’s safe to substitute Axure with more or less any of the commonly used wysiwyg wireframing tools out there today. Likewise, it’s not a matter of Ruby on Rails rather than any MVC web programming framework (you could use web2py if you’re more of a python kind of person). So the comparison could have been named “Wireframing tools vs. MVC frameworks”, but it’s much more fun to pick on specific tools than giving a generalized criticism of something no one really relates to.

There is a key parameter, that the comparison does not take into account. And that is the time used to build a prototype. I have no evidence giving me any foundation to compare time consumption between the two approaches. It’s a pity, because that is what it comes down to in the end: the cost of the prototype.

That said, I think there is a tipping point around the complexity of a prototype, where Rails seems to be the better choice, when enough complexity is added.

Leave a Comment

Let us know your thoughts on this post but remember to place nicely folks!