I was recently asked by a potential customer to compare Axure RP to comparable products, and in my response I described some of the principles on which we base our design and marketing decisions. I thought it would be a good first blog post to share those with you and provide some insight into the type of products and company we are building.

Here is an excerpt from my response:

Axure RP was designed and developed with a focus on building a usable tool that would make it easier, faster, and more effective for people to do their work. This applies not only to our customers, but to their customers and the people they work with as well. This is reflected in features in Axure RP including the familiar interface, masters (references and templates), wireframe editing features, and support for viewing prototypes in popular browsers without a player.

We also want Axure RP to be easy to adopt and used widely across a large user base because we believe this will add value for Axure RP customers and help us make it a better product based on a larger set of customer experiences. Our focus on easy adoption can be seen in things like our try and buy model, the low learning curve, the price point, and support for generating the specification with versions of Word down to 2000.

This is contrary to some traditional RM solutions that are frequently viewed as difficult to learn and use and oftentimes sold through a sales team to management and then rarely used or used begrudgingly by the team.

We also think that each piece of the solution should be available separately and work together seemlessly. The initial release of Axure RP contained project info, requirements management, flow diagramming, interface design, prototyping, and specifications. What we found was that although the integration was attractive, each piece was not necessarily the best of breed and the flexibility to choose a preferred tool for each task was important to our customers.

And finally, we think managers and teams should have the freedom to define the process that works best for them and for their specific projects. There is no one process that works for every team and project, and the tools should not impose one. If your project requires flow diagramming, then do it, if not, then don’t.

For future posts I plan on writing about prototyping, other process topics, and product plans... tune in!