Ildikó Balla is a UX consultant currently living in Sydney, Australia. She has over six years of experience working on mobile, web, and desktop applications ranging from simple sites to complex back-office solutions and e-commerce platforms, and experience in establishing and leading a small team of junior interaction designers. Specializing in interaction design and medium-fidelity prototyping, Axure has been Ildikó's tool of choice for the past five years.

Ildikó is currently working for reInteractive (www.reinteractive.net), Australia's largest Ruby on Rails-focused development company. She is in charge of requirements analysis, information architecture, interaction design, and user testing for complex web applications and business intelligence solutions.

Some of Ildikó's short articles about UX, interaction design, and prototyping can be found on the company's blog. She is a regular attendee of AxureWorld and similar Axure- and UX-related events. She was the technical reviewer of Axure RP Prototyping Cookbook, John Henry Krahenbuhl, Packt Publishing.

In her spare time, Ildikó is often found taking pictures, travelling, riding, and learning new languages, though usually not all at the same time.

On one of my projects, I was the lead of a small team of three additional junior interaction designers, who were also not familiar with Axure. So I had to quickly share from my experience in both UX and the tool. Another challenge was the limited ability of some members in the team to communicate in English when it came to writing clear annotations.

The team was required to annotate the wireframes, and these annotations were later consumed by Business Analysts (BAs), who generated more extensive specification documents, and stakeholders through the HTML prototype.

Early on, we had to get to an agreement on how much to annotate, and who will write and review the annotations. It was important to provide the client with a consistent, fluid level of writing, and given the language challenge mentioned earlier, the majority of the task was assigned to one team member who was assigned the writing. As mentioned earlier, because BAs were assigned the task of writing the extensive specification documents, the agreement was that the team provides only light annotations, and the workload on the person was manageable.

To support team collaboration, we used the Shared Projects feature (renamed Team Projects in Version 7) from the get go. With help from the company's IT team, we were set up on the company's own SVN server, and we were supported by IT throughout.

I am a proponent of naming conventions and implement and use them. I encouraged my team to use the scheme, because it can save a lot of time in the long run, especially when trying to guess what things are or do. But, I ended up not enforcing it, just because it was difficult to govern on top of all the other things I had on my plate.

The prototype we were expected to deliver did include the visual design, but the interactions were in high fidelity. The way we split the work, each team member owned a set of pages in the file and was responsible for building the interactions on these pages.

We would have documented our code, if there was a way to do it in Axure, to add comments to interactions. Instead, we tried to use very descriptive names. But when it came to global variables, for example, we had a challenge. Because each team member was creating variables as needed, and because it is not possible to document variables (owner, purpose, and so on), the list of global variables mushroomed with redundancies and abandoned variables, but no one knew what they were and where they were used. Everyone was afraid to delete variables in case they broke something, somewhere in the prototype.

With each team member owning a chunk of the prototype pages, we had obvious style differences. Some were careful about alignment and measurements and some were more loose in their treatment of the layout, distorting images instead of fitting them, for example, use of line width, and so on. This created consistency issues. We did not initially have a widget library, but we quickly started using masters, as I wanted to ensure that consistency does not get out of control. We also incorporated the style guide, which was mostly textual, as a master in the file.

Susan Grossman is a well-seasoned enterprise consultant who usually works under titles like Senior UX Analyst, Interaction Designer, or Technical Trainer. She has actively used Axure at a variety of corporations, working with their teams' nuances and processes, through many diverse projects: waterfall, agile, or lean. An avid all-inclusive web proponent, Susan volunteers to help nonprofits improve usability and meet accessibility. She works out of her California Gold Rush foothills home with a Rhodesian Ridgeback at her side.

When using Axure in an enterprise environment, shared projects online and outside the firewall are a must. I can't imagine going back to working without one.

