Book Image

Axure RP 6 Prototyping Essentials

By : Ezra Schwartz
Book Image

Axure RP 6 Prototyping Essentials

By: Ezra Schwartz

Overview of this book

Wireframes, interactive prototypes, and UX specifications are among the fundamental deliverables of every UX project. They are also the most labor and time intensive to produce due to constant changes in business requirements. Given these circumstances, Axure is quickly taking over as the preferred tool for prototyping. However, prototyping in Axure is strikingly different from the conventional method of producing static wireframes and to rapidly develop interactive prototypes in Axure, you'll need to have a good understanding of the tool and its features.Whether you are an individual practitioner or a member of a UX team, a consultant, or an employee, this book will teach you how to use Axure, one of the leading UX tools. You will learn to use Axure for producing top-quality deliverables and tackling the demands of rapid iterative UX projects of any complexity and size, and for any platform and device.Axure RP 6 Prototyping Essentials takes a very pragmatic approach to showing you how to use Axure and produce impressive deliverables while saving labor and time. You may not be in a position to change how projects are scheduled, budgeted, and managed, but you can be more creative and productive by mastering one of the leading UX tools in the market. After an initial introduction to Axure's user interface, terminology, and features, this book walks you through a medium-size UX project: a digital library that sells books, newspapers, and movies. Although some aspects of the prototyping process are simplified for the sake of clarity and efficiency, the demo project is an opportunity to discuss in context and in sequence topics such as addressing business and technical requirements, handling use cases and flow diagrams, low and high fidelity wireframe construction, interactivity, writing annotations, generating detailed UX specifications, and traceability. For the most part, Axure 6 RP Prototyping Essentials can be read in sequence or used as a reference guide.
Table of Contents (18 chapters)
Axure RP 6 Prototyping Essentials
Credits
Foreword
About the Author
Acknowledgement
About the Reviewers
www.PacktPub.com
Preface
Index

The art of UX prototyping


Prototyping is an ancient practice. Back in the fifteenth century, Leon Battista Alberti described an event that took place in the First century BC. In his classic text named 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". He 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.

Another way to think about the event has an immediate relevance to us, two millennia later. 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 every project they work on. Often, the client might have a clear idea in their head of the exact way the building—and for that matter, the software—should look and function. Sometimes, the client has no idea about the structure or the function of the software but has a pressing need to have such a structure in place, in order to fulfill a business or some other pressing need.

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

However, beyond borrowing the terminology from architecture, aspects that relate to engineering and process rigor take much longer to implement. For example, the use of modeling in user interface and user experience design, as we see it today, came in quite late in the software development life cycle. This perhaps explains why a very high number of software projects fair badly, but our cities are not littered by the ruins of collapsed buildings. Compare a large architecture project to build a 100-story skyscraper, with a large enterprise software project. What are the odds that both will be fully up and running within years? They 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 to the typical chaos of software projects (perhaps with the exception of software for airplanes and such no-failure use), we probably have some ways to go. It is an evolutionary process.

The truth is that, of the billions of private residents, 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. You can read Donald Harington's The Architecture of the Arkansas Ozarks, for a wonderful account of such an evolutionary process.

Alberti further writes that "Having constructed those models, it will be possible to examine clearly and consider thoroughly the 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, order of entities, and also the ability to use the prototype for cost and effort estimation.

Another example of providing a client with 'wireframes' and ensuring alignment with their needs is mentioned in the book Painting and Experience in 15th-Century Italy by Michael Baxandall, who writes about the fifteenth 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

Therefore, it turns out that we did not quite invent the prototyping wheel after all. The value, 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 a rich user experience that is particularly challenging for UX practitioners.

Most structures don't involve dynamic interaction with the user. Buildings stand there, whether there is an occupant or not. Moreover, when you enter a building, rooms do not contextualize themselves instantly to reflect your identity. When it comes to software and prototyping a rich user experience, the complications come from the need to demonstrate the following:

  • Action and response: The prototype needs to simulate possible paths that a user would have on any given screen and the system's appropriate responses to actions 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.

    For example, the prevalent navigation model back in the client-server model of the '80s involved moving from one window to another, as part of a workflow involved in completing a task. In the '90s, common web navigation was hyperlinking from one page to another, facilitating a similar goal. These days, with asynchronous in-page data updates, the need to negotiate multiple windows has been greatly diminished, but the complexities of prototyping in-page data refreshes 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 preferences they have set in an earlier session, and a paying user needs access to additional content, based on 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 their investment in the project, based on strategic goals, practical budgetary, and technical constraints. The prototype, which often begins as a fully-fledged visionary concept, needs to be able to support 'graceful degradation', or fallback to less-ambitious capabilities of the present, and scale in the future.

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

  • Exception handling: One of the toughest requirements is to demonstrate the way an application will respond to the rules for moving through an interaction path; this can be subject to either user or system override.

Like architecture and construction, software is an evolving art and science, but 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 have evolved over centuries and stay relevant for a long time, in technology, what worked ten years ago is practically ancient and moot by now.