Prototyping Essentials with Axure

By Ezra Schwartz , Elizabeth Srail
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Prototyping Fundamentals

About this book

Designing the user experience has never been more exciting, while prototyping it has never been more challenging. Whether you are an individual practitioner or a member of a UX team, a consultant, or an in-houseUX resource, this book will teach you how to plan, construct, and document top-quality, device/OS-agnostic artifacts and deliverables such as task and user flows, persona briefs, wireframes, prototypes, and specifi cations with Axure 7, the leading UX industry design tool.

Axure 7 is used worldwide by tens of thousands of UX professionals, business analysts, and product managers in global corporations, governments, large institutions, leading interactive agencies, and consultancies.

Prototyping Essentials with Axure Second Edition is a detailed, practical primer on Axure 7.0 and is a complete rewrite of the previous edition due to the numerous new features in Axure 7.0. Demand for skilled Axure professionals is high and familiarity with Axure is an expected prerequisite skill for UX designers worldwide.

Publication date:
May 2014


Chapter 1. Prototyping Fundamentals


"Come gather 'round people

Wherever you roam

And admit that the waters

Around you have grown

And accept it that soon

You'll be drenched to the bone

If your time to you

Is worth savin'

Then you better start swimmin'

Or you'll sink like a stone

For the times they are a-changin'."

 --Bob Dylan, from The Times They Are A-Changin'

The Times They Are A-Changin'

There is good news and not-so-good news to report on the state of things since the publication of Axure 6 Prototyping Essentials, Ezra Schwartz, Packt Publishing. The good news is that Axure now has over 80,000 licensed copies in 126 countries, and over 1 million .rp files have been uploaded to AxShare in 2013 alone (including new versions of the same file). The not-so-good news is that Responsive Web Design (RWD), a development approach hatched by programmers for programmers, has swiped the rug under the brief autonomy that User Experience (UX) designers had, over the creation of rich, interactive HTML prototypes, which tools such as Axure afforded without writing a single line of code. In RWD, developers solved a serious problem that they had to deal with: how to effectively and efficiently deal with multiple display sizes with a single code base. For designers, however, it became a struggle to construct and document the interactive prototype for variable screen sizes even in Axure. Increasingly, the task of building the prototypes appeared to be shifting back to the developers.

What happened? A profound change in human-computer interaction is sweeping the world, leaving in its wake injured giants of hardware and software, who less than a decade ago, roamed undisturbed in an ecosystem dominated by Intel- and MS Windows-driven desktops and laptops. The trigger was squeezed on June 9, 2007, with the introduction of the iPhone and again on April 10, 2010, with the introduction of the iPad. Since then, iOS and Android devices moved to account for the majority of devices sold worldwide.

That the world is rapidly turning mobile or that Intel and Microsoft lost their dominance so quickly, is part of the transformations we are experiencing. For UX, it is rather the emotional attachment that owners develop with their devices, which drives their popularity. The devices facilitate experiences and connections with both the real and virtual worlds through the mashing of personal and social, work and leisure, content discovery and consumption, and entertainment and learning.

For decades, user interfaces were assembled out of a small and finite collection of beloved widgets tied to a small and finite set of mouse and keyboard interactions. These user interfaces were composed of a small and finite set of window types. The majority of these interfaces were delivered to displays that increased incrementally in size and resolution over time. Yet, it turned out that it is not so simple to slap together a bunch of widgets on the screen.

But the complexity of designing a good user interface just a few years ago, pales in comparison to the present state of chaos; the number and flavor of user interface widgets keeps exploding, as new means of interactions are being invented via fingers, gestures, voice, eyes, and most recently, our brain.

Anywhere-Anytime used to be a favorite marketing catchphrase in the '90s, but globalization and technology turned it into an Anywhere-Anytime-Any OS-Any Device reality. Organizations are scrambling to adjust to this reality and for some, it's a survival effort.

Designing acceptable and good experiences kept eluding the majority of software of all types, regardless of the investment. After several decades of a slow and uphill battle for recognition, business and engineering stakeholders are ceding to the emerging UX profession. This is because good UX drives down the overall life cycle costs, increases market share, and earns the user's satisfaction and loyalty. Simply said, a bad user experience is bad for business.

However, guess who else is scrambling these days? We are! Just as UX has earned a prime-time spot at the software development life-cycle table—prototyping the experience for a device-agnostic world, has been snatched again by front-end developers, who invented a practical technique to deal with the challenge. They came up with a practical approach, while in UX circles, people were still debating the merits of Visio and paper static prototyping.

We have a great deal of respect for front-end developers who, in our opinion, are UX's best partners in evolving exceptional user experiences. Gary DuVall, lead presentation layer architect, talks about the challenges of keeping up with the constantly shifting technologies, and how front-end developers can greatly help UX when developers and designers tightly collaborate. As an example, he mentioned a project he worked on that experienced serious challenges with tables in a responsive design. The research and experimentation lead by the presentation-layer team has yielded a feasible approach that allowed the designers to use it to great success and solve the design problem.

At the time of writing this book, RWD is the most practical, technical method to deliver OS and device-agnostic experience to the Web. This explains its rapid propagation if you are a developer, but for UX, there is a sense that designers are back where they were a decade or so ago: front-end developers create prototypes and designers are further removed from being able to experiment first-hand with interactivity. The following diagram visualizes the two common models for UX prototyping:

Image 1

  • Option A: Complete dependency on front-end developers to express interactivity ideas and accept the risk of becoming marginalized. In this scenario (Image 1, A), UX creates static wireframes. The front-end developer turns them into HTML. The concern is not only around the waste of time and money this option can be, but also around issues that emerge in interpreting the dynamics of the interaction.

  • Option B: You can become a coder yourself. You can learn HTML, CSS, and JavaScript, as it seems that there are no good UX tools to deal with RWD or are there?

It is common to find ads that look for a UX designer who can: plan and conduct user research, conceive and lead the design, create wireframes, build production grade html-css-javascript prototypes, and write detailed documentation. In other words, a one-person team that can do the work of several professionals, each with a specific expertise, but get paid as an individual. This, in our opinion, reflects how deeply UX is still misunderstood.

We believe that the primary focus of UX designers must be set on conceiving, experimenting with, and communicating UX. A tight collaboration with developers and a solid understanding of the technologies that drive modern software development, including HTML and CSS, is a must. UX practitioners should not be treated as a "jack of all trades" because they then become expert in none. Instead, UX designers need specialized and powerful tools to design UX.


The Axure Option

We propose a third option in which UX designers do not need to cede control over rapid prototyping to front-end developers nor become coders. While the learning curve of Axure 7 is somewhat more demanding, one can easily imagine and materialize contemporary UX firsthand. In Axure 7, you can evolve from a concept, to high-level wireframes, and then a detailed design in a responsive manner. If you are a current user, there are some new capabilities that will require you to drop familiar construction methods such as how you use dynamic panels.

Yet, and here we are talking from our experience; you will quickly adopt the new capabilities because they are built into and extend the familiar framework. If you are coding, Axure is surprisingly robust in its support for JavaScript and CSS. If you don't care much about this fact, you can still create amazing responsive simulations without having to code them.


"We shape our tools, and thereafter our tools shape us."

 --Marshal McLuhan

Marshal McLuhan's insight is especially intriguing in the context of tools that help us conceptualize and express the user experience. Our motivation to write this book has been shaped by personal experience with Axure. Early on, we were struck by the freedom to design, test, iterate, and present fully clickable interactive, and now, responsive, HTML prototypes of the experience we design. This is accomplished without a front-end developer and yet, our energy is focused on the user and the best UX instead of being thinned by struggling to learn a programming or authoring language.

Both Elizabeth and I share an experience that many other Axure users had. Within a few hours of launching Axure for the first time, we were able to create an interactive prototype without coding. Since that day, we have rarely used Visio as a wireframing tool. We also realized that in addition to being able to create interactive prototypes, Axure can help us deal with a major chore—creating and updating the user interface's UI specifications document.

If you ever created a specifications document in a traditional way using Visio, Word, or InDesign and a screen capture utility, you would know the drill—a tedious, time-consuming, and expensive process that involves adding footnote tags to Visio wireframes, taking screenshots of these wireframes, saving them, importing them to the specifications document, and finally, writing the relevant annotations.