There are several repositories out there that allow you to set access permissions on different projects and maintain version control. One of them is Beanstalk, which keeps an activity log by project, supports grouping projects in separate repositories, has e-mail notifications, and prominently gives the subversion URL to use the first time you "Get and Open" a shared project. The ability to assign users to specific projects with separate URLs for retrieving is a must for busy UX teams. For me, it emphasizes teamwork, even when you're working remotely, and you see all those check-ins with comments in the main area and everyone with permissions in the right column.

Whatever repository you use, being able to add notes for every check in and downloading any past version are expected features. I like being able to get a past version, save it off locally as an .rp file and pull in older pages from it. When business asks for something that was removed in a previous release or an idea that wasn't used before, which could work now on a different screen, this comes in real handy.

Since Axure allows you to choose what pages to generate, some teams will set several cover pages in the prototype. There will be one cover page for the business that will always get published as the root or top-level page. This page explains what you're showing and gives details on what a wireframe is, what it does and doesn't include, and any disclaimers you may need about pages using screenshots from existing live sites, the look and feel of being in the comp part of the project, and what it means to be sketchy.

The second cover page is never published and is strictly for passing along information to someone who may pick up the project a year later. This is a significant time saver when looking up things, such as who was on the initial project, a summary of the main requirements, and nice-to-haves that are on unpublished pages for future releases, including in past versions, and so forth.

You don't have to create your own repository or install and maintain one. I'm a remote contractor for a large corporation, have been remotely contracting for quite a few years, and depend a lot on discussion.

A lot of companies use an online bug tracker, or put their knowledge base outside the firewall, and it makes sense to do the same for your shared Axure projects. They need to be accessible no matter where the team members are, and without relying on logging in and going through a network first. When well utilized in a collaborative team project, your files get pretty large, cumbersome, or completely unreachable if the network has issues. Even if the team is all onsite, there are often things that must be done in the evening or over the weekend when going back to the office isn't possible.

The repository must allow you to set different levels of permissions. Even when we're all pros, someone will accidently delete something, relocate to another project, or make some mistake wherever possible. And like Murphy's law, it will happen right before an important presentation of the work to business sponsors. At the minimum, you'll need roles for a limited number of team members who can administer (add/delete), an overall owner (or super admin) who can add users and assign administrators, and finally, users who can check in and out of a project once it is set up.

It's important to have a process to use Axure-shared projects that the UX team follows. These include how they deal with the repository, how they add/remove pages in the site map, what masters must be used, when to create new masters, and how to display interactions and roles.

Before starting work on an existing project, always get all the changes from the shared directory or there's a high probability of overwriting someone else's work. No exceptions.

Before generating a prototype, even if done to quickly show something, always get all the changes from the shared directory or there's a high probability that you may show work that's no longer valid. Again, no exceptions. I've seen this happen both with the site owner questioning why they're seeing something they thought was changed, or ended up showing something that has been scrapped.

Never use the Check out Everything option unless you change something on every page. Also, inform everyone else working on the project. There's nothing more frustrating than trying to fix something late at night and finding it checked out to an unreachable teammate who wasn't even working on that page. Pages should be checked out as determined. They then need to be edited in Axure using the option Check Out.

You need a process to check-in—some teams request that every night a check-in is done, both for versioning and a record of progress in the check-in notes. Others assign specific sections and request that they aren't checked in until the section is ready for its first review. This works fine as long as any new masters or changes to masters are coordinated. This is really a choice determined by the number of people working on the project, and how fast the turnaround is.

One of the reasons why past versions should be saved and made easily available is file size. Often, multiple candidate wireframes exploring possible interpretations of the requirements are set up as root-level pages. Some of these pages are removed over time to reduce the file's size and its complexity. If all alternative interactions for all versions, including their notes, are retained on a large project, they become difficult to sync and pull down without crashing or not completing them on the standard issue company laptop.

Saved versions or past versions that can be easily fetched from the repository will allow you to import a style or concept down the line when the business remembers something they saw early on and think that the current requirements could use that treatment. It's also not best practice to leave all the pages in, even if they aren't published. A team member could unknowingly build the project and set pages that the business has decided against generating, causing invalid feedback, and making you look bad.

