Evaluating Axure RP - Talking Points

I'm often asked by colleagues and clients about my experience with rapid UX prototyping tools in general, and Axure specifically. I always preface by saying that I’ve been using Axure as a primary wireframing tool for the past 3+ years, and, although I occasionally evaluate new prototyping tools, such as ProtoShare or Sketchflow , I don’t have the hard-core experience that comes from daily work with a tool.

The landscape of rapid prototyping is changing rapidly, with frequent announcement of new players, some that look very promising. These are very exciting times for our profession because finally, user experience architects and designers can master a specialized UX tool instead of tools borrowed from desktop publishing or app developers.

So one must be open minded to change and to take advantage of whatever does the job. Yet any tool is a strategic investment - of our time, our ability to successfully execute and deliver demanding challenges. In other words - the stuff needs to really work when a large team of UX designers, spread all over the country needs to collaborate under tight schedules. Making things change colors on mouse over is not enough.

So here is a deck I created recently and used in several occasions to help guide an evaluation process. It is of course in favor of Axure, and not because the product is perfect or because the company pays me to promote the product (They don't!). It is their uniquely amazing customer support that won me over.

Download the PDF.


Comments are most welcome. 

Inital thoughts on Agile with Axure

Part 1: 

The Settings (Or, making software is like making sausage - you don't really want to know how it is made, but you should)

Immediately one faces the fact that there are way more flavors of Agile than Baskin Robbins ice cream...So perhaps we should begin with the key drivers that lead to typical UX projects. Typically it is the business side of the organization that drives the change, with IT group either resisting change, locked into a technology flavor mindset (.Net, Java, etc.) and in many cases the communications between the two part of the organizations are poor.There are many exceptions, but I want to address realities of large scale projects. In established organizations, despite the desire to use Agile, there are still hard wired protocols and bureaucracy around traceability, change management and sign-offs.

Axure, like the typical UX team, sits in the intersection of messy cultures and is being used as a communication tool to articulate, 'sell' and specify both vision and reality - this is where some of the key risks and opportunities are for us as UX practitioners. By that I mean that the initial Axure prototype is probably very aggressive about rich interactions, features and functionality.  The business end gets excited because customers who are exposed to the new vision are pressuring for improvements. The sales department is always hungry for a better product to sell.

Thus, strategic plans and budgets are set around unrealistic delivery targets and often, with very little awareness of the full UX development process. In fact, the UX team is often engaged after the project plan, budget and delivery dates were set (What?! we need to pay for usability tests?!). Moreover, large projects are often broken into phases, which means you can not expect a clean process of creating a prototype, finalizing it and go to the beach, because work on following phases often begins before coding of the previous phases ended - which means that everything is in flux, and the Axure file should be well formed to handle change. 

So who are the players, and consumers of Axure output now the the project is in flight?

• The UX team (or perhaps you are a single practitioner) - The organizational association of the team is critical - is the team part of the business unit, or part of the IT organization. I've seen both, and, I've seen the team floating with no clear association, which can be worse.

• The business owners - and depending on the organization, they may be spread all over the US or worldwide, often with conflicting motives and requirements. - The UX team must make sure that UX requirements are captured in a very formal way - Axure can be used for that, but there are some issues around managing the requirements in Axure. While Axure is not a requirement gathering tool it makes so much more sense to capture UX requirements in it that we may get tempted, and have to live with the consequences later on. Not a big deal if we planned for it, a mess if we did not.

• The IT team - In large organization this may be a Hidra, with sub units that are in charge of some aspect of the technology, they may not like each other, or for that matter, even communicate much on a regular basis. And off shore teams are the norm these days, so we have to keep in mind that the output of our Axure project may be consumed by people for whom English in not a native language.

• The BAs - In some organizations each group might have their team of BAs - so the documents that are produced include business requirements and specifications, technical requirements and specifications, etc. The UX team typically adds UX requirements and specifications -- All mentioned are often extremely long documents that none really reads because everyone is busy trying to beat the unrealistic deadlines mentioned above. So an opportunity that Axure affords, is generating specifications that are easy to consume, which s is not so trivial, and I'm looking forward for the upcoming resale for some enhancements. Agile does not mean that specs and requirements are not needed - in fact the issue becomes worse - how to track and mange changes from scrums and sprints such that developers and business partners don't get lost in the sea of documentation?

• The QA team - this team (if it exists beyond being a place holder) has the worst job - testing scripts are often rendered useless because changes happen all the time - so they need to be able to follow up the rapid changes, and update the testing library in time for testing.

This post was originally posted on the Axure Discussion board.

Choosing a Prototyping Tool

It seems that only yesterday the mainstream prototyping option favored by user experience practitioners was Visio. Also common were heated arguments on the greatness of paper, Power Point and other low fidelity tools and techniques as the main prototyping instruments. I recall a 2007 uphill battle with colleagues around use of Axure for a large RIA project, where I was met with skepticism and concerns about the validity of the approach. They favored Visio.

Fast forward to 2009 and there seems to be an influx of new tools and with them, potential possibilities to express ourselves to our colleagues, business and development partners. This trend signals that finally the practice of user experience has matured and is large enough to attract software developers. This trend happened with word processors, desktop publishing, illustration, video editing, browsers, web authoring and many others. Eventually the market settles on a couple of applications that become the de-facto tools of the trade, at least until a game-changer enters the field. From this perspective, Axure is a game changer, emerging when pressures on UX to simulate rich interaction rendered tools like Visio useless.
A few points to consider:

• What is our interest as a professional community? I would argue that as information architecture and interaction design are getting more complex yet deadlines continue to shrink, we want our prototyping tools to be powerful yet easier to use: We need demonstrate our value in expressing complex applications correctly - and fast. The tools needs to handle the various facets of our work products: As we know, there is a lot more to user experience design than just mocking up screens and simulating rich interaction. Our deliverables include extensive documentation that is consumed by a range of stakeholders.
  
  
• Features and complexity. I would argue that the successful tool must be feature-rich and fit the granularity of prototyping throughout the design process. By that I mean that we typically start with high-level concepts - fast wireframes and flows. Gradually and with feedback from research and stakeholders, more depth and details are added to the prototype, including interactions and detailed annotations. While we want to simulate rich interactions, I think that it is desirable to avoid becoming programmers, or at least, minimize the need to relay on a scripting language such as ActionScript or JavaScript. A concern is that the more effort is spent on making the prototype interactive, the less flexible the design becomes because we are getting involved in development instead of design. It is possible to create fairly complex prototypes with Axure without ever using raised events and variables, but these features are available to power users. Few of the new tools offer this flexibility. Finally, beyond dragging and dropping some UI widgets on a canvas and simulate RIA interaction, it is the proven ability to fuse team work, richness of interaction specifications, reuse of visual and interaction patterns (to name some key capabilities) that sets a tool like Axure from the new crop of tools.
  
  
• Proficiency and professional benefits. This is especially relevant to situations where a team of interaction designers is assembled and is required to conceptualize, test and document (fast...) a large, complex application. It makes a great difference if all team members can - in addition to quickly get up to speed on the prototyping tool - master it and maximize its potential. For example, Axure seems to be gaining awareness in the UX community so it is easier to find UX professionals who are familiar with it and can 'hit the ground running' . Another important aspect is that practitioners want leverage expertise gained in one project when moving to another employer or project. If one uses tool A in one project, tool b in another and tool c in the next, there is little benefit in terms of best practice and expertise from a professional perspective.
  
  
• Shared projects, regardless of the prototyping tool, are not trivial and best practice is still evolving as knowledge around this new, emerging capability is spreading within the community. Developers of prototyping tools that do not support sharing miss on the experiences gained from having to deal with the challenges of collaborative work, especially issues that relate to management of assets, management of multiple releases, etc. Keep in mind that implementing solutions into the tool take time and feedback form practitioners - see the list of desired functionality for Axure to get an idea of how much more we want...
  
  
• Cost. As others and myself noted elsewhere in this forum, cost plays a major role for the acceptance and adaptation of any tool. As we know, cost is not just the price of the application, but also the time invested in getting to proficiency, dealing with work-arounds if the tool lacks the features needed, or if it is buggy. There is also an interesting phenomenon with price: If the tool is too inexpensive it tend to be dismissed by IT organizations. From this perspective Axure's price point makes it affordable to single practitioner and also makes it a palatable purchase for large teams.
  
  
• Community and Customer support. Last but not least - The prototyping application and files become critical to our ability to deliver on time. As I wrote elsewhere, the confidence that Axure will respond to an urgent crisis is a major, major point of differentiation for me. I know that postings on this board or direct mail to Support will be addressed. I also learn all the time from reading the tips and techniques that other practitioners post regularly. In fairness to the developers of the new tools, they will have an opportunity to prove their commitment to the their customer base. Ultimately, the success of one tool over another can be often attributed to the strength of the community formed around it.

To be continued here.

This post was originally written as a response to another post in a thread on Axure's discussion board.
---------------------------------
Disclaimer: I am not an employee of Axure nor am I compensated by the company in any way, shape or form. Rather, I have a vested interest in its continued development as an avid user of the application on a daily-basis. (Disclaimer text by Dingle)

Best practice for shared Axure projects

While it is important to develop tool-agnostic practices, in reality we are always empowered and limited by our choice of tools. Although this post references Axure specific functionality it also includes general aspects, the first and most important of which is communications.

Regular and productive communications are the important contributer for successful team work, yet it is easier to say than practice. This is especially true with virtual teams of individuals who work remotely from their homes and on-site teams spread across several geographical locations. But all to often people who are only a few years apart fail to exchange meaningful information.

As much as possible it is important to allocate time for staff development to ensure that all team members posses a level of proficiency that would not only make them productive, but also avoid loss of work due to errors caused by an unknowledgeable team member messing up the shared file. As we know, such calamities tend to happen just before a major deadline.

1. Team members should understand how to work with shared projects. All should be comfortable with the various options under the 'Share' menu and the difference between options such as 'Get all changes..." and "Get Changes...", for example.
2. New team members should have an on-boarding deep dive session with a knowledgeable team member to cover the structure of the sites. In large, intense projects new members are often thrown in to the cold waters of a shared project file to sink or swim because the team is at the height of some crunch. disoriented and under pressure to get up to speed asap, the incoming member can be easily lost in the intricacies and work-arounds.
3. All team member should participate in a weekly status meeting that covers the structure of the sitemap, variables (since those are global and limited) and other important changes. Use web sharing to view the file, make sure that members understands the composition structure of their colleagues.
4. Despite looming deadlines...it is important to be careful and pay attention before checking in and out. A few seconds of concentration can save hours of lost work.
5. Team members should avoid unsafe check outs -- checking out pages that are already checked out by another team member - this is critical.
6. Before you begin work on a page, make sure to 'Get ALL changes from shared directory' - this will insure you have the latest copy.
7. Update your file frequently by getting all changes.
8. When done editing a page or master you checked out, check it in so that it will be available for other team members.
9. Check out only what's needed for your design work, check in as soon as done and check out the next chunk you are going to work on: Avoid hogging files you are not working on but still checked out.
10. If possible, structure the sitemap and masters in sections such that team members can work on chunks of the file in parallel. Agree on unique page and master IDs and a naming convention to help team members access the right files and communicate.
11. Make sure to back up the shared file.

Note: Sections of this entry was first published on Axure's discussion board, but I had requests to post it here.

Disclaimer: I am not an employee of Axure nor am I compensated by the company in any way, shape or form. Rather, I have a vested interest in its continued development as an avid user of the application on a daily-basis. (Disclaimer text by 'dingle', a frequent contributer to the Axure discussion Board)