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.

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)