It's important to know and consider all your team mates' systems. If someone was issued with an older laptop, though you may have no problems uploading and retrieving a large project, if other members are unable to get the project running without errors, or crashing, timelines will slip. It's important to remember that this isn't an issue with Axure itself, but the systems using Axure and getting projects from a shared, external repository.

As mentioned previously, initial versions of the wireframers' early interpretation of the requirements are set up as root-level pages. A lot of projects name their screens by the initial requirement feat, use case number, or user story name, depending on the company. Under each named version, there are sets of the same child pages (name and data) showcasing the style of the version.

For a simple example of initial concept versioning, one version may be a tabbed or panel experience, another maybe a dynamic version with a section of the page changing based on choices, the final version showing highlights of everything like a dashboard. It's important that each child of these different flows' names would reflect the parent version for easy referencing in remote meetings.

For clear directions to those creating the comps and then relating the full experience to development, dynamics can sometimes add an unexpected kink. In a project that has several roles accessing the same pages that were shown different sections and/or possible data sets, we chose to display the role in Axure dynamic. When generated as HTML and demoed, we entered the screen as the core user, and there was a mini dashboard in the top corner that was not part of the flow. It allowed us to switch to the other roles by selecting the role name link. This changed areas on the screen using Axure variables with OnClicks. It was very clear to the business that we could include a bit of flow, keep the dashboard, and switch users at any time on any page. The business loved it.

Then, it was time to do the comps and many extra meetings had to be called. There wasn't a physical screen named with the company convention that they could tie directly to a comp and without this, a matrix had to be created so comps weren't missed. It also caused extra meetings with the development team on why there were comps that didn't appear to match up to a named page in the wires.

In this case, the dynamics could have been less fancy and utilized name screens from the dashboard so the business still had a feel of changing roles on the screen, but would be actually moving to another page. I'd recommend saving the in-page dynamics to represent data returns, or success and error messages for form submission.

Not all team members are equally skilled with Axure. You may have some team members who are highly skilled and will set up all the masters initially, while other team members work with the business doing the initial storyboarding, architecture, and rough wires. How interactive the wires are will be determined by the team's skill levels. If there's only one person who knows how to set panel states on page load, you'll want to keep your interactions basic so everyone can work on them and the final product is consistent.

There is also risk if you have a contractor come through that sets up fancy interactions and isn't there when you're doing updates/new releases. I had the chance to work with a very skilled Axure user on one of my contracts, and though he was brought in for one specific project, he ended up assisting with some complex flows and concepts on several projects. After he was gone, and some of these projects went to other UX people, there were some major requirement changes in the next release. Things were missed because the new team members didn't know how to update the wireframes and interactions correctly.

If your team has several members with strong Axure skills, then you should be taking advantage of the features available by adding cases to show different states, and using custom widgets along with your masters.

Most UX practitioners are skilled in storyboarding and information architecture and any team member should be able to set up the sitemap correctly and generate a flow diagram within Axure. Axure makes these tasks easy to use in order to display different options to the business, grouping the versions in the sitemap and rendering a flow for the business to visualize what you're proposing. Simple storyboards can be used at this stage, like we used to do in Visio, with the storyboard kept as the first page of the final version and the generated sitemap as the second.

Several teams I've worked on have used password-secure AxShare outside the firewall, publishing space for their wireframes. AxShare allows each team to create their own unique URL and password—all administered from the same AxShare manage page.

Make sure before you demonstrate that only the pages that are a part of the discussion, or only the approved ones, are published, which means someone has to be responsible for making sure that only the agreed-upon pages are selected in the Pages tab of the Generate Prototype menu. Managing this tree correctly can become complex when multiple team members are working on the same file, but on different pages or versions.

Not all files created are for publishing, and yet making sure the ones that are to be published have been updated in this view correctly isn't as easy as it sounds. Someone always has this checked out. You can get around that locally, but when it's time to check in and publish, you need to check destination folders and make sure someone hasn't turned on anything you don't want published, or have checked annotations that were only meant to be published for the development team.

