User interface/experience practitioners come in many flavors. There is no standard certification or professional accreditation that can help a client determine who is a truley qualified UX resource. While you will not take on an uncertified architect to design a skyscraper or your home, the evolution of user experience as a discipline matches other segments in software design, where a degree is not the only measure of expertise and skill.
However, there is also an aspect that relates to the technical skills we bring to the table. For someone who is only versed and comfortable with wireframing in Visio, developing an interactive prototype in Visio, will be a challenge.
Of course, it is a lot easier to create such a prototype in Axure. However, should you embrace this tool? It is best to avoid heated tool-camp loyalty arguments, as the answer typically boils down to a strategic business and professional decision:
Are you a single user? Perhaps an independent consultant, or the single UX practitioner in an organization? In this case, you need to consider the cost of investing in the tool, and the return on your investment.
Think about the projects you have created so far with the tool(s) you have. Is there a gap that you need to fill?
Axure is becoming a good skill to master. Will learning the tool open up new opportunities?
What about the cloud-based services for which you pay a subscription? Certainly, it is a good idea to review the option. However, the thing to consider here is that many corporations may frown upon having their strategic plans placed on some cloud. Moreover, firewalls and other security barriers may make it difficult for stakeholders to access the work.
Are you a member of an interface design agency, or in an in-house design team?
What are the challenges of running a shared Axure project?
What kind of training is needed to level the team's prototyping skills?
What are the project opportunities that open up with using shared project and the efficiencies, savings, and increased profits in terms of re-use of widget libraries, masters and generators?
I have asked a few colleagues to share their honest perspectives on the use of Axure. I think you might find Katrina's and Saikat's account very relevant to your experience. Here are Katrina Benco's thoughts:
I used Visio for a long time before using Axure. The thought of switching tools was a daunting, but enticing proposition. I started using Axure with an open mind and haven't looked back. It has a small learning curve and is continually proving itself as a clever and useful tool.
One way Axure has supported my design process is its flexibility for documenting highly complex or configurable systems with a rich, interactive UI and layers of business rules. The mechanisms to prototype also allow me to document and annotate the different states of the wireframes in an object-oriented manner. I can use dynamic panels and masters to show different states in the UI not only based on interaction, but also business rules, roles, configurations, etc.
My primary use of Axure has been to design and specify wireframes and generate printed wireframe specification documents for the developers, not to do prototyping. However, Axure's prototyping features have reshaped my design process in two ways:
I can quickly prototype an interaction and test it out myself. There is nothing like trying on your own design for size. I prototype my design concepts to pitch them to the business and tech folks. Seeing concepts in action is a powerful way to show design concepts and gain buy-in, or to sell one design over another.
My suggestions for successful adoption by a large UX team are to:
First, have best practices for using the tool in place to ensure everyone documents their wireframes in the same way. Second, take advantage of the masters to globally spec as much of your UI as you can and to share design patterns.
And here are Saikat Mandal's thoughts:
Axure is an amazing prototyping tool. It can be all-inclusive tool for a UX designer. It helps you ideate; create bubble diagrams, flow diagrams, sketchy-low fidelity prototypes. Where it is hugely helpful is its capability to make high fidelity prototypes, which can mimic the actual system at quarter of its cost and time. This is not just a tool for the designers but also for the whole team, which includes Project Managers, Business Analysts, developers and even the Quality Analysts. Rapid visualization gets all these team going. They now don't have to wait for the other team to pass the ball.
The beauty of all complex things is its simple structure (I am reminded of Clarke's Law: Any sufficiently advanced technology is indistinguishable from magic.) Your work just gets done like magic and you don't even have to think of the mechanism behind it. (Disclaimer: Sometime this can set wrong expectations at workplace ). The Layout is similar to a website. A simple structure which tells you that there is a website with simple three pages. A common man can make a website and have a web presence. It does not need any prior knowledge of website building. Simple knowledge of hyper linking will get a person going. You can then make it more complex based on your need.
There are some challenges to Axure's adoption. Most of the design fraternity has grown up using Adobe suit and Dreamweaver as prototyping tool. Thus adapting to a new product that does things differently can be a challenge in the beginning. The other disadvantage is that Axure does not have the capability of layers . Layers in Axure can add whole new meaning. This will make it closer to Photoshop and can have the versatility of Auto Cad.
However, there are ways to customize the dynamic panels to behave as layers. So an advanced user, familiar with layers can modify dynamic panels and get it to perform the functions of layers.
'Nomenclature' is another problem. Naming widgets and panels correctly and reusing them as masters is the crux of Axure. Unique Ids can be separated from a class of object by naming objects properly. A new user without guidance will not get to know the pattern and thus there needs to be some scaffolding to help them. The good news is that a user has complete ability to customize the system. Thus giving tremendous power to the user.
Overall one tool doing so much is in itself a marvel. It has its shortcomings but the team behind it is doing a tremendous job of mitigating the problems. Axure is a powerful tool, which can make wonders when used correctly.
I asked Alfred Kahn to share with us his insights, based on his experiences with the previous version of Axure, while leading a large UX team on a complex project:
Create a new, consistent, unified design for the J.P. Morgan Treasury Services portal, using a large team spread across three locations.
My team consisted of 12 designers divided into four workstreams, each responsible for a different part of the design: Portal, Payments, Information Management and Standards. Each workstream had a lead responsible for overseeing the design work and ensuring that the workstream's designs complied with the standards that were developed over the course of the project. The Standards team was responsible for maintaining the User Experience standards and reviewing each team's designs for compliance.
Based on prior experiences working with standards that were developed in the abstract, I established an iterative process that would enable us to evolve standards organically. Our standards were derived from solving real-world design problems specific to the context and the domain in which we were working. Each workstream had an ownership of the wireframes for the screen designs in its area of the portal and published its own specifications. The specifications were consumed by the product and tech teams (BSAs, architects, and developers) for that area, but starting with the initial designs, we identified common functionality and created a set of standard patterns that were then used in all wireframes.
Each of the three specifications included a "Globals" section, maintained by the Portal and Standards workstreams, containing specifications for widgets used for common functionality. As a result of this approach, the Client Experience team became the central point for maintaining consistency across the entire portal project in terms of both design and requirements.
Axure was the easy choice as the primary design tool, to a large extent based on its shared project, masters, and UI specification generation features. Had we used any other tool, the project would likely have required at least 2-3 additional designers to just support distribution and integration of common design elements.
After the design of the first release was done, we explored ways to integrate the functional specification content into Axure, in order to provide a single point of reference for the developers building the application. We piloted and then rolled out a process whereby the Business Systems Analysts (BSAs) would enter their content into the shared Axure file in a separate set of annotations through a customized view. The BSA annotations were published in the UI specification in a separate table following the annotations entered by the Client Experience designers.
This approach was limited to those parts of the functional specification that related to the UI, but provided a single point of reference for the developers building the user interface. It had the added benefit of lowering the overhead around maintaining consistency between the functional specification and the UI specification; prior to establishing this process, the Client Experience and the BSA teams spent a significant amount of time reviewing each other's documentation to make sure that they were in alignment and that there were no conflicts.
There were two main features in Axure that helped ensure consistency of the design across the three workstreams: the shared project and custom widget library features.
The shared project feature enabled the team to use the same set of masters, which meant that we could centrally update designs common to all workstreams. The custom widget library provided designers with an easy option to use widgets that complied with the standards. We regularly re-factored the custom widget library to reflect modifications made to the user experience and the visual design standards, so that they always had an up-to-date version available to them. Other Axure features that helped streamline the design process were:
Access to wireframes across workstreams: As every designer had access to every wireframe, they could easily refer to another team's design to prevent duplication of functionality and drive consistency across the application.
Wireframe categorization and navigation: We used the tree in Axure's left navigation to categorize our many wireframes. Each team had a node, and as we had established a numbering and naming convention for wireframes, masters and dynamic panel states, it was easy for us to find each other's wireframes.
Page Notes: These enabled us to provide a categorized overview of each screen, and the sections we established within Page Notes served as a template to prompt designers to enter critical information.
Integrated specification generation: It drastically reduced the overhead related to maintaining the UI specification, especially as we ended up with multiple versions of each specification related to point releases. Had we been forced to use a separate tool for managing and generating the UI specifications, it would have doubled the level of effort for the project, at the very least.
Restore feature: On a number of occasions, Axure's restore feature saved us many days of rebuilding screens. Coupled with the fact that the subversion instance was backed up centrally, we were able to reduce our file management overhead as well.
The single biggest downside to using Axure (Version 5.6 and earlier) on a project of this size is that the project file got extremely large, creating significant latency in checking files in and out. It was not unusual for it to take up to 5 minutes to check a screen in or out. This was a source of frustration for the team and became a drag on productivity.
An easy way to mitigate the check in/out latency would have been to break the file up into separate projects for each workstream. Unfortunately, Axure does not have an "include" feature; there was no way to store, maintain, and share common elements outside of the main project file. For this reason, we maintained a single project file and lived with the frustration.
While we loved the custom widgets library feature, it didn't update when the library modified; each time we updated the library, it had to be published and imported manually. It would have been much better to be able to push custom widget library updates out to all designers automatically, through the project file.
The functionality associated with the Specification Generator not as robust as other features, however, Axure was very responsive to our feedback. We sent the company a list of new features and upgrades that we thought would significantly improve the utility of Axure for us. When we met to review the list, we indicated that the Specification Generator feature upgrades were of the highest priority for us (Axure 6 addresses many of those requests).
Despite all of these issues, Axure was a huge boon to the project. Given the scale of the effort, if we had not selected Axure as our design tool, each workstream would have required an additional designer just to manage the distribution and integration of the common design elements, significantly adding to the overhead of the project. After leading a team through the design of four releases using Axure as our design tool, I think we made the right choice, and would do so again without hesitation.
The following are some tips that should help you get the most out of using Axure on a large project:
Axure can promote, but not enforce, consistent design; ensuring a consistent design still requires a governance process
It is critical to construct wireframes properly and consistently across all teams
Create a naming convention for wireframes and dynamic panels; validate proper naming during governance reviews
Agree on a common structure/organization of wireframes and enforce that organization across all teams
Allow time to train new users in the finer points of using Axure
At the beginning of the project, pilot a number of ways of using masters and dynamic panels, and then settle on a common approach; validate the implementation during governance reviews
Be sure to bake time into your project plan for maintenance of the Axure file:
Refactor the project file at strategic points in time—between completion of wireframes and writing the spec, and after the completion of a release
Plan to have one wireframe structure for prototypes and another for specifications