Axure RP: Lego For Software Designers

Someone asked me on Twitter a little while back:

@dylanbeattie Do u currently use Axure? If so, could u pls tell what size team it's effective with? And, is it really better than pen-paper?
11:38 AM Nov 7th from web in reply to dylanbeattie

The short Twitter answers are “yes”, “we’ve used it effectively with up to 4 people”, and “yes, because I can’t draw” – in that order.

But a slightly more detailed response would probably help.

Once upon a time, prototyping web apps was easy. You’d draw every page, and then use a site map to demonstrate which links went where. Every page was static; nothing moved, there was no Ajax, no infinite scrolling, no drag’n’drop, and most websites were actually about as interactive as a Choose Your Own Adventure novel. Well, those days are gone. People expect more – richer UIs, better responsiveness, less postbacks and waiting around for pages to load – and with libraries like jQuery, there’s really no excuse for not delivering code that satisfies those expectations.

Question is – how do you prototype a rich user interface? How do you draw a picture of something that won’t sit still? For me, that’s where Axure RP comes in. Axure is a “tool for rapidly creating wireframes, prototypes and specifications for applications and web sites”. It’s a commercial product, so it is, alas, not free (although to put it into perspective, it costs less than hiring a .NET developer for one day) – but it is a uniquely powerful and expressive piece of software that I find myself firing up on an almost daily basis.

In everyday use, it’s like a weird cross between Balsamiq, Visual Basic, and Lego.

• Balsamiq, because it’s easy to mock up static user interfaces by dragging buttons, inputs and form elements on to your page.
• Visual Basic, because it’s easy to add behaviour to those elements using click handlers, events and dynamic controls.
• Lego, because it’s intuitive, and it’s fun, and there is no way anyone is going to look at what you’ve done and think the project is finished.

The game Populous was designed using Lego. I grew up with Lego*. From a very early age, I learned to use Lego bricks to express ideas. I knew every single brick I owned. I could demonstrate an idea I’d had for a car, or a spaceship, or a robot, by assembling these reusable components into a prototype with spinning wheels and moving parts and a sense of scale and colour. Working entirely in plastic bricks actually become very liberating, because it stops you worrying about materials and finishes, and allows you to focus entirely on expressing ideas.

Have you ever showed someone a Lego house and had them say “Hey, that looks great! When can we move in?” No. People know a Lego house is not a real house. They appreciate that the point of a Lego - or cardboard, or clay - model is to demonstrate what you’re planning to do, not show off what you’ve already done.

Have you ever showed anyone an HTML mockup of a web app and had them say “Hey, that looks great! When do we launch?” – and then they look horrified when you explain that you haven’t actually started the build yet?

People don’t grok the difference between HTML mockups and completed web apps the way they grok the difference between Lego houses and real ones. I can’t say I blame them. HTML is HTML – whether it was hacked together late last night in Notepad or generated in the cloud by your domain-driven MVC application framework. The difference doesn’t become apparent until they actually start clicking things – by which point it’s too late; you’ve made your first impression (“wow, the new app is done!”) and it’s all downhill from there.

I think the hardest questions in software are “what are we doing?” and “are we done yet?”. I think good prototypes are absolutely instrumental in answering those questions, and any tool that can help us refine those prototypes without falling into the trap of “well, it looks finished” has to be a Good Thing.

* Some people look at how much Lego I still have and conclude that I never grew up at all…