This is just another opportunity to process and make sure all the team members understand the publishing options and how they affect even team members who don't publish.

Starting a large website/web application project brings a lot of teams together, and each team has their own expectations on what deliverables they'll produce for what purpose. The teams that receive these deliverables have their own expectations on what they'll receive and how they'll use them. Often, there's a large chasm between these sets of expectations.

Axure has opened a lot of possibilities for higher-quality deliverables and has widened the gap between these expectations. Fortunately, expectations can be set early in the requirement process to help close the gap. The cover page discussed previously is part of setting expectations, and I have found it very helpful to read it out loud to the business before diving into the presentation.

Teams need to determine how they're using Axure. Sometimes a project can be jumped into before there's a team together other than business analysts. Whoever is doing these early stage flows and story boards in Axure needs to know before they start how deep the final deliverables are for the UX team.

What are the architecture or design goals? Are they using the interactions for activity analysis or just to portray to the business? Will the business want to see the comps themselves added into the wires, or are they separate deliverables? What is the expected complexity level? All these factors affect the Axure skills you need for the project. Do you need all requirements, wire/comp/content in a comprehensive specification? If so, you many need team members who really understand how to coax Axure to generate a usable requirements document.

Is this being built off an existing look and feel? Is this an enhancement to an existing product that another team initially worked on? Then, you'll want to see what already exists and leverage any masters or other widgets available, base your team choices on the type of interactions, and set up.

I've seen very good UX people with basic Axure skills end up on pages that utilize a lot of the features they have no idea how to use. If paired with an Axure guru, they'll supply extremely high-quality deliverables, whereas alone they'd fail, with business and development both unhappy.

The following section addresses the impact and importance of wireframe fidelity.

Adam C. Basey is currently an information architect at Orbitz Worldwide, one of the leading online travel agents with previous working experience at Accenture, User Centric, and Indiana University Alumni Association, all in IT- and HCI-related areas. He has a B.S. in Informatics and M.S. in Human-Computer Interaction/Design from the Indiana University School of Informatics and Computing. He has great passion for design and always looks for ways to make things simpler. He is an expert in having a bird's eye view of the problem and sets the vision clearly before stepping forward. Personal fitness is his hobby and passion and he is an ACE-certified trainer. In his free time, he passes out his bodybybasey.com business cards and flexes frequently. The cards usually end back on his desk. His LinkedIn profile is http://www.linkedin.com/in/adambasey.

Suresh Kandeeban is an information architect at Cognizant Interactive, User Experience division of Cognizant Technology Solutions, one of the top-tier services and consulting companies. He is an Axure enthusiast who actively looks for better ways to work with Axure and also loves to share his knowledge. He is an expert in using the Axure tool and has good knowledge (intermediate level) in using other popular prototyping tools, such as Balsamiq, Visio, and so on. He likes reading design books and those that are related to mobiles. Responsive design and SEO inspires him a lot. His personal website is www.sureshkandeeban.com and he can also be found on LinkedIn at http://www.linkedin.com/pub/suresh-kandeeban/72/a3b/973.

Melissa Sisco is currently the User Experience Lead at CA Technologies, a large independent software company. She has been working in the User Experience department for more than 16 years and is passionate about turning around failing product experiences into positive, simple, and intuitive designs. Previously, she worked at Orbitz where she helped the UX team make the transition from Visio to Axure for all their wireframing and prototyping needs. During her 12 plus years prior to Orbitz, Melissa was a member of the User Experience group at Accenture where she helped shape the design of several websites and products for a variety of Fortune 500 companies. Her LinkedIn profile can be found at http://www.linkedin.com/in/melissasisco/.

Vinoth Balu Gunasekaran is a Manager (Biz. Dev.) at Cognizant Interactive, User Experience division of Cognizant Technology Solutions, a global leader in business and information technology consulting. He started off his career in interaction design about 10 years ago, architecting user experience solutions for business applications, portals, and e-commerce sites across business domain, technology landscape, form factor, and geography. As part of a long-term consulting engagement, he has been jointly working with the in-house UX team of a leading US-based online travel agency where he helped the team make a business case, chart roadmap, and complete the transition to Axure, leaning down the wireframe specifications in the process. When not working on client projects, Vinoth is typically engaged in creating proof of concepts, conducting benchmarking studies, and crafting solution approaches for IT business proposals from Cognizant's global clientele.

