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.

What We Learn From Animators About Prototyping

In animation, much like in software, everything that we see on the screen needs to be artificially created. In other words, as opposed to live action film, where the camera captures massive amounts of extra detail because it is part of the physical world, animators must create the ground the characters are walking on, the sky, and everything in between.

The production process of animation can be excruciatingly slow even in modern, computer generated productions. 'Snow white', Disney's first full length feature film took 4 years to produce (1934-37) and ended up costing nearly S1.5 million, a significant sum for a feature film back in 1937. In fact, a list compiled by Forbs, of 25 most expensive films until 2006, adjusted for inflation, lists one full-animation film and many with heavy use of special effects which is a form of animation.

In a recent interview with Terry Gross, Pete Docter described the creative process of the animators team behind the Pixar movie 'UP' ($175M), a process that in many respects is very similar to the process established by animators in the early days of animation at the dawn of the 20th century.

For example, the team created a story reel which Docter, the movie's co-director, described as a "comic book version of the movie". The idea is to build the visual sequence of the movie using rough 'keyframes' - drawings that define the start and end points of a sequence. Team members record the dialogs and add these to the visual roll. In the case of 'Up' the team used immediately available resources such as Docter's daughter who's recording ended up in the released movie.

Animation, has always been slow and expensive to produce because it is labor and technology intensive. Thus the story reel provides the stakeholders and the production team with a good idea of the narrative flow from start to end - before production begins. Gaps and flows can be identified and the script, character models and animation properties can be modified accordingly.

One second of animation, at 24 frames per second takes 12 to 24 unique images. According to an article published in January 1938 in Popular Mechanics Monthly, over 1.5 million drawings were created for Snow White. Fast forward 70 years and production of computer generated animation is still as demanding, and prototyping before actual production is critical.

So in addition to the story reel animators also use a technique called pencil testing. The pencil test helps evaluate the animation quality within a scene. The animators shoot a scene using key frames and in-betweens (the sequence of drawings the connect 2 keyframes), review the result to identify flows in the animation - jerkiness, action that goes too fast or too slow, etc. - and make the necessary changes. Once pencil sketches were approved the production moved on to retrace in ink those rough pencil outlines, yielding high quality drawings, and these were in turn traced on clear acetate cels and painted. A long process indeed.
Another technique that was an absolute must in the day of hand made drawing animation, was 'flipping'. The animator, hunched over his animation table would quickly flip through a stack of drawings - sometimes as little s six or twelve, to get a sense of the flow within a sequence. This was very helpful during the process of creating the in-between drawings.

The similarity between animation prototyping techniques and user interface and user experience design are interesting:

1. The story reel is like a complete interactive prototype, the one that let's us step through tasks an interactions from login to logoff - check for overall consistency of interaction patterns and usability. Identify gaps in requirements and patterns. It is seeing the forest and also the trees and is important on a project level.
2. The pencil test is is like testing a single ui widget or screen - is it working according to business requirements? does it comply with our established interaction and visual design patterns? If not, iterate until approved. This is like seeing the tree but not the forest, and is useful on a work-stream level.
3. Flipping, the quick testing of interaction flow within a ui widget, for example, a dynamic panel in Axure. This is useful on a team member, UXA level.