However, iterative design is at the heart of the UX process, meaning that updates are frequent and sometimes substantial. And so you have to retake screen captures, name and save the image files, import the updated version to the document, and update the annotations. Sometimes, changes to wireframes require a cascading change in the order of annotations, which involves more work and potential errors. The process needs to be repeated for each updated wireframe. Multiply the time it takes by the number of modified wireframes in your project, and the magnitude of the effort becomes clear and daunting—a real drain of time, money, and energy which is bad for everyone involved in the project.

Axure's integrated specifications offered an innovative approach that had the potential to greatly reduce the manual process through automation. Axure numbers the annotations on the wireframes, takes the screenshots, and organizes the entire content in a customizable layout. While configuring the UI specifications document takes some experimentation, the effort pales in comparison to the manual process. Moreover, once you are happy with the way the specifications generator works, you no longer need to deal with it.

Since its introduction in Version 4.X, Axure's support for teams has evolved as an important enhancement that helped cement its adaptation among UX professionals. Any sizable project requires multiple UX resources, and collaboration is a critical prerequisite, which Axure addressed with its Shared (now known as Team) Projects feature.

Elizabeth and I share another experience with many users. As we started using Axure, we occasionally stumbled on technical issues or had questions we could not figure out. The company's responses were and continue to be prompt and detailed. Files sent for checkup are reviewed, the issues are explained, and bug fixes are promptly posted. This commitment and dedication to customer support has been, and continues to be, the reason for the loyalty Axure users have for the company.

Axure users also benefit from an incredibly helpful community of fellow users worldwide on Axure's discussion forum (refer to Typically, you can get a helpful response to your query within hours, and people are generous with sharing their expertise. Over time, as users gain some expertise with the tool, many enjoy being able to help others in the forum. Overall support is very important when a tool becomes critical in our work, because it has a direct impact on our livelihood. Support becomes a lifeline in times of crisis and the knowledge of that such a level of support exists plays a major role in wining user-based loyalty and tolerance.

Axure's value proposition continues to be strong and compelling, and its success in convincing clients and team members to approve or adopt it goes back to times when Axure was far less known among UX practitioners. This UX-centric integrated environment for wireframing, prototyping, UI specifications, and collaboration also carries a price tag. It is a small fraction of the cost and implementation complexities of enterprise tools.

A few years ago, some clients raised a concern about the ability to find UX resources who knew how to use Axure and some UX designers raised a concern about switching from tools they were very familiar with to a new tool. Despite the fact that these two concerns can potentially feed each other in a damaging loop, which makes it difficult to affect change, Axure has captured a dominant position in the UX industry despite numerous competitors.

External pressures also drive a change in attitudes and acceptance of the new competitor. Indeed, the growth of Axure's popularity among UX designers paralleled two important trends: the solidification of UX as an integrated part of the overall development process and technological advances that afforded the creation of rich user experiences. As more companies recognized the business value of modern user experience, budgets opened up and with them, the demand for UX professionals increased.

With this increase in demand came the pressures to deliver on time and budget, both often aggressive to absurdity. At a certain point, overly ambitious schedules create serious friction with the core principles of user-centered design, an inherently time-consuming methodology, which calls for contextual research, iterative design, and user validation. Many in the UX community realized that besides helping to produce world-class deliverables on a tight schedule, Axure is also helping UX stay profitable. This is because we can deliver a lot more value to our clients in less time, with less resources, and less sweat.

Profit is always important because at the end of the day, design agencies and independent consultants need to turn a profit in order to stay viable. In-house UX departments also need to increase productivity and reduce costs to help their company's bottom line. It is impossible to stay viable for long if you have to double and triple your workload just to keep up with the pressure of constant updates to a prototype and UI specifications. Axure helps maintain profitability because it is relatively easy to master and it affords substantial efficiencies through a clever use of customizable patterns, templates, and automation.

In conclusion, and reflecting back on McLuhan's observation mentioned earlier, Axure is a tool that has been shaped by UX designers over the course of over a decade. At the time of writing this edition of the book, it is widely used, with tens of thousands of licensed copies running worldwide on Mac and Windows, probably making Axure the de facto UX design tool in our industry.

In this chapter, we will introduce you to a simple planning and logistics methodology that will make your life easier while working on projects. We will cover the following topics:

  • The A Weighted Risk Checklist for UX Projects section covers a diverse set of variables over which you have little control at the start of a project, will help you develop a predictive estimate of possible challenges and suggests actions you can take to turn lemons into lemonade

  • The Axure Construction Strategy Checklist section helps define your approach to the construction of the Axure project file well before you even fire up the software

  • To remind you that UX projects are a collaborative effort, the stakeholders' expectations list will help orient your position related to business, project management and engineering stakeholders, as well as other design and user experience practitioners


UX Prototyping by UX Designers

Our friend and a UX pro, Rich Macefield, told us about his amazing trip to Egypt, where, instead of joining the crowds at the Great Pyramids of Giza, he visited the site of smaller pyramids constructed around the 27th century BC. These pyramids are considered the prototypes of the famous structures. Back in the 15th century, Leon Battista Alberti described an event that took place in the first century BC. In his classic text, On the Art of Building in Ten Books, Alberti mentions that Julius Caesar "completely demolished a house on his estate in Nemi, because it did not totally meet with his approval." and continues to recommend "…the time-honored custom, practiced by the best builders, of preparing not only drawings and sketches, but also models of wood or any other material…".

One might think that, given his authority as the ruler of the Roman Empire, Julius Caesar was perhaps abusing his powers by acting in a capricious, short-tempered manner. We can also think about Caesar as a typical client, reacting somewhat badly to a design that did not meet his requirements and specifications.

Two millennia later, this is another way to think about the event that has an immediate relevance to us. The core of the problem is how to figure out what the client wants, and deliver a product that meets those expectations. This is a problem of communication, and UX designers face the challenge of resolving it satisfactorily on each project they work on. Often, the client might have a clear idea in their head of the exact way, the software should look and function. Sometimes the client has no idea of how the structure should look or function, but has a need to have it in place in order to fulfill a business requirement or some other pressing need.

From the early days of computer science, people found obvious parallels to physical architecture and borrowed from it liberally—terms and titles such as architect, build, configuration, and so on. Similarly, to architects and builders of physical structures, we need to create a functional product, and face the challenges of tracking tight budgets, adhering to schedules, and making our clients happy.

However, beyond borrowing terminology from architecture, aspects that relate to engineering and process rigor take much longer to implement. For example, the use of modeling for user interface and user experience design as we think about it today, came quite late to the development life cycle. This perhaps explains why a very high number of software or Web projects fare badly, but our cities are not littered by the ruins of collapsed buildings. Compare a large architecture project set to build a 100-storey skyscraper with a large enterprise software project. What are the odds that both will be fully up and running within a couple of years? The odds are very high for the skyscraper and far less for the software.

In other words, if we compare the rigor, efficiencies, and processes that translate a cardboard model and blueprints into a skyscraper with the typical chaos of software projects (perhaps with the exception of software for airplanes and such no-failure uses), we probably have some ways to go; it is an evolutionary process.

The truth is that of the billions of private residences, public buildings, and industrial structures that humans constructed on earth since moving out of caves, relatively few ever benefited from the design of an architect. Not that these are necessarily bad; in fact, many of the structures we see today evolved successfully over millennia. People build their own homes—individually or as a communal effort. Read Donald Harington's The Architecture of the Arkansas Ozarks for a wonderful account of such an evolutionary process.

Alberti further writes: "Having constructed those models, it will be possible to examine clearly and consider thoroughly relationship between the site and the surrounding district, the shape of the area, the number and order of parts of a building...It will also allow one to increase or decrease the size of those elements freely, to exchange them, and make new proposals and alterations until everything fits together well and meets with approval. Furthermore, it will provide a surer indication of the likely costs—which is not unimportant—by allowing one to calculate costs".

It is fascinating to translate Alberti's writings about modeling for buildings to UX prototyping for software. He is talking about the ability to articulate the layout, hierarchy, organization, and order of entities. He further talks about the ability to use the prototype for cost and effort estimation.