Julie Harpring is a senior user experience architect for the travel website company, Orbitz Worldwide, where she recently created a custom Axure widget library for the UX team. Since she entered the field of interaction design in 2005, Julie has created mobile, tablet, and desktop experiences for organizations such as Orbitz, eBookers, HotelClub, CVS Caremark, Motorola Solutions, the University of Missouri, and Goodyear. She holds a master's degree in Science in Human-Computer Interaction from Indiana University, a bachelor's degree in Journalism, and a bachelor's degree in the field of Arts in English from the University of Missouri. Julie loves tapping into her journalistic sleuthing skills to gain user insights that lead to exciting new concepts. Her LinkedIn profile can be found at www.linkedin.com/in/julieharpring/.

For years, Visio has been the documentation tool in our company for an extremely large document base/wireframes of our current set of platform pages. This is a comprehensive collection of all possible permutations, combinations, and conditions of every page that a customer can see on our e-commerce platform. We call these pages document masters.

A typical project process in the UX team of our company has been that every time someone works on a project, they create a copy of a document master page and update that page/module based on the project requirements. This copy of the document master for the project is referenced as a Project Document (PD). The PD is what gets presented to the business for review and further iterations before implementing. Once the project goes live, the PD will be merged back with the document master file so that the document master stays up to date. We call this merging. The following diagram will give you a brief idea of the merging process:

Image 62

Traditionally, this process as seen in the preceding diagram (Image 62) was done in Visio, which has served as a great wireframing and documentation tool, but was lacking in features as the UX industry evolved. At times, showing an interactive prototype/wireframe to stakeholders had a clear advantage in helping them understand the concept at hand. We needed a tool that allowed us to wireframe, annotate, capture functional specifications, as well as produce interactive prototypes for our PDs, and so we began to explore different tools outside of Visio to experiment with, during our PD phase.

Axure had become the go-to wireframing tool for our company for project work or PD but we still needed to justify recreating all of our Visio document masters in an Axure format. So, why Axure? From what we understood of the use of Axure during the PD phase, we felt, we could achieve the following for our document masters.

Following are the improvements Axure would have on our UX delivery process and how it maintains our current information architecture capabilities as well as enriches our interaction design capabilities:

After reviewing multiple wireframing/prototyping tools in an agile environment during the PD phase, the team focused on Axure and its suitability in managing not only our PDs but our masters as well.

We created a working group of five people that met once or twice weekly over a course of six months, and used the following set of activities to investigate Axure's capabilities as a possible document base to hold our masters and determine the implementation strategy.

One of the first things we did in the working group was to begin building a skeleton/framework in the format of an Axure Team Project using one of our more complex document masters. It was necessary to test all the content and methods we used in Visio within the Axure environment and determine new ways to work.

Essentially, we began to create a proof of concept (POC) that was eventually shared with management and the UX team for buy in. While building the POC, we were able to determine why Axure would be a better tool for us, as shown in the following table:

The following table represents the improvements Axure would have on our PDs and UX delivery process with one being easy and five difficult:

Separate sessions were held where we identified and called out every type of documentation method and artifact used in our Visio document masters. The purpose of this activity was to allow our quality engineers, user interface engineers, product specialists, and developers raise a voice into what the future of the document base would be. More importantly, it was an opportunity to remove artifacts that no longer needed to be documented in our document masters. Essentially, we carried out a process to lean-down documentation to eliminate old or unnecessary documentation artifacts.

The initiative to migrate the doc base from Visio to Axure started with an effort estimate. We considered two different approaches with the biggest assumption being "nothing will be dynamic" (as in, we will only move the masters over from Visio to Axure as static wireframes with no interactions) in the doc base document masters as follows:

To align with UX team's Vision for an efficient use of the doc base, we started with the rebuild approach to construct the entire doc base in Axure, though it took longer.

The following workflow table represents the collaborative working model of UXAs and UXDs at various stages of the design process/activities:

Workflow Details

The following sections will give you a detailed description of different stages in workflow.

Process A – Project Kick-off

This phase starts with getting all the changes from the shared directory so as to ensure we have the latest version of the document master to get started with the new project.

There have been conflicts in the past where two UXAs/UXDs work on the same page (for example, the search results page) later realizing/understanding the conflicts. Traditionally, Excel was used to resolve these conflicts; however, we identified a potential solution in Axure that we started using by annotating the site map under a user's name with intended page changes.

The following screenshot (Image 63) shows how Axure's annotation capability was used for a page tracker (content was scrubbed for confidentiality reasons):

Image 63

A quick check in/out mentioned in the workflow table is the step to inform users to annotate pages that are getting impacted, so everyone on the team has visibility of the document masters that are being used for PDs, along with some high-level details of document master changes.

Next, a UX team member exports the document masters that have been identified from the document base shared file .rppj to a .rp file. The objective is to retain only those pages that are necessary or relevant to their project. It's important that no actual changes to the document base are made until a merge takes place.

Any work created on a PD should not be represented in the document base until the project goes live. Because team members may be working on the document master at the same time for different projects in different PDs, we used Axure's annotation feature to create an integrated file tracker, which allows team members to chat with one another on potential feature team/project overlaps.

Process B – Project Updates

This is the phase where most design explorations occur. UXAs/UXDs will set the exported (.rp) file as a shared project file (.rpprj) among themselves to work on collaboratively, which is now their shared PD. Based on reviews and iterations, the designs will be updated / changed and the final version will be shared with the stakeholders as detailed in the Storing/Sharing Files section. To iterate, the deliverable will host both UXA/UXD artifacts in the same location without having to go to different targets, which is one of the main advantages of using a shared project delivery. Another main advantage is to ensure there is communication between the UXA and UXD so that the designs/wires presented are in sync.

Process C – Usability Testing

As mentioned, this phase doesn't apply to all projects. For those applicable, interactive wireframes are created using the linked comps approach or Axure's interactive capability.

Process D – Merging

This phase starts only when the project goes live. As the first step, a team member would get all the changes from the shared directory for the latest version of the document base. In our company, there is a traditional process of archiving the old version of the documents whenever you make updates and we leveraged the same approach while using Axure by exporting a version of the document base .rpprj to a .rp file. Axure's built-in shared version history didn't work out to our specific needs, since it handles each and every update as a version.

Once a team member has the latest version of the doc base, they export it as a .rp file and archive it. Then, they will check out those pages that they want to update with the new project-specific changes from their PD, which is in the .rpprj or .rp format. They can either copy and paste or choose to import with Axure's import feature from the PD.

Once a team member completes the merge, they will remove any annotations/notes, from the screen map we are leveraging as the file tracker, to indicate that they are done with the project. The document base is now updated from the PD, and the PD is also archived in the UX_Projects file location mentioned in the following section, in a directory labeled merged.

We created three file locations for people to manage their artifact throughout the design process; they are as follows:

Another activity was presenting and demonstrating findings to the management and the UX team. We had many iterations of our POC, internal process documentation, training material, and other artifacts mentioned in this case study. Our approach was very iterative and eventually we landed on a version of the document base in Axure that was acceptable to the team, and we were given approval to migrate from Visio to Axure.

The activities that were used to bring our team up to speed on the Axure document base and delivery process of PDs are as follows:

Our proof of concept finally worked well with all the investigations and explorations that we did. With multiple rounds of presentations and discussions, we got a buy-in from the management team to move on with the huge effort of document base migration from Vision to Axure.

We identified a resource by the name of Jessintha Jeyaraj who worked out of the southern part of India to help us in completing this migration. She did justice to this to a point where we can say, "The Axure doc base is up and running for use".