Another example of providing a client with wireframes and ensure its alignment with the client's needs is mentioned in the book, Painting and Experience in 15th century Italy, Michael Baxandall, Oxford University Press. Baxandall writes about the 15th century painter, Filippo Lippi. Back in 1457, Lippi was commissioned to paint a triptych for Giovanni di Cosimo de' Medici, the Italian banker and patron of the arts. In a letter to Giovanni, Filippo writes "...And to keep you informed, I send a drawing of how the triptych is made of wood, and with its height and breadth".

Prototyping Interaction

So it turns out that we did not quite invent the prototyping wheel after all. The value propositions, ROI calculations, and fancy technical terminology of prototyping have been around for a couple of millennia, if not more. There are however, several important differences that make prototyping rich user experience particularly challenging for UX practitioners.

In the past, structures did not involve dynamic interaction with the occupant nor did they need to shrink or expand at a whim. Buildings stood there, whether there was an occupant or not. However, we are entering an age when, as you enter a building, rooms could contextualize themselves instantly to reflect your preferences and perhaps even adjust physically to reconfigure the space to your specific needs.

When it comes to prototyping a rich user experience, the complications come from the need to demonstrate the following norms, among other things:

  • Scenarios: The prototype needs to simulate the possible paths a user would have on any given screen and the system's appropriate responses of the actions that the user is taking. Often, the path could be conditional and take several steps to complete in a coherent and satisfactory way. The arsenal of interaction patterns that is available to UX designers today is significantly richer than what was available a decade ago.

  • Multiple screen sizes: We must consider screen sizes, for example, small for smartphones, medium for tablets, large for desktops, and extra large for those large, high-definition screens. The user experience is influenced by the size of the screen, although the user might expect the same content and functionality regardless of the device in order to accomplish a task.

  • Prototyping in-page data refresh: Back in the eighties, a prevalent workflow for a given task in client-server software involved hopping from one window to another. In the nineties, the common web navigation was hyperlinking from one page to another, facilitating a similar goal. These days, the need to negotiate multiple windows has been greatly diminished with asynchronous in-page data updates, but the complexities of prototyping in-page data refresh have increased.

  • Personalized experience based on login: The prototype needs to simulate how the system will render for different users based on the entitlements. In the case of non-registered users, the site might display special offers to entice the user to register. A registered user may get information based on the preferences they have set in an earlier session and a paying user needs access to additional content based on their past activity on the site. Increasingly, we are asked to model all of these permutations.

  • Scalability and future scope: Many applications are deployed in phases, making it possible for the business to prioritize its investment in the project based on strategic goals and practical, budgetary, and technical constraints. The prototype, which often begins as a full-fledged visionary concept, needs to be able to support graceful degradation or fall back on less-ambitious capabilities of the present and scale in the future.

  • Adaptability to localization: In a global economy, a common requirement is to develop an application that can be easily localized to reflect the language and cultural preferences of the local demographics of its users. The prototype needs to demonstrate the ability to render in multiple languages.

  • Exception handling: Following business rules helps dictate the logic that drives user-system interaction. One of the toughest requirements to prototype is how the application will respond when the rules for moving through an interaction path are subject to exceptions. For example, sales representatives want to increase the allowed discount on a product. Often, the demand for overrides surfaces late in the design process as a result of a push back from stakeholders who demand such capabilities.

Similar to architecture and construction, software is an evolving art and science. However, unlike construction, many of the tools and methodologies are evolving at such a rapid pace that it is very difficult to establish solid patterns of development. While physical architecture and construction evolved over centuries and stayed relevant for a long time, in technology, work created ten years ago is practically ancient and moot today.


Project-level Forecasting


"It is possible to fail in many ways... while to succeed is possible only in one way."

 --Aristotle from the Nicomachean Ethics

Aristotle's observation predated by in some twenty-three hundred years Tolstoy's famous maxim that states:

"Happy families are all alike; every unhappy family is unhappy in its own way."

The idea is now encapsulated by the Anna Karenina principle, which, loosely speaking, describes an undertaking (say, UX project) in which an issue in any one of a number of factors dooms it to failure. Consequently, a successful undertaking (the same UX project) is the one where every major problem has been projected and avoided; this is our goal.

A Weighted Risk Checklist for UX Projects

Before you embark on a UX project, you should carefully consider several heuristics which will help you predict what lies ahead, how to take appropriate steps to take advantage of the potential opportunities, and how to avoid potential pitfalls. These heuristics share an important attribute—you have little or no control over them at the start of the project, but you may be able to affect change as things move along.

The checklist we propose has the following benefits:

  • The factors in this checklist are generic and relevant to any UX project.

  • The value of each factor can only be one of two possible options.

  • Each option is weighted.

  • In each option pair, the Base option's weight equals 1.

  • The risks are not bad or good; it is just that, a risk of the project that will run over time and over budget because of complexities, churn, miscommunication, and other factors that are relevant to the risk.

  • Before you engage in the project and start it, you should know the value for each factor.

  • When you add up the numbers, the total score is a measure of your forecasted risk. The higher the number, the higher the risk.

The idea is not to prevent you from moving forward with the work. There are additional factors to consider when it comes to that. There is a risk in anything we do in life.

The Heuristics

The purpose of the following list is to get you ready and when possible, prepare. Feel free to modify—add or remove—items as you see fit to your personal circumstance. The key takeaway here is that you should have a list. It is a repeatable measure and tool that helps you identify patterns so that you can develop the best practices from one project to the next.

Image 2





Higher Risk



Your Employment






The Client






UX Reporting to...






Enterprise Grade...






New Product or a Redesign



New product





















Business Requirements Exist






UX Resources



UX team



Communication & Collaboration Tools

G Docs and similar.


MS based



UX Documentation & Traceability






Min Possible



Max Possible


The Score

When you sum up the items in the preceding table, you will end up with a score that is a predictor of what your scope will be. When you roll off the project, go over this list again and compare the prediction to the reality that you experienced. It is a good debriefing technique. The following table proposes a way to interpret the score:


Prediction about your experience with the project


Green (lowest risk)






Red (highest risk)

If you have some experience with previous projects, think about them, score them, and see to what degree the result fits your personal experience. We have tested this, and it seems to work quite well.

Note that a stormy prediction can also be a very rewarding professional and personal experience. Over the years, both Elizabeth and I had the opportunity to work on projects that were challenging and yet the reward of colleagues and friendships, the creativity, and satisfactions minimize the difficulties.

The following is an expanded review of the heuristics. Feel free to send us a note and share your personal insights.

Your Employment Type

The form of your engagement is at the core of your starting position in the project. While there are infinite variations given one's seniority and role, the two most common types of employment that frame your relationships with stakeholders can be your ability to influence things and the well-being of your emotional investment. The weighting of employment types is:

  • You are a consultant of the company (Risk Weight = 2)

  • You are an employee of the company (Risk Weight = 1)

Risk Factors for UX Consultants

The following are the risk factors for UX consultants:

  • You probably don't really know anyone—who are real influencers and who are puffed pretenders—friends or foes of or office politics? How strong is your sponsor and how dependent are they on your success?

  • You are an outsider and are being constantly evaluated at the start of the project. Trivial misunderstandings may get blown out of proportion. Some are hoping to see you make mistakes.

  • You are not familiar with the culture and attitudes and need to be aware of the possible gaps in the expectations of how things get done.

Of course, being an employee does not shield you from significant challenges. If you are an employee, the preceding items may be relevant. However, for the purposes of this evaluation, we assume that employees are insiders and are better-positioned than consultants.


The following are some tips to find opportunities:

  • Ask for an organization chart and explore the organization's intranet if it is accessible to you. Study it. Review the CC fields in your e-mail and match the names to the organization chart.

  • Move as fast as possible to expand the circle of stakeholders who are aware of your existence by arranging short discovery meetings. Ask about their expectations and concerns and if relevant, continue to seek their input as the project moves along.

The Client

UX projects in large and small organizations are often challenging from a UX perspective due to the dynamics of influence and the need to handle stakeholders' power plays that may hijack important aspects of the design. The savvy to successfully oppose a dominant and powerful stakeholder comes naturally to few of us, but typically, it takes experience and courage. The sheer size of enterprise projects diminishes the influence of a single stakeholder over all. In a small company, any person on the project carries a significant influence just because there are far fewer competing voices. In both cases, we propose you read about group behavior in the context of social psychology to understand group think and other situations. Remember that in the end, you win some and you lose some. Weighting the options as follows:

  • The customer is a large enterprise, a small company, or a startup (Risk Weight = 2)

  • The customer is a mid-size company or organization (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • The larger the organization, the higher the probability that one hand does not know or care about what the other hand is doing, thus leading to fragmentation and political power play

  • The larger the organization, the slower things move due to added layers of hierarchy

  • Busy decision makers may be too far removed from the project's nuts and bolts, making review meetings with them susceptible to major setbacks and blowouts due to miscommunication and misunderstandings

  • Vertical silos are common in large organizations leading to misalignment and miscommunication around various aspects of the project's priorities, goals, and approach

  • Small companies and startups can be chaotic and dominated by overloaded stakeholders with strong personalities


The following are some tips to find opportunities:

  • In a large corporation/organization, you should master the operational mechanics, such as the phone system, reserving conference rooms, and online sessions, as fast as possible. You want to avoid a potential derailment of important meetings just because you could not figure out how to dial-in, reserve a room in advance, and so on. While this is an attitude you want to adopt in any setting, smaller organizations tend to be less formal and bound by procedure.

  • Understand the organization, flow of work and responsibilities between departments, as well as governance structures that have impact on UX. Also make sure to understand processes such as change management and change control.

UX Reporting To...

It is rare that UX has complete organizational autonomy and influence, a situation that would be ideal. However, for most projects, UX is either sponsored by marketing, sales or other business functions or by the engineering department. Typically, UX projects are initiated by the business as part of a larger strategic goal. The closer the relationship with the business, the easier it is to affect alignment of the experience with these goals. The weighting for this category is:

  • UX is reporting to Engineering (Risk Weight = 2)

  • UX is reporting to Business (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • Engineering sometimes lacks a complete or accurate insight into the entire set of strategic and tactical business objectives that drive the project.

  • In many organizations, Engineering is focused on the maintenance and upkeep of software, which is an operational model that is radically different from the software development mode. As a result, you might find yourself trapped in what appears to be an unnecessarily slow and bureaucratic environment that is not optimal for rapid, iterative development.

  • It seems that there is an infinite number of development methodologies and it is possible that unless you are with the same organization, you will have to adapt the UX process to whichever methodology is used in the project.

  • Projects often start with an enthusiastic embrace of some methodology, such as a flavor of Agile, and degrade over time to a state of loose chaos.


The following are some tips to find opportunities:

  • Since you typically have little control over whom you will report to at a given project, it is important to stay apolitical and avoid falling into the camp trap of assigning blame to one party or another. We are uniquely positioned to bridge differences of opinion as long as we communicate clearly and to the point.

  • If you feel that the methodology enforced by engineering is compromising UX, make sure to understand the constraints that are at the root of the matter.

  • It is possible to come up with recommendations and workarounds that while still a compromise, ends up working better overall.

Enterprise Grade

There are various definitions on the Web for the meaning of enterprise grade, and some include buzzwords such as "mission critical" and so on. Size matters! The larger the project, the higher the risks involved in a successful experience project. Enterprise-grade projects are notoriously challenging due to the need to deal with multiple tentacles of a complex organizational hierarchy. This hierarchy is often spread across coasts and continents, its culture, silos of power, and legacy constraints. The weighting of this category is:

  • Enterprise-grade project (Risk Weight = 2)

  • Non-Enterprise grade project (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • An enterprise project means that UX is impacted in multiple dimensions such as scope and phasing, complexity, number of stakeholders involved, and resources.

  • UX-specific dependencies are often not accounted for when the project road map and project plans are created. Omissions include no or insufficient time for adequate iterative review and revision cycles, prototype refactoring, digestion of usability testing results, and so on.


The following are some tips to find opportunities:

  • It is sometimes difficult to remember, but every one wants to be part of a success. Recognize the forces of groups and social psychology that are in play and be a positive force in meetings. Be flexible when accepting critiques, yet firm in defense of the user experience.

  • People are hesitant to voice their opinions even if they object to something. However, they need to hear alternatives. Try to be prepared with design options.

  • As little as two voices, yours and another stakeholder's, in support of your idea can help you convince a larger group of your design direction despite stronger opposition. Always support your design with relevant arguments that stem from research, experience, public examples, and so on.

New Product or a Redesign

UX work typically involves a revamping of an existing product or the invention of a new one from scratch. It is the latter that is more problematic because only high-level concepts have been explored but not in great detail. Unfortunately, the devil, as the beaten phrase goes, is in those details. The weighting for this category is:

  • The project is for a new product (Risk Weight = 2)

  • This is a redesign project (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • There is a lot that is unknown and will be in flux throughout the duration of a new product. Major changes might and will happen at unexpected times.

  • Initial assumptions are likely to be blown away as the project evolves. Scope creep is endemic.

  • Stakeholders who don't have a clear vision or true understanding of the work will introduce doubt, hesitance, and tangential alternatives that may derail aspects of the design and sometimes, the entire project.

  • Redesigns too have their potential risks, especially when the there are high expectations for a contemporary, engaging user experience, which is greatly limited by the constraints of backend legacy technologies.


The following are some tips to find opportunities:

  • It is rare to be involved in the creation of a brand new product. Take time to do the research and develop design principles and framework concepts that best fit the experience for your new product. The more solid and well-supported your approach is early on, the better your chance to place UX as a key player in the project.

  • Design is critical when shaping the requirements, but it is hard to design with requirements that are being shaped and thus, often change. This is a typical conundrum. So, while it is extremely challenging to work in an environment that sometimes may feel like quicksand, remember that it is difficult for everyone on the project. UX can help by proposing rapid iteration on evolving concepts that help stakeholders arrive at the requirements.

  • Despite the fast action, always present your work in an organized and prioritized way. Always tie your work products to your understanding of the importance and priority or requirements.


Transactions mean that something is moving from a source (sender) to a target (receiver). The volume of transactions is a function of the number of sources and targets and the frequency of transmission. In addition to front-end experiences, a robust administrative interface must be provided as well, to facilitate the ability to deal with settings, business rules, and exceptions. Often, the administrator interface gets short changed at the start of the project because it is not customer facing, only to emerge as a massive, complex undertaking, once the work on the customer frontend winds down. The weighting for this category is:

  • The project includes aspects of transaction management (Risk Weight = 3)

  • No transactions are involved (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • Transactional systems involve exception handling, which may complicate UX. Often, the business requirements have gaps in these areas.

  • Prototyping transactional systems that needs to afford work with a lot of data is more time consuming; not only is it important to simulate screens that show many transactions—accuracy of simulated data is important. This means that we have to pay close attention to the flows and data transformations from one screen to another.


The following are some tips to find opportunities:

  • Axure's new repeater has great potential in helping simulate transactional data

  • Transactional application can provide you with opportunities to design very compelling work


The term, "Mobile First", became popular in 2013 and is a strategic declaration that organizations make. In these declarations, they express their commitment to reaching their audience on tablets and smartphones, ahead of desktops. This can be accomplished in several ways, including OS native apps. However, the proliferation of operating systems and devices turns native apps into a very expensive proposition. Responsive Web Design levels the playing field by eliminating the cost associated with native apps. However, for UX, the risks and challenges are still significant, as the experience needs to be optimized to the display size. The weighting for this category is:

  • Yes (higher risk, Weight = 5)

  • No (typical risk, Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • With RWD, you must have the design for all sizes ready at the same time. In other words, you cannot release a website that is only optimized for a smartphone and wait for the desktop view.

  • Each breakpoint size requires an optimization such that the user gets the appropriate experience. Even when you are very efficient, it takes extra time to consider the various layouts across all sizes.

  • Stakeholder meetings, user validation, usability testing, and of course, construction take more time because you need to go over multiple layouts.


The following are some tips to find opportunities:

  • If you are new to RWD, this is the chance to learn!

  • It is easier to affect change and help stakeholders empathize with users by reminding everyone to look at their phones. Because desktop and mobile experiences are so different, stakeholders, who may initially be oblivious to the quality of the user experience on a desktop, get your point immediately when smartphones and tablets are discussed.


When software needs to be translated to one or more languages, several layers of complexity are added to the project, both on the design and the implementation side. The weighting for this category is:

  • Localization needed (Risk Weight = 1)

  • No localization needed (Risk Weight = 0)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • The design must support text directionality (left-right, right-left).

  • The design must be flexible to support elegantly wider scripts, such as French and German.

  • While the first two should be evident and simple for any professional UX designer, it is important to know about the customization and presentation of content as soon as possible due to cultural or business needs in a particular local, which may render key templates unusable and require extra work.

  • There may be a need to factor in time for usability studies with users overseas. Time zones, holidays, and other issues may introduce unexpected delays in the execution of the testing program unless taken into consideration early on in the planning phase.

Business Requirements Exist

Unless you are totally new to UX and are facing your first project, some flavor of this heuristic is familiar. UX is supposed to follow business requirements. Without these requirements, the work is unfocused, with a high probability of going nowhere. The weighting for this category is:

  • Requirements don't exist, are skeletal, and/or too general, or they are being developed (Risk Weight = 5)

  • Well-developed requirements exist, and they are well written (Risk Weight = 2)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • Writing good business requirements is a skill and also an effort that requires time. It is more common to find requirements that are vague, a compound of several requirements where some don't even fit together, and so on. UX often needs to drive the process of clarifying unclear or ambiguous requirements but the process can be slow and lengthy.

  • It is common to get business requirements that try to dictate the user experience. You will have to educate and advocate for abstraction of the requirements from the specifics of UX. Your job will be to demonstrate how the requirements are fulfilled in detailed design.

  • Another risk factor can be insufficient time in the project plan for creating the requirements, digesting them, and iterating their implementation in UX. The design is essentially due before or when the requirements are delivered.


The following are some tips to find opportunities:

  • This is a tough spot to be in and we have been there numerous times. Therefore, if you don't understand the requirement, ask for a detailed explanation.

  • Be organized. If requirements are not numbered, number them. If a bunch of requirements are lumped together in a single blob, break it apart. Everyone prefers order and organization over ambiguity and sloppiness. Make sure that you approach this in a diplomatic manner as part of the UX process and not as a critique of the person or group that created the requirements.

UX Resources

There is a famous saying that, "One woman can deliver a baby in nine months, but nine women can not deliver a baby in one month". For some, working alone is compelling for a variety of reasons. However, there is only so much we can do single handedly and the larger the project, the larger the UX team. While your role in the team depends on your experience, seniority, and several other factors, teamwork is not trivial. The weighting for this category is:

  • You are part of a larger UX team on the project (Risk Weight = 2)

  • You are the only dedicated UX resource on the project (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • You don't know anyone on the team, and for some, adjusting to team work is difficult

  • Skillsets, experience, and savvy can vary greatly

  • The fact that not everyone on the team carries their weight, is not immediately apparent, and can explode just when the team is overflowed with stress and work

  • It will require additional time and effort to align the work each team member contributes, and often, time and energy are very scarce


The following are some tips to find opportunities:

  • Having a team has its own benefits. You get to learn, mentor, or be a peer of a colleague.

  • There is a lot to learn from experiencing distributed work on multiple work streams and dealing with the complexity of managing and orchestrating timelines and efforts; they all merge at certain milestones.

  • Extend your expertise in designing and applying global design patterns that will serve the entire team.

Communication and Collaboration Tools

This heuristic deals with the seemingly mundane software that is used to support the teams working on the project. In large budget projects, you will commonly find that critically important and highly collaborative documents, such as business requirements, are created in MS Word or Excel and distributed through a SharePoint repository. Wikis are also popular despite their being hideously convoluted and difficult to use. Similarly, UX work is expected to be created in a static wireframing tool such as Visio as opposed to Axure. The weighting for this category is:

  • Excel, Word, Visio, SharePoint, and Wikis are the primary methods of documentation and content/project management (Risk Weight = 1-3)

  • Collaborative software (not Wikis) is used (Risk Weight = 1)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • Inefficient communication leads to miscommunication, mistakes, misunderstandings, and more serious problems.

  • It is difficult to work collaboratively with multiple versions of documents floating around in e-mails. Referential integrity becomes a risk when work and review are done on the wrong/outdated copy of a document.

  • Having to wait for another person or multiple people to finish work on a document is frustrating and time consuming.


The following are some tips to find opportunities:

  • It can be very difficult to get the organization to adopt new tools such as Google Docs and similar ones, for a variety of reasons including concerns about security and confidentiality. Make sure that you follow the internal procedures and protocols.

  • It may be possible to get the organization to let you use Google Docs or some other collaborative tool just for UX. This will be a good opportunity to facilitate reviews, both in person or remote.

UX Documentation and Traceability

In some circumstances, detailed specifications are acutely needed, when the coding is done overseas and the organization is contractually committed to providing as detailed instructions as possible to the developers who have only the documentation to support their work. However, even in this case and in most others, the general sentiment is that creating such detailed specifications is a massive and ineffective waste of time.

The demand for traceability is less common, so if you are expected to show specifically where each business requirement is fulfilled in UX, be aware that this can be a massive, complex undertaking.

The combination of having to provide both detailed specifications as well as traceability audits is severe in terms of time and resources and typically, not well accounted for. The weighting for this category is:

  • Detailed specs and UX traceability are required (Risk Weight = 3-8)

  • Light annotation and no traceability (Risk Weight = 0)

Risk Factors

The following are a few risk factors that should be taken into consideration:

  • Writing specs takes a lot of time. If this time is not accounted for, you have a real problem.

  • There is an expectation that the specifications will be delivered with the requirements. This is a sad but common paradox in which, although UX is being updated up to the last minute to accommodate new or changing requirements, the writing of the specification is supposed to happen automatically.

  • Resist managing requirements in Axure at all costs (see the following Opportunities section for an exception).

  • Although Traceability may look like a chore, it is in your best interest to have an efficient strategy to map each requirement to where it has been implemented in the design. Some clients may require such inventory as a condition for payment. However, even if they don't, it helps avoid complications due to the requirements that were forgotten during the design process and their unexpected reappearance breaks the design and requires change.


The following are some tips to find opportunities:

  • Well in advance and as early as possible, engage all relevant stakeholders in an effort to develop the required annotation fields.

  • Make sure that the metadata requirements are the minimum possible, because each added field will mean input in multiple places and have a compound impact on the time needed for writing the documentation.

  • Also, collaborate on the format and organization of the specifications document so that you minimize the tweaking of the Word output after it has been generated.

  • It may be possible to format an Excel spreadsheet in such a way that it could be used in a repeater, thus affording a close tie between requirements, diagrams, wireframes, and prototype. Handle these requirements with care because they constantly change, and you don't want to lose time constantly updating the Axure file.


Axure Construction Strategy Checklist

There is no need to reinvent the wheel on each and every UX project, but we keep doing this despite the fact that in principle, all projects share more things in common than are unique to them. Before you embark on a UX project involving Axure (or any prototyping tool, for that matter), you should carefully consider several factors that will help you predict what lies ahead, how to take an appropriate approach to take advantage of Axure's features, and how to avoid potential pitfalls downstream.

These considerations share an important attribute—you have quite a bit of control over them at the start of the project. The checklist is driven by the deliverables you are contracted for and are expected to deliver. Another benefit of this method is cumulative; as you complete the project, make sure that you review your original assumptions and decisions so that you can apply your learning in the next project.

The following table lists many of the important deliverables or work products for which Axure can be used. The items on the list are classified as opportunities and potential risks to be aware of. This is by no means an exhaustive list, and yet, we feel that you could plug in any items that are relevant to you.



Deliverable/Work product




Discovery report




Personas/user types and tasks




Concept models




Use Case library




Task Flow library








A heuristic review of the current site







Wireframes /prototype

Pattern library



Wireframes /prototype

Vision prototype



Wireframes /prototype

Low fidelity prototype



Wireframes /prototype

High fidelity prototype



Wireframes /prototype

Usability testing prototype




Light annotations (HTML)




Detailed specifications (Word)


Showcasing Opportunities

The following is a list of ideas for adding even more value to your work:

  • Flows and diagrams: Create and aggregate all your abstractions in Axure as opposed to creating them as discrete PDF documents in Visio or OmniGraffle. While Axure's diagramming capabilities are not very robust, what you lose in fine detailing of an individual diagram is gained by the mere fact that they are always available during design and stakeholders' meetings. We often find that while a significant amount of thought and effort is invested early on in understanding and documenting flows, they end up being buried somewhere on the network, quickly forgotten and never used. As part of the Axure file, these diagramming can stay in sync with the work as initial assumptions evolve.

  • A heuristic review of the current site: One of the first steps before moving to design the new site is a detailed analysis of the existing software. Using Axure to reproduce highlights, insights, and reports of the current state is fast and easy. The benefits are substantial. You can dissect and analyze any aspect of the design in a structured way with the aid of custom annotation fields.

  • Pattern library: Axure's support for the creation and management of widget libraries is ideal to help control the consistency of the interface and interaction across the application. Additionally, the construction of wireframes gets a significant productivity boost from reuse of these widgets and masters.

  • Interactive prototype: The most effective tool that UX designers have in their arsenal is a simulation of the experience. Time and again, we have witnessed the impact of walking stakeholders and users through a clickable prototype. The speed with which such simulation can be placed in front of stakeholders and users for validation of initial concepts provides you with many opportunities to establish yourself. There is no need to have something flashy or complete as long as the presentation is not sloppy.

  • Documentation—light annotations: Perhaps, it is the propagation of agile methodologies and a growing frustration with the expense and ineffectiveness of detailed documentation that is never accurate and nobody reads carefully; we are witnessing a general willingness by clients and stakeholders to accept benefits of light annotations—brief and contextual documentation that is generated with the HTML prototype. Instead of reading through hundreds of pages of a document, UX guidance, details, and descriptions are provided as companions to the visualization that, within itself, contributes greatly to the understanding of the application.

Considering Risks

Each of the following is a resource and time-consuming artifact in its own right. Often, you may produce several of these throughout a project. This affects the project's schedule and budget.

  • Vision prototype: A vision prototype is a glamorous, early-stage artifact that is often used to sell the project to leaders and investors. It is more often than not an exercise in wishful thinking: significant changes happen when detailed design and requirement work begins. Beware of an expectation to use the vision prototype "as is" or an expectation to use it for generating Word specifications. Refactoring is often needed and depending on the complexity of the project, you might as well start from scratch.

  • High fidelity prototype: The scope and depth of the prototyping effort should be determined early on so that you are not spending valuable time and energy on visualizing the entire application in great detail. A prototype, even if it is a high-fidelity depiction, is just a sample of the complete product.

  • Usability testing prototype: Make sure that the construction of the prototype is guided by agreed-upon key flows that should be validated during usability testing. Focus first on the interaction that maintains data and context across the flows. Avoid the pressure and crisis of having to make significant changes in order to create appropriate flows in a short time.

  • Detailed specifications: If you need to deliver such a document, make sure that you view the output early on and avoid a serious crisis if you wait until the end of the project to generate the Word specifications.


Practical Axure

Some colleagues of ours swear by Axure and claim to do everything with it. The rest of us typically fire it up when we are ready to wireframe. Frequent questions are when to use Axure and for what kinds of projects or tasks it is suitable. In the following sections, we discuss the aspects of Axure usage, which were motioned earlier, in more detail.

Small Projects

Often, initial conversations around a project begin with "we need a simple website, something very basic..." This later turns out to be not that simple or trivial at all. Ideally, you want to discover this before the contract is signed.

We are not sure what a simple website is, but we know one when we use one. The word "simple" is used on purpose, because a common understanding of "simple" tends to focus instinctively on the most prominent functionality—the number of pages involved. However, this can be a gravely misleading measure, and here is why:

  • Modern web applications have a relatively small number of page templates, such as an overview, list, and details pages. Within each, however, the level of transformation and complexity can be significant, and this is typically hidden during early exploratory discussions.

  • Content strategy is required to prioritize and organize content in a way that is appropriate for a device. This means that for any given screen, the content for a minimum three layouts should be considered. For some types of applications, the increase in complexity can be exponential to ensure the fidelity of multiple workflows and conditions across multiple screens.

  • Another measure could be the number of audiences that the application will serve. Does it need to dynamically change content and functionality based on login? Are any types of registrations involved? Are there any transactions? If the answer to all these questions is no and what you are looking at is stringing a number of pages together with some global navigation, you are most likely looking at a simple project.

However, as we said, there are certain simple sites. Is Axure the right tool for such simple projects? One could argue that Axure is an overkill and that a tool such as PowerPoint or Keynote will be more productive because you can concentrate on the content and not lose energy on learning the prototyping tool. Additionally, the deployment of simple websites today is most successful with platforms such as WordPress or Squarespace. These enable a non-techie person to experiment and create a highly sophisticated website using prebuilt and easily customizable templates. For rapid visualization and brainstorming of ideas and approaches, using Axure on a simple site can help keep the project from unnecessary complications and help determine which technology and service to use.

Web Applications and Portals

This class of prototypes is probably the meat and potatoes for Axure use. While there are many portal platforms, corporations often require custom development and enhancements that meet their business needs. For many organizations, such projects are viewed as transformative and strategic and are significant financial investments. The following are some attributes that such projects have in common:

  • To secure the approval and go-ahead from corporate leaders, the initial UX involvement may be limited to the creation of a highly polished vision prototype. The UX footprint may be small in terms of the actual resources involved but significant in terms of the impact on moving forward.

  • The application involves multiple modules that oftentimes represent discrete organizational business units. It is common for these business units to be spread across the country or the world. Each business unit may have its own rules, requirements, and supporting technologies. These need to be streamlined and unified to make the integrated application work as envisioned.

  • If you are tasked with creating a high-fidelity prototype, keep organizational complexity in mind. As much as possible, document your working assumptions, the guidance and feedback of various stakeholders, their priorities, and potential areas of friction.

  • On the one hand, UX often enjoys a mandate to come up with an all-new, efficient, and great design. Then there comes the push-back and sometimes the blame: UX is too ambitious and risky and the UX team is ignorant of the constraints of legacy and business rules. The ability to walk the fine balance between pragmatic and aspirational is important, especially because UX rarely gets enough time to gain deep knowledge of the business. And so, we recommend that:

    • Don't assume anything. Ask as many questions as you need to clarify the terminology and processes you don't understand.

    • Point out, early on, the potential gaps and implementation risks. In Axure, annotate the risk field for relevant widgets and layout regions you are concerned about, and go over those items during the review sessions.

  • You might truly say that more than just widgets and regions, the documentation of risks related to business rules, which may affect interfaces, is crucial too. We've mentioned that requirements should not necessarily be managed in Axure. However, are references to risk, embedded in the Axure annotations, appropriate? This is a chronic problem that deserves its own book. However, our answer is no. The main concern is that it quickly becomes impossible to track and update the requirements and the risks in Axure, and you end up adding to the confusion.

  • To handle the complexity and specific needs of each module, developing such application requires a large team of business and technology stakeholders; a larger UX team is required as well.

  • Start using a team project early on and communicate a lot with the team about establishing design patterns and other common elements. Balancing the flexibility of work streams and their ability to address unique needs with the overall consistency and integrity of the application is a major challenge, and we will discuss some strategies to address it later in the book.

Heuristic Evaluation

A heuristic analysis of the existing user interface (current state) is often one of the initial steps that UX designers perform at the inception of a redesign project. The outcome can help decision makers determine the scope, budget, and timelines for the project's future state, and also determine an opportunity to get the UX designer familiar with the application and its user-experience issues.

You can very rapidly create a mini replica of the actual application by placing and linking screen captures in Axure pages. Add more details, such as drop-down lists, form fields, and action buttons over the appropriate places in the screen captures, to create a hybrid of an image- and widget-based prototype. Add your comments in relevant annotation fields and generate an HTML prototype and a Word document, which you will use as you walk the stakeholders through the findings.

User Validation

A by-product of creating an interactive prototype in Axure is, of course, the fact that you have a tremendous instrument to use in various user validation activities, such as focus groups and usability tests (UT); this is a no-brainer. However, it is important to include the refactoring work necessary to use the prototype for such activities in the project's budget and timeline. This is especially important for complex applications that adjust the user interface based on the user login. Here are some points to keep in mind:

  • Make sure that the scenarios planned for UT are actually built into the prototype. Making the prototype work for unplanned scenarios may involve considerable rework and modifications to the construction of the file.

  • If the file is also intended to be used to create specifications, how will the tweaks and added interactions needed to make the prototype work for UT affect the generated specs?

  • Does it make sense to duplicate the current file and have a dedicated file just for the purpose of UT? It really depends on where you are in terms of construction. The benefit of developing the file separately is that you can work quickly and tweak the construction without having to worry about the specifications or impacting other sections of the project. On the other hand, it means that any updates made to the production file will have to be updated in the UT file.

Deliverables – Prototypes and Specifications

Are you contracted or expected to deliver only an interactive prototype or the annotated specifications as well? The following list takes you through some important pointers to consider. Don't worry about Axure terms and functionalities you are not familiar with, since we will cover those later in the book.

  • If specifications are in play, what are the expectations for the format and delivery of those specifications? Is it, for example, an exhaustive Word document or a light HTML-based annotated version of the prototype?

  • Did you have an opportunity to discuss these flavors of documentation with the relevant stakeholders (typically the development team) or are the specifications mentioned casually and their scope only implied? If this is the case, you should get explicit clarifications as early as possible.

  • Ask for an example of a previous specifications document used by the development team to get a sense of what is acceptable.

  • If you are contracted to deliver an interactive prototype, what level of fidelity is expected? Interactivity means different things to different stakeholders. Their expectations are often shaped by past experiences, if any, with user experience projects.

  • If the application needs to support different types of user roles based on login, are you expected to simulate the entire user experience for each of these roles or just for a primary role? This point alone can make or break a project because stakeholders may demand to see the differences in each role, while you have budgeted and scheduled the work for simulating only one.

  • Knowing in advance that various sections within wireframes are global, that they will have to reflect user types, or have multiple states, implies the use of masters and dynamic panels to reduce wireframe redundancy and other construction inefficiencies. Use of masters also implies the possible use of Raised Events.

  • Demonstrating how the interface renders for different user types or for different workflow paths is likely to involve the use of variables and functions, and as mentioned earlier—the use of masters, dynamic panels, and raised events. Knowing what is expected will help you acquire the Axure skills that you need in advance.

  • Are you expected to simulate features such as type-ahead or is it enough to call out such behaviors in the annotations? It is not that difficult to build the simulation in Axure, but is there value, and more importantly, the time and budget allocated for constructing such common interactions?

  • How much of the interface is expected to be prototyped, and how much can be just defined by static wireframes?

  • Often, the conversations around the scope of work occur before the actual work has begun. It is a good idea to agree with stakeholders on the desired wireframes, the complexity of each wireframe, and priority of the wireframes and flows that will be simulated in detail and the ones that will be addressed as static wireframes.

  • Is the plan to quickly deliver a high-fidelity vision prototype first and once the project gets a green light, use it for detailed design and specifications? If this is the case, keep in mind that refactoring—the need to rebuild sections of your Axure file—is likely to be required. There are several reasons for this:

    • To begin with, the work on a vision prototype tends to be a very high-level show off, with the best of all the possible-functionalities and features in the world. Often, there may not be enough time or details to validate that the proposed user experience can actually be supported by the underlying business processes or technology. When work on detailed design moves forward, many of the assumptions that were made for the vision need to be scaled back in order to meet the actual business requirements and technical constraints.

    • One particular pitfall to watch for has to do with administration screens. Most applications have some sort of administrative functionalities that range in capabilities, from allowing a super user to assign access permissions to other users to setting the values of a wide range of defaults and other parameters. As very few users will actually interact with this part of the application, it is often dismissed casually in early conversation, only to resurface deep within the project.

Create an inventory of all the modules and key screens of the application. With the relevant stakeholders, agree which screens are in scope of what treatment. This will be the blueprint for working on the prototype and for change management as a result of scope realignment.


Tips for Using Axure on Large-design Projects

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 on the finer points of using Axure

  • At the beginning of the project, pilot a number of ways for 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, such as before major usability tests, or before resuming work on the file following major de-scoping or major design modifications. Other refactoring effort may be required:

    • Between the completion of wireframes and writing the specifications

    • After the completion of a release

  • Plan on having one wireframe structure for prototypes and another for specifications


UX and Stakeholders' Perspectives

In his classic movie Rashomon, Akira Kurosawa unfolds the details of an event by telling the story from the perspectives of multiple characters, including a dead person. Each character, who was also a direct witness to the event, recounts the story by telling the narrative from their point of view. That same form of the event actually happened is undisputed, but as it happens, the stories, while similar in structure, end up contradicting each other.

User experience practitioners often find themselves in a Rashomon situation because of UX's unique position at the intersection of business, engineering, people, and systems. The success of the UX project rests on our ability to fuse the various entities in a coherent and elegant way.

Our colleague, Sam Spicer, often speaks of empathy being vital to the role of UX. Understanding the perspectives of the stakeholders we work with is important not only for arriving at a good design but also for a strong collaborative environment that can handle the stresses of constant change and fleeting schedules.


Regardless of the organization's type or size, any successful commitment to high standards of user experience and satisfaction must be driven from the top down. Chief executives who take time to learn and understand the importance of UX are the most important sponsors of our work in the organization. The commitment will materialize in strategy, resources, and budgets. When such recognition comes from the very top, the tendency is to discount the value of UX because many of the deliverables are dismissed as soft and hard to measure.

Obviously, your interaction with the senior leadership is tied to variables such as your seniority, the organization size, and the project you are involved with. Still, the following situations are common:

  • For small companies, the project is likely to be really important and top leadership will take a close interest in it, sometimes too close. A desire to direct or control the outcome and influence the design is not uncommon. Such circumstances may get you stuck between the project's leadership and the company leadership, which are often not the same group of individuals. Your Axure file can become an invaluable asset to all as a live document that captures key decisions around the experience. Consolidation of diagrams, flows, wireframes, and relevant documentation makes it possible and easy to access and present relevant support to a design decision.

  • In a large organization, your contact with the senior leadership may be limited only to those who are directly leading the project because there are just way too many levels of hierarchy. Still, mission-critical projects are visible at the executive suite because the organization needs it to succeed and because it is expensive. Your work will be exposed to the scrutiny at the highest stratospheres of the organization. Regardless of your audience, it is important that the construction quality of your work is high, even when you are only experimenting with high-level concepts.

Project Management

Project managers are tasked with tracking the progress of projects and facilitate solutions that help resolve roadblocks along the way. In many projects, UX does not have the benefit of a dedicated project manager. This can lead to problems for medium and large projects, such as:

  • If a project manager is not budgeted to the project, it is a good idea to raise this as a flag and take extra effort in developing a comprehensive, mid-level plan yourself

  • If a project manger is budgeted, make sure to jointly review the entire project plan, ask questions, and flag dependencies such as where a projected UX effort has not been considered

For example, many plans do not account for the time it takes to refactor the Axure file from a vision prototype to detailed design prototype. Others don't take into account the time it takes to iterate and revise the prototype. Sometimes, the time it takes to arrange the logistics of usability tests such as recruiting is not considered. The more time spent early on with the project manager as the plan is being developed and revised, the better the project will track later on.


One would not be blamed for thinking that developing the user experience and software development are complementary processes. However, as we often find out, there is a gap between UX and engineering. There are many reasons for the friction, but a fundamental means to resolve these is communication.

It is surprising to hear stories about large projects where the interaction designer and the developers only got together well after a splashy high-fidelity vision prototype, commissioned by the business side of the organization, has been used to drive the top management to move forward with the project.

The problem, from the perspective of the development team, is managing the expectations of the top leadership that the new application will have a close resemblance to the vision prototype and be in production in no time. If only life was so simple. Engineering leaders often express concerns that UX does not always take into account the constraints of available technology, impact of the new UX on performance, scarceness of development resources available to the organization, or the complexities involved in the accessibility and localization implementation of the new UX.

These concerns are often valid and true. With Axure, however, UX has a tool that helps improve communications via visualization of interactivity and integrated annotations. Conversations, analysis, estimation, and adjustments can start early on in the development life cycle and reduce the stress on the engineering team.

Visual Design

Visual design introduces some of the most daunting challenges for rapid prototyping projects and a hidden iceberg for Axure prototypes. Why? This is because of a gap, sometimes a serious one, that grows between the wireframe prototype and the visual design.

This gap poses both UX and development risks because of the need to reconcile between the two presentations of the same screens. Sooner or later, a refactoring of the Axure prototype will be needed, especially if the intent is to keep using the file throughout the entire life cycle of the product.

The two sets of wireframes are developed asynchronously. Normally, we start with Axure wireframing as rough conceptual sketches that evolve through rapid iteration. These wireframes address information architecture and actionable tasks and the layouts are often tentative. With Axure, we can enhance these rough ideas and evolve the concept as an interactive prototype that demonstrates the vision for navigation and interaction patterns.

All this work, however compelling, tends to be in grayscale without visual design. As user experience architects and designers, we want to isolate the feedback we obtain from stakeholders and potential users. The conventional wisdom is that adding visual design cues at such an early point is adding unnecessary noise to the feedback. This is because people's response to colors and layouts are both extremely subjective and strong, and the concern is that such feedback tends to push more substantive issues to the background.

It is impossible to separate the visual design from the user experience. This argument sounds especially compelling when it comes to the design of mobile apps, where beauty is inherent to the design of the user experience.

What often happens is that at some point in the UX process, visual design gets involved and the ugly duck emerges as a beautiful swan. Now, everyone needs to start looking at the two sets of the design (wireframes and the visuals). Often, the two sets will continue to evolve on separate tracks because while the work with the visual designer takes place, the work on finalizing the Axure wireframes for specifications continues.

Sometimes, UX designers do not fully appreciate the complexities and challenges that visual designers face. Busy and stressed by our own issues, it is tempting to dump on the visual designer a great deal of information, often not fully baked, and expect that the designer will get it somehow. However, it is often the case that the visual designer has very little time to dive into the depth of the application.

The bottom line is that since you will know when the visual design phase is planned, you should be able to build into the timeline time to refactor the prototype so that at some point, the approved visual design is reflected in the wireframes, prototype, and documentation.

The UX Perspectives

When individuals or organizations hire an architect, they are typically influenced by that person's body of work. However, they are also certain that as a certified architect, the person has formal educational and professional qualifications. The clients and contractors who work with an architect also have a formal understanding of the type of deliverables the architect needs to provide. There are also legal and other regulations the architect must abide by. After all, you would not take an uncertified architect to design a skyscraper or your home.

Hiring a qualified user experience practitioner, on the other hand, is somewhat like rolling the dice despite the fact that the project's scope and complexity makes it like a skyscraper in comparison. It is not quite clear to the client what exactly UX is. Unlike architecture, anyone can call themselves an experienced architect as there is no standard professional certification or accreditation that can serve as a lighthouse to help a client choose. However, this, by no means, is a fault of our discipline. Architecture has evolved over thousands of years, but the formalization of who is a qualified architect is a relatively modern development.

As in any profession, there is the level competency and mastery of 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 real 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 you need to fill?

  • Axure is becoming a good skill to master. Will learning the tool open up new employment 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 most 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 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 projects, efficiency, savings, and increased profits in terms of reusing the widget libraries, masters, and generators?


The Axure Perspective

As users of software, we demand constant improvements. As professionals who are involved in the process of making software, we can be more sympathetic to the challenges and tradeoffs that Axure, the company, is facing:

  • The more features and capabilities Axure supports (adaptive views, advanced interactions, logic, variables, functions, and so on), the more complex the tool becomes. In fact, we already find a demand in the market for specialized Axure prototypes, people who can take Axure to the max and create really powerful vision prototypes. Ironically, freeing ourselves from dependencies on developers and the ability to quickly and easily create an interactive prototype is exactly the goal that Axure sets out to tackle, being a tool for non-developers. So, how can the company balance these two extremes:

    • Prototypes versus specifications: The demand for high-fidelity vision prototypes is on the rise and is becoming a norm. The turn-around times for such prototypes is shrinking, and they are extremely influential in getting decision makers to give the green light to ambitious development projects. However, turning a vision prototype into a specification—a deliverable that is often contracted for—is most likely to require refactoring. This effort can be substantial and yet, often not planned for, budget or schedule wise. Clearly, there are some challenges around reducing the gap between prototype construction and specification generation. How will Axure try to address this in the future?

    • The landscape of UX is rapidly changing. Apple, through iPhone and iPad and its ongoing quest to integrate iOS, its mobile operating system, with OS-X, its desktop operating system, is impacting the user experience in profound ways. As a result, the syntax of interaction patterns is evolving. New multifinger gestures are a good example. How will Axure support the creation of prototypes for the next generation of devices?



Our success as UX designers rests on our ability to synthesize and express the many diverse, often conflicting inputs, we gather from sources such as business and engineering stakeholders, user research, and data from analytics. At the end of the day, our goal is to find the pragmatic balance, opportunities, and innovation for the best user experience possible, regardless of the device or operating system that drives that device. To help us conceive, visualize, communicate, and document our vision, a specialized UX tool is invaluable.

Axure is considered by many to be the tool of choice for the UX industry worldwide because the company works hard to evolve the tool so that it supports the escalating demands on UX. The company listens closely to practitioners as it strives to balance a rich feature-set with complexity and cost, and has proven repeatedly that it is the right tool to help us in our demanding line of work.

The following chapters will introduce you to the wealth of features Axure offers in the context of real-life circumstances. As you read the book and get a better sense of how Axure might fit your needs, keep in mind that Axure is just a tool. There is no substitute to rigor, collaboration, and iteration to achieve a successful prototype that communicates our design for a product that will exceed the expectations of our clients and their users. The next chapter provides a comprehensive guide to Axure's user interface and various features.

About the Authors

  • Ezra Schwartz

    Ezra Schwartz is a multidisciplinary design leader with a holistic approach to experience strategy and design. He led projects in diverse settings, from Fortune 50 companies to start-ups in finance, healthcare, aviation, manufacturing, education, research, and other industries, and is the author of two books on prototyping.

    Throughout his career, Ezra has been devising and refining qualitative and quantitative design methods, advancing rapid interactive prototyping techniques, streamlining iterative design guided by continuous user feedback, advocating for accessible design, and mentoring junior practitioners.

    Ezra lives in Hyde Park, Chicago, where he draws serenity and often conceives design solutions while running along the shores of the magnificent Lake Michigan.

    Browse publications by this author
  • Elizabeth Srail

    Elizabeth Srail has been creating and leading designs since 2001, and throughout that time, she has learned that employing the lesson her parents taught her at a young age, which is to "put yourself in that person's shoes", is the key to a successful design. In an age where everyone is talking, mostly through social media, Elizabeth has been listening. She takes what she hears from the users and stakeholders, and removes or diminishes the problems these people face with designs that are thoughtful, easy-to-use, fun, and pretty. She employs that same lesson when managing others as well and believes that kindness is the greatest illustration of strength. In addition, Elizabeth has guided large organizations by educating leaders on the nuances of the UX process and advising them on how best to implement this practice into their current delivery methodology. Elizabeth started using Axure in 2008 and was happy that Axure allowed her to demonstrate her vision by creating interactivity without having to code and without having to use words to sell her designs; the design and experience spoke for themselves. She met Ezra in February 2009, and in the following years, they collaborated on how best to optimize Axure, often discussing and debating the evolution of the UX practice. Elizabeth is a devoted practitioner and teacher of Ashtanga yoga. Practicing yoga has allowed her to be more creative and handle the stressors of work with poise.

    Browse publications by this author
Prototyping Essentials with Axure
Unlock this book and the full library for FREE
Start free trial