"We shape our tools, and thereafter our tools shape us."—Marshal McLuhan
I find Marshal McLuhan's insight to be especially intriguing in the context of tools that help us conceptualize and express user experience. In fact, my motivation to write this book has been shaped by my personal experience with Axure, since I started using it back in 2007.
What struck me then, and continues to excite me today, was the freedom to design, test, iterate, and present fully-clickable interactive prototypes. I did not need a developer. I did not need to spend months to learn a programming or authoring language. It was easy, fast, and fun. As someone who does user experience for a living, Axure afforded me my own user experience.
Within a few hours, I had my first prototype running, and since that day, I never looked back, and have since rarely used Visio, my previous wireframing tool. I also realized that, in addition to being able to create interactive prototypes, Axure helped me deal with a major chore—creating and updating the user interface functional specifications document.
If you ever created a specifications document the traditional way by using Visio, Word, and a screen capture utility, you know the drill—a tedious process that involves adding footnote tags to Visio wireframes, taking screenshots of these wireframes, saving them, importing them to Word, and finally, writing the relevant annotations. If you update the wireframe, you have to retake the screen capture, save, replace its version in Word, and update the annotations. Multiply this process by the number of wireframes in your project, and the magnitude of the effort becomes clear and daunting.
As the UX design is inherently an iterative process, the specifications update process is a real drain of time, money, and energy, which is bad for everyone involved in the project. With Axure's integrated specifications, I found an innovative approach that reduces, greatly, the manual process. Axure numbers the annotations on the wireframes, takes the screenshots, and organizes the entire content in a customizable layout. While configuring the 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.
Axure's support for team collaboration was an important enhancement that helped cement its adaptation among UX professionals, because it underscored the dramatic shift in the perception of UX among business stakeholders, as critical to the success of software projects. As any sizable project requires multiple UX resources, collaboration has become a prerequisite that Axure addresses with its Shared Projects feature.
As I started to use Axure, I occasionally stumbled on technical issues or had questions I could not figure out. Responses were prompt and detailed, files I sent for checkups were reviewed and issues explained, and occasionally, immediate follow-up of software updates that fixed bugs I mentioned. This dedication to customer support has been, and continues to be, by far, the deepest I have ever encountered.
I also discovered an incredibly helpful and responsive community of fellow users worldwide, on Axure's Discussion Forum. Typically, you can get a helpful response to your query within hours and people are generous with their expertise. Over the years, as I gained some expertise with the tool, it has been nice to be able to help others in the forum. I will admit that this level of support is very important to me. When a tool becomes critical to my work, it has a direct impact on my livelihood. Support feels like a lifeline in times of crisis, and knowing that such a level of support exists, plays a major role in my loyalty and tolerance.
Axure's value was so compelling that I was able to convince clients and team members to approve the use of the tool, back when it was far less known among UX practitioners. This UX-centric integrated environment for wireframing, specifications, and collaboration also carried a price tag that was a small fraction of the cost and implementation complexities of enterprise tools. Occasionally, clients would raise a concern about the ability to find UX resources who know how to use Axure. UX designers would raise a concern about switching from tools they were very familiar with to a new tool. These two perspectives can potentially feed each other in a loop, which makes it difficult to effect change. It really takes external pressures to drive change.
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 software 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.
With increased demand came also the pressures to deliver on time and within budget, both often aggressive to absurdity. At a certain point, too-ambitious schedules create serious friction with core principles of user-centered design, an inherently time consuming methodology that calls for contextual research, iterative design, and user validation. I realized, as many others did, that on top of helping me produce excellent deliverables on a tight schedule, Axure is helping me stay profitable, because I can deliver a lot more value to my clients, in less time and less sweat.
This is an important point. At the end of the day, design agencies and independent consultants need to turn a profit in order to stay viable. It is impossible to stay viable for long, if you have to double and triple your working hours just to keep up with the pressure of constant updates to a prototype and specifications. In-house UX teams must also control their cost and increase their productivity. Axure helps maintain profitability, because it is relatively easy to master, and it affords substantial efficiencies through clever use of customizable patterns, templates, and automation.
In conclusion, and reflecting back on McLuhan's observation earlier in this chapter, Axure is a tool that has been shaped by UX designers over the course of nearly a decade. At the time of writing this book, it is widely used, with over 30,000 licensed copies world wide, running on Mac and Windows. Axure is probably the de facto UX design tool in our industry. To what degree does it shape its users? It is for each of us to discover.
In this chapter, we introduce a prototyping checklist that covers the diverse set of variables that are involved in user experience projects, and how your approach to constructing an Axure project file might be affected by the specifics of your own project. Also, in the spirit of User Centered Design , and because UX projects are a collaborative effort, I thought it will be valuable to include the insights and expectations of real people who've experienced work on UX projects in various roles ranging from business, project management, visual design and development, as well as other user experience practitioners.
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...".
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.
Before you embark on an Axure prototyping project, you should carefully consider several variables that will affect your approach to the prototype's construction and logistics. The following checklist is probably relevant to any type of prototyping software you may use, and not just to Axure. However, as you will see, neglecting to think in advance about these issues can cause serious roadblocks at various points in the project. The checklist is driven by the deliverables you are contracted to, or are expected to, deliver. This, in my opinion, is the most practical and beneficial angle with which to approach the work ahead.
In the case of UX projects, size and scope matters, the type of application, and the purpose for which you are going to prototype can have a significant impact on the time, budget, and number of UX resources needed to get the job done on time. Surprisingly, it is not uncommon for projects that begin as small-scale efforts, to mushroom into increasingly complex and expensive ones.
UX resources, including internal teams, often do not have good visibility into the real drivers that move the project within the company. As a result, you may not always have the benefit of knowing in advance about what is going on, and changes to the scope and direction may come as a disappointing and frustrating surprise. There is little that can be done about such situations, but you can take a proactive approach to the way you construct your prototype, such that you have the ability to handle change, with reduced impacts to your own workload.
I am not sure what a simple website is, but we know one when we use one. I am using the word "simple" on purpose, because often, initial conversations around a project begin with "we need a simple website, something very basic...", which later turns out to be not that simple or trivial at all. A common understanding of 'simple' tends to focus instinctively on the number of pages involved. However, this can be a gravely misleading measure.
Modern web applications have a small number of page templates (for example, an overview page, a list page, and a details page), but within each, the level of transformation and complexity can be significant.
Another measure could be how many audiences the application will serve. Does it need to dynamically change the content and functionality based on login? Are any types of registrations involved? Are there any transactions? If the answers to all of these are no, and what you are looking at is stringing a number of pages together with some global navigation, then you are most likely looking at a simple project.
Is using Axure a good option for such simple tasks? Most likely not, especially if this is a one-time project, and you don't build user interfaces quite often. One could easily argue, and quite successfully, that in order to concentrate on the creation of content for a simple site, a common tool such as PowerPoint, will be more productive, because you can concentrate on the content and not lose energies on learning the prototyping tool. Additionally, the deployment of simple websites today is most successful when people use existing platforms, such as, WordPress or Squarespace . These enable a non-technical person to experiment and create highly sophisticated websites using prebuilt and easily-customizable templates.
This class of prototypes is probably the 'meat and potatoes' for Axure use. While there are many portal platforms, corporations often require custom developments and enhancements that feed their business needs. For many organizations, such projects are viewed as transformative and strategic, and are a significant financial investment. The following list shows some attributes such projects have in common:
In order to secure approval and a 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 actual resources involved, but is significant in terms of the impact on moving forward.
The application involves multiple modules that often represent discrete organizational business units. It is not uncommon 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, which 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 the 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.
Forward and backward vision. On one hand, a UX often enjoys a mandate to come up with an all-new, efficient, and great design. Then, there comes push back, and sometimes blame; the UX is too ambitious and too risky, and at times the UX team is ignorant of the constraints of legacy and business rules. The ability to maintain the fine balance between pragmatic and innovative is important, especially because a UX rarely gets enough time to gain deep knowledge of the business.
Don't assume anything. Ask as many questions as you need to clarify the terminology and processes that 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 review sessions.
To handle the complexity and specific needs of each module, developing such an application requires a large team for business and technology stakeholders, and to work with everyone, a big UX team.
Start using a shared project early on, and communicate a lot with the team about establishing design patterns and other common elements. There is a need to maintain the balance between providing each workstream with the flexibility to address the unique needs of the part it is tasked with, but also, to keep in mind the overall consistency and integrity of the application.
Apple continues its long tradition of affecting the user experience in profound ways. As it narrows the gap between mobile devices and the traditional computer experience, new interaction patterns, such as figure gestures, have been introduced in the lexicon of direct manipulation methods. With Axure's shared libraries, you can easily create prototypes that simulate the appearance of most popular mobile devices, from iPhones and iPads to Android.
Increasingly, organizations seek to extend their web applications from the Web to the mobile space, and you can prototype such apps in Axure, demonstrating their use on the targeted device.
One of the initial steps that UX designers are often asked to perform, at the inception of a redesign project, is a heuristic analysis of the existing user interface. The outcome can help decision makers to determine the scope, budget, and timelines for the project, with 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 droplists, form fields, and action buttons, at the appropriate places in the screen captures, to create a hybrid of images with a 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 guide stakeholders through the findings.
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, in the project's budget and timeline, the refactoring work necessary to use the prototype for such activities. This is especially important for complex applications that adjust the user interface based on the user login.
Make sure that the scenarios planned for UT are actually built into the prototype. If not, adding those may involve considerable work 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.
Are you contracted, or expected, to deliver only an interactive prototype or also annotated specifications? The following list takes you through some important pointers to consider. Don't worry about Axure terms and functionalities you are not familiar with, as we 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 specifications mentioned casually, with their scope only implied? If the latter 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 a primary role? This point alone can make or break a project, because stakeholders may demand to see the differences for each role, while you have budgeted and scheduled the work for simulating only one.
Wireframe planning and construction: Knowing in advance that various sections have to reflect different types of users or states, should mean use of masters and dynamic panels. This will reduce redundancy of wireframes and rework, as the use of masters will require the use of raised events.
Axure skills and techniques: Demonstrating how the interface renders for different users or different workflow paths, is likely to involve use of variables and functions, and as mentioned, use of masters, dynamic panels, and raised events. Knowing what is expected will help you acquire the Axure skills 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, is 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 conversation around the scope of work occurs before the beginning of the actual work. It is a good idea to agree with stakeholders on the set number of high-priority screens and flows that will be simulated in detail, with the rest to be addressed as static wireframes.
Is the plan to quickly deliver a high-fidelity vision prototype first, and once the project gets the 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 very high-level show off, with "best-of-all-possible-worlds" functionalities and features. Often, there may be enough time or details to validate that the proposed user experience can actually be supported by the underlying business processes or technology. When the work on the detailed design moves forward, many of the assumptions that were made for the vision need to be scaled back in order to meet 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 capability, for example, allowing a superuser to assign access permissions to other users for 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 conversations, only to resurface once deep into the project.
Create an inventory of all the application's modules and key screens. With the relevant stakeholders, agree which screens are in scope for what treatment. This will be the blueprint for working on the prototype, and for change management, as a result of scope realignment.
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 some 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, technology, people, and systems. The success of the UX project rests on our ability to fuse the various entities in a coherent and elegant way.
Understanding the perspectives of the stakeholders we work with is important, not only to arriving at a good solution, but also for a strong collaborative environment capable of handling the stress of constant change and fleeting schedules. The coming pages provide the insights of real people: business process architects, product managers, project managers, visual designers, development managers, and developers. I had the pleasure and benefit of working closely with many of these people over the years, and their insights are provided below, as they correlate to various chapters in this book.
You are likely to interact regularly with several types of business people: top executives, business process architects, product managers, and others. In many projects, the entire effort is driven by the business, and the success or failure of UX initiatives indeed rests on the informed support of top executives, who firmly understand the benefits of investing in user experience. UX practitioners often do not get much visibility into the tactical or strategic goals that the top management has for the project, which may lead to frustration and misaligned expectations on both sides.
I have asked Oren Beit-Arie, Chief Strategy Officer at Ex Libris, a leading global provider of library automation solutions, to share his thoughts about management and UX. This is what he has to say:
Organizationally, a company may not be built around UX core competencies, and outsource it. Consequently, UX may be the first to be cut because it is not clear to management that UX contributes enough value, and there is suspicion that the consultants are just exaggerating up the value of their work. The recognition of the importance of UX for our company and products has evolved over the past decade, as we gradually learned to integrate UX with the development process.
When you are designing a customer facing application, it is easy for stakeholders to form their own personal opinion on how compelling a proposed UX is. That's because we can see ourselves in the role of the user, compare the experience with the competition, and with other applications we are familiar with.
But when you develop expert systems, and administration tools, Management and other stakeholders face a true challenge with the UX because it is difficult to figure out the best user experience. Managers have less intuition about how expert users do their work, how to improve and innovate something you are not fully know in great detail?
As a result of the evolutionarily path we took, we have a lot more confidence in dealing with this situation, and the impact of UX on our products. Today, we can also invasion how to use patterns we experienced on our iPhone and other mobile devices, might work on a particular product, because such patterns are so ubiquitous.
Generally, we find that, as Management, we think about UX as an investment effort that has two aspects to it:
The first deals with relatively straight-forward questions that are easy for management to drive towards and benchmark against: How to facilitate tasks and workflow via the UX? How to improve the productivity and efficiency of an application? How to satisfy the need to demonstrate lower cost of ownership? How to get a smart UX especially for complex tasks, How to make a product accessible, and so on. This is a very important aspect, but perhaps more tactical, as it is a solution-based approach.
The second aspect is less clear but more strategic and far-reaching; where Management, often struggles to determine the appropriate answer and make the proper investment: It involve aesthetics, design language, high production values, and our product, even corporate identity: How to balance between sleek, supper commercial design, and a more appropriate, practical design?
Increasingly, the standards and expectations our customers have, are not related to the specific class of applications we are dealing with. Rather, they form their experiences based on their experiences with applications from totally different domains. The issues become - are user expectation set too high due to these other apps? Think about Pixar producing eBooks...How to balance between making you product unique - and yet not so different - How to preserve your identity?
New realities force management to think about the competitive landscape, and new customer demands such as dealing with multi-device delivery: Mobile, tablets, desktops - which translate to the cost and complexities of multiple technologies, and on top of these - creating the UX for these. Another example for a challenging dilemma was, should we wait to HTML5 or do something now with existing technologies? Other questions related to this aspect involve localization, personalization and customization - How much to spend on these features and capabilities?
It is a process, and working closely, and iteratively with UX helps resolve many of those questions and concerns.
Tim Robb is a senior manager at NetApp, with whom I had the pleasure of collaborating some time ago. I have to admit that I am still under the spell of his leadership style and the way he worked to get the team through challenges that, at the time, seemed insurmountable. Here are Tim's thoughts on collaboration with UX, in this case, a team of UX designers.
Q: What are your expectations from the UX team?
I'm looking for the UX team to understand the context in which our users will interact with an application and what the users value above all else... That is, I expect the UX team to go beyond time-on-task analyses and develop a full understanding of why the users would want to use an application AND then how the application will impact user productivity, how it will hold their interest, how it will pique their curiosity, how it will help them understand and hopefully encourage them to return and view the application as an enabler rather than a "burden"...
The UX team should apply its expertise to help the business/functional/technical teams from "getting in their own way". We can all fall in love with automation, technology, the latest-and-greatest, "process simplification", our pet features, etc. However, the UX team should be speaking as the surrogate voice of the user. They should keep the business teams honest in representing and protecting the users' best interests. They should help the project team approach "stretch goals" in fostering end user satisfaction. Don't lull us into adopting "best practices" at the expense of delivering something remarkable, something that could deliver a competitive advantage.
In some respects I expect the UX team to serve as a kind of safety net that drives the business to deliver a harmonized blend of critical functionality and usability. The UX team should play a key role in leaving users with the impression that application delivery is not something we did TO THEM, rather something we did FOR THEM.
Q: What are some challenges in reviewing UX?
Protecting the time to do it... the business is trying to balance requirements-gathering, BRD (Business Requirements Document) development, conversion to functional/technical documentation, etc. and bringing UX team up to speed on all the nuances within and across workstreams.
Given challenge above, we had to 'divide and conquer' to review and advise... I think preferences for UI elements tend to be very personal which can result in different opinions when different parties review at different points in development lifecycle (and I would assume, frustration on the side of the UX team when the feedback changes depending on who is weighing in and when)
Trying to understand how to wade thru a wide variety of options... Looking at Wireframes, mockups or some other graphic representation is very helpful – critical for me (and also I think for sales and marketing users, who I think tend to be more "visual")... but then it can be a challenge to keep up with the changes and proposed changes and user-reaction/feedback to those over time.
Q: Do interactive prototypes help clarify the UX, or do they make things more complicated, slowing down the project?
I think the answer is "Both". Prototypes definitely help clarify the UX and in many respects "bring it to life"... but they do take time to develop, review, refine, review, assess, refine, etc.
I think an equally impactful issue for consideration is how close can/will the final product be to the prototype?... Project capacity/timeline, technical limits or performance considerations (for instance if application is integrated to or embedded in another application framework) can all impact the ability to match a prototype to the final deliverable. Users who see a prototype seem to magically develop a "photographic memory" of that cool new UI or UX treatment of something they've labored with in the legacy system for years... If the end product can't or doesn't deliver those one or two favored aspects, you can run the risk of not meeting up to the expectations the prototype set in their mind. I don't think this is a reason to shy away from prototypes, just a cautionary note to be careful how you position prototypes/wireframes.
That being said, we don't subscribe to the "under-promise, over-deliver" strategy. Despite good intentions, that can easily turn into a "under-promise, under-deliver" situation and worse, can actually prevent the team from reaching stretch goals or creating differentiating outcomes.
Q: What can UX teams do to improve the communication with business people?
Simply be honest with the users and the project team... don't tell either of them what you think they want to hear, tell/show them what is realistically possible within the constraints of the technology and the project scope. At the same time, convey the UX team's excitement and energy to those possibilities.
Communicate visually, communicate visually, communicate visually – whether with mockups, wireframes, prototypes or by showing other websites for comparisons or just to trigger thoughts/ideas.
Don't dwell on the legacy system, but understand it well enough to understand what users think are the top detractors/barriers to productive use AND what they think are top 5 positive aspects. Keep in mind that when you do deliver the new system, regardless of current "shortcomings" the legacy system will instantly become "the best thing we ever had". So help protect the project team by understanding not to "miss what's not broken".
Don't underestimate or under-invest in the value of the end-user feedback as part of the review process. And if you are developing an application that is utilized both internally and externally be certain to capture both perspectives... walk thru "a day in the life" of both parties and then frame that in the perspective of the end user values (not what the project team values, not what project management values).
M is a director-level business process architect at a global consulting firm, who has years of experience leading the development of business requirements effort for highly complex software development projects:
During the requirement gathering and high-level design phases of a complex implementation project partnership between the Business Architecture and the UX team can greatly enhance the final product.
By using a prototype-driven approach, the business is able to grasp possible options and make better informed decisions. At the same time, the risk is that what is presented is assumed to be "set in stone" by the executive team therefore creating an expectation that cannot be maintained due to budget constraints or availability of functionalities.
The Business Architecture team can and should leverage ideas generated by the UX team and evaluate the business requirements accordingly. In multiple occasions, we found our requirements to be lacking the users' perspective. By communicating with the team and by evaluating its reaction, we were able to adjust the requirements to achieve an enhanced user experience.
Of particular help was the use of wireframes. One of the most effective interactions I have experienced with the UX team was the creation of wireframes making the requirements come to life.
The back-and-forth between the teams and the ability to see a draft of the final product while finalizing the requirements was instrumental in the achievement of a successful product. For example, one of the requirements called for the ability to indicate that one account can be indicated as "Same As" any other account on the object being developed. After reviewing the wireframe and going through the steps a user would have had to take to comply with the requirement, the Business Architecture team realized how cumbersome the interaction was and modified the requirement accordingly.
Although the use of wireframes and prototypes greatly enhances the ability to deliver a good final product from a user experience standpoint, some considerations need to be taken into account.
The UX team has generally limited knowledge of the processes being enabled; this requires the Process Architecture team to spend a considerable amount of time, at least in the beginning, transferring knowledge. This is especially daunting when the UI being designed is completely knew. In projects with limited time and budget this can cause friction between the teams and poor cooperation.
The Process Architecture team's expectations need to be managed when interacting with the UX team. In the early stages of a project, there should be a clear understanding of the rules of engagement between the two teams and the expected deliverables the UX team will produce. In my experience, teams that did not work on projects with heavy involvement from the UX team had difficulty understanding the benefits and the deliverables the UX team can provide. One of the major points of contention has been, in my experience, the demarcation between BRDs and UX specs. It has been challenging to identify which document should contain what requirements and to what extent to the point that, at times, there were conflicting directions for the functional teams to follow.
The UX team should use tools capable of producing an output that speaks not only to functional teams but to Business Architects as well. While reviewing UX specs I frequently found the documents to be very technical and not immediately understandable. This slowed down the process of creating a cohesive output and, in time-sensitive situations, has created friction between teams.
We live in a world where most of us spend a considerable amount of time each day on the Internet or using products from well known software providers such as Microsoft Office and Adobe Creative Suite. This provides all of us with access to well thought out user interfaces that have been refined over the course of several years and have been widely accepted as standard. When interacting with the UX team, Process Architects tend to apply their experience with such software packages and websites sometime overstepping their area of expertise. Interaction with the UX team, in such circumstances, has resulted less than fruitful. The Business Architecture team should clearly understand and recognize the UX team's expertise and rely on its inputs to craft a good user interface.
In my opinion, the inclusion of the UX team on complex system implementations is fundamental for being able to provide the best product. Although the interaction with the other teams involved in the development is not always easy, the benefits far outweigh the challenges.
Project managers are tasked with tracking the progress of projects and facilitating solutions that help resolve roadblocks along the way. In many projects, UX professionals do not have the benefit of a dedicated project manager, which can be a problem for medium and large projects. If a project manager is not budgeted to the project, it is a good idea to raise that as a flag and take extra effort in developing a comprehensive, mid-level plan, by yourself. If there is a project manager, make sure to review the entire project plan and flag dependencies where the UX effort has not been considered.
For example, many plans do not account for the time it takes to refactor the Axure file from 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 off the project will track later on.
Tom Hackett is a project manager with a background in web development. He has worked with UX designers as a front-end web developer and a project manager:
Q: What are your expectations from the UX team?
As a project manager my expectation from a UX team is that they are able to identify user issues, and suggest design solutions that solve customer problems. I would expect that a UX Engineer can identify issues through both interviews and observation. A UX Engineer who can create clickable mockups and walk users through a prototype helps clarify if suggested changes will have the desired effect. It's also important that the final designs incorporate functionality and workflow notes for the development teams, clarifying expected behavior that isn't implemented in the interactive prototypes. It's a huge benefit if the wireframes are written in such a way that the development team can leverage the HTML/CSS in implementation.
Q: Do interactive prototypes help clarify the UX or make things more complicated, slowing down the project?
My experience has been that UX prototyping seems on paper to increase project timelines, but in practice can reduce development cycles since users can give feedback on an interactive UX design much sooner than waiting for the first generation system. This reduces the amount of feedback necessary in the development cycle itself and allows developers to focus on functionality rather than incorporating design or layout feedback during the build phase. An interactive UX often clarifies whether implied or assumed functionality that isn't documented formally exists, both for end users and development teams.
Q: What can UX teams do, to improve the communication with business people?
UX Engineers can improve overall team communication by ensuring development teams are behind suggested solutions and feel confident in implementation. An interactive prototype that pleases the business but cannot be implemented due to performance constraints or ties to legacy system workflows, etc... can cause problems with scope management.
The Medium is the Message—Marshal McLuhan
Visual design introduces some of the most daunting challenges for rapid prototyping projects and a hidden iceberg for Axure prototypes. Why? Because of a gap, sometimes a serious one, that grows between the wireframes in the prototype and the visual design. This poses both UX and development risks because of the need to reconcile between two representations of the same screen. Eventually, 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 iterations. These wireframes address information architecture and actionable tasks, and the layouts are often tentative. With Axure, we can enhance those estimates 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. That is because people's response to colors and layouts is both extremely subjective and strong, and the concern is that such feedback tends to push to the background more substantive issues.
However, referencing McLuhan's point that the medium is the message, is the argument that it is not possible to separate visual design from user experience. This argument sounds especially compelling when it comes to the design of mobile apps. This is a case 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 duckling emerges as a beautiful swan. Now, everyone needs to start looking at the two sets of wireframes. Often, the two sets will continue to evolve on separate tracks because, while the work with the visual designer takes place, work on finalizing Axure wireframes for specifications continues. It is easier to manage the situation if it is taken into consideration early on. Resolution is still going to be an effort, but at least it will be accounted for in the project plan.
I have found that UX designers, myself included, sometimes do not completely appreciate the complexities and challenges that the visual designers on the project 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 somehow the designer will 'get it'.
Therefore, I have asked Yael Alpert and Colin Ochel, two exceptionally talented principal visual designers, to share their perspective. Here are Yael's thoughts:
Q: What are your expectations from your UX partner (team or individual) on the project?
Get informed about the client's business and UI requirements as much as possible and get the full understanding of any background research for the project done by the UX team.
Be involved the UX's process of creating personas and users' and stakeholders' interviews, when such process exists, and understand the audience for the project.
Get involved in the UX process as to why they made certain decisions in design and interaction; this can help the visual designer better make their decisions in visualizing the wires and see what limitations, if any, the specific project has.
Meet the UX designer to go through the wires; this is very important, so the visual designer can fully understand every intention of the UX in the project.
Have meetings critiquing the visual designs; it is important to have these meetings so the visuals are viewed from a UI perspective before being presented to the client.
Q: What are some challenges of integrating the visual design with a conceptual wireframe?
Keeping true to the UI while creating an engaging braded experience. Many times it is tempting to design interactions that are 'more fun or unique' but are less 'user friendly'; the challenge is to find the balance between the two.
Come up with appropriate solutions - many time the wireframes will not be obvious in what's the best solution for a certain interaction or page; the visual designer will than need to communicate the UI intention in a way that makes sense to the user. It's the visual design that the user sees in the end and these do not come with an explanation, so the visual design needs to be very clear to the user.
Be creative: a good visual designer will try and see the wire frame page in a few different ways and explore a few ways of visualizing the same thing. This is a challenging practice but a very good one especially if user testing of the UI are conduced.
Q: What should UX designers keep in mind when communicating with visual designers?
Everything happens for a reason: Have every element in the wire thought about (even if they are made just for the purpose of visual design), even elements such as color; if you color a certain item in the wires, the visual designer will see it as a meaningful thing, if there's no reason for the color / differentiation – do not use color.
Be consistent: Describe or visually represent specific elements in a similar way and keep to it throughout the wireframes. Elements such as icons representation, navigation items, buttons etc.
Be clear: The visual designer in a way is like the client to some extent; s/he needs to understand the wires as much as anyone else to achieve the best outcome; to save a lot of back and forth clarity is important.
Be open: Many times, inspired by the wires and the project in general, the visual designer might come up with a different layout and or interactions than the UI that still serve the project well. Be open to discuss updates if they make sense; visuals designers in the interactive area understand interactions and have an opinion; they are not just 'coloring' the wireframes; a good visual designer brings his or hers experience to the table that can work well together with UX.
Here are Colin's insights:
Q: What are your expectations from the UX team?
To be the voice of the client. I expect that the wire frame are the translation of the client's needs and if I have any questions or suggestions, the UEA can answer me as if they are the client.
I also expect the UEA team to be open to change. Because the UEA gathers the requirements from the client, they are led down the client's vision of the product/site/widget and it very difficult to view it from another direction. I get to see the requirements from a bird's eye view through the raw wire frames so I can view the content/flow from a non-influential eye. This allows me to make suggestions the UEA might not have considered.
Q: What are some challenges of integrating the visual design with a conceptual wireframe?
Space. Often wireframes pack in a lot of information in a small space. It looks fine when it's small text in a bounding box but not when it is in a designed layout.
Less is usually more when it comes to design. Just because something is content rich does not mean that it needs to be cluttered. Do not be afraid to brake down a page into parts that are shown only when needed. Finding a clever yet clear, intuitive way to display the content is always a challenge though. The more you hide, the more risk you run into bad usability.
Q: What should UX designers keep in mind when communicating with visual designers?
Most designers do not think like architects so it is a good test to see if your wireframes are clear. If the designer gets hung up on any part of your wireframe then you need to revise that interaction to make it more clear because if they do not get it, the end user will not get it.
One would not be blamed for thinking that developing the user experience and software development are complementary processes. However, as we often find, there is a gap between UX and development. There are many reasons for friction, but a fundamental means to resolve these is communication.
It is surprising to hear stories about large projects where the interaction designer and developers only got together well after a spanking, high-fidelity vision prototype, commissioned by the business side of the organization, had been used to drive top management to move forward with the project.
The problem, from the perspective of the development team, is that the expectation now is that the amazing application will be developed and will work just like the prototype, and will be in production in no time...as if life was so simple! Development 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 implementation of the new UX.
These concerns are often valid and true. With Axure, however, UX has a tool that helps improve communications through 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 development team.
The following are the thoughts of Mark Roeser, a senior technology executive with extensive experience and focus on large-scale data systems:
Q: What are your expectations from the UX team?
At the core of course the UX team builds out the interface design, looking for the most effective way to bridge the user's wants with the application. What I like to see most are openness and curiosity. UX needs to navigate around shifting product goals, technical constraints, a variety of user personas, and other unique challenges that have the potential to lead to an unsatisfying compromise. Having the freedom and curiosity to explore a number of possibilities is the best path toward inspired solutions.
Q: What are some challenges in reviewing UX?
Removing ourselves and our assumptions when reviewing UX, and imagining new contexts and situations in which to review a design. Also, focusing on the right elements at the right stage of the project: don't review or discuss art when things should still be handled at the wireframe stage.
Q: Do interactive prototypes help clarify the UX or make things more complicated, slowing down the project?
Prototypes should be carefully considered with specific goals in mind and not always be included. Prototypes that are easy to produce but too simplistic can lead to false validations. For example, a hardcoded workflow reviewed with an end user can seem easy and clear to understand, whereas a final working product might reveal excessive clicks, repetitive tasks, etc. when they use it for real w/out the idealized storyline.
Q: What can UX teams do, to improve the communication with business people?
As much as possible, share share the methods and teach the language of UX. Give them a language to effectively communicate their ideas and concerns, and draw them into the process. Be a guide and partner with them to discover solutions together, rather than asserting authority or attempting to dazzle with cleverness.
I'm also very much interested in finding ways to improve how UX works in an iterative development process, particularly in the context of the "minimal shippable functionality" aspect of agile/scrum. Here the goal is to learn early from a simple product in the field, rather than concentrating all UX work at the start. For this to be effective, the UX team needs to work closely with the development team to plan meaningful iterations and build in the feedback/measurements necessary to drive the process forward. Easier said than done!
User interface/experience practitioners come in many flavors. There is no standard certification or professional accreditation that can help a client determine who is a truley qualified UX resource. While you will not take on an uncertified architect to design a skyscraper or your home, the evolution of user experience as a discipline matches other segments in software design, where a degree is not the only measure of expertise and skill.
However, there is also an aspect that relates to the technical skills we bring to the table. For someone who is only versed and comfortable with wireframing in Visio, developing an interactive prototype in Visio, will be a challenge.
Of course, it is a lot easier to create such a prototype in Axure. However, should you embrace this tool? It is best to avoid heated tool-camp loyalty arguments, as the answer typically boils down to a strategic business and professional decision:
Are you a single user? Perhaps an independent consultant, or the single UX practitioner in an organization? In this case, you need to consider the cost of investing in the tool, and the return on your investment.
Think about the projects you have created so far with the tool(s) you have. Is there a gap that you need to fill?
Axure is becoming a good skill to master. Will learning the tool open up new opportunities?
What about the cloud-based services for which you pay a subscription? Certainly, it is a good idea to review the option. However, the thing to consider here is that many corporations may frown upon having their strategic plans placed on some cloud. Moreover, firewalls and other security barriers may make it difficult for stakeholders to access the work.
Are you a member of an interface design agency, or in an in-house design team?
What are the challenges of running a shared Axure project?
What kind of training is needed to level the team's prototyping skills?
What are the project opportunities that open up with using shared project and the efficiencies, savings, and increased profits in terms of re-use of widget libraries, masters and generators?
I have asked a few colleagues to share their honest perspectives on the use of Axure. I think you might find Katrina's and Saikat's account very relevant to your experience. Here are Katrina Benco's thoughts:
I used Visio for a long time before using Axure. The thought of switching tools was a daunting, but enticing proposition. I started using Axure with an open mind and haven't looked back. It has a small learning curve and is continually proving itself as a clever and useful tool.
One way Axure has supported my design process is its flexibility for documenting highly complex or configurable systems with a rich, interactive UI and layers of business rules. The mechanisms to prototype also allow me to document and annotate the different states of the wireframes in an object-oriented manner. I can use dynamic panels and masters to show different states in the UI not only based on interaction, but also business rules, roles, configurations, etc.
My primary use of Axure has been to design and specify wireframes and generate printed wireframe specification documents for the developers, not to do prototyping. However, Axure's prototyping features have reshaped my design process in two ways:
I can quickly prototype an interaction and test it out myself. There is nothing like trying on your own design for size. I prototype my design concepts to pitch them to the business and tech folks. Seeing concepts in action is a powerful way to show design concepts and gain buy-in, or to sell one design over another.
My suggestions for successful adoption by a large UX team are to:
First, have best practices for using the tool in place to ensure everyone documents their wireframes in the same way. Second, take advantage of the masters to globally spec as much of your UI as you can and to share design patterns.
And here are Saikat Mandal's thoughts:
Axure is an amazing prototyping tool. It can be all-inclusive tool for a UX designer. It helps you ideate; create bubble diagrams, flow diagrams, sketchy-low fidelity prototypes. Where it is hugely helpful is its capability to make high fidelity prototypes, which can mimic the actual system at quarter of its cost and time. This is not just a tool for the designers but also for the whole team, which includes Project Managers, Business Analysts, developers and even the Quality Analysts. Rapid visualization gets all these team going. They now don't have to wait for the other team to pass the ball.
The beauty of all complex things is its simple structure (I am reminded of Clarke's Law: Any sufficiently advanced technology is indistinguishable from magic.) Your work just gets done like magic and you don't even have to think of the mechanism behind it. (Disclaimer: Sometime this can set wrong expectations at workplace ). The Layout is similar to a website. A simple structure which tells you that there is a website with simple three pages. A common man can make a website and have a web presence. It does not need any prior knowledge of website building. Simple knowledge of hyper linking will get a person going. You can then make it more complex based on your need.
There are some challenges to Axure's adoption. Most of the design fraternity has grown up using Adobe suit and Dreamweaver as prototyping tool. Thus adapting to a new product that does things differently can be a challenge in the beginning. The other disadvantage is that Axure does not have the capability of layers . Layers in Axure can add whole new meaning. This will make it closer to Photoshop and can have the versatility of Auto Cad.
However, there are ways to customize the dynamic panels to behave as layers. So an advanced user, familiar with layers can modify dynamic panels and get it to perform the functions of layers.
'Nomenclature' is another problem. Naming widgets and panels correctly and reusing them as masters is the crux of Axure. Unique Ids can be separated from a class of object by naming objects properly. A new user without guidance will not get to know the pattern and thus there needs to be some scaffolding to help them. The good news is that a user has complete ability to customize the system. Thus giving tremendous power to the user.
Overall one tool doing so much is in itself a marvel. It has its shortcomings but the team behind it is doing a tremendous job of mitigating the problems. Axure is a powerful tool, which can make wonders when used correctly.
I asked Alfred Kahn to share with us his insights, based on his experiences with the previous version of Axure, while leading a large UX team on a complex project:
Create a new, consistent, unified design for the J.P. Morgan Treasury Services portal, using a large team spread across three locations.
My team consisted of 12 designers divided into four workstreams, each responsible for a different part of the design: Portal, Payments, Information Management and Standards. Each workstream had a lead responsible for overseeing the design work and ensuring that the workstream's designs complied with the standards that were developed over the course of the project. The Standards team was responsible for maintaining the User Experience standards and reviewing each team's designs for compliance.
Based on prior experiences working with standards that were developed in the abstract, I established an iterative process that would enable us to evolve standards organically. Our standards were derived from solving real-world design problems specific to the context and the domain in which we were working. Each workstream had an ownership of the wireframes for the screen designs in its area of the portal and published its own specifications. The specifications were consumed by the product and tech teams (BSAs, architects, and developers) for that area, but starting with the initial designs, we identified common functionality and created a set of standard patterns that were then used in all wireframes.
Each of the three specifications included a "Globals" section, maintained by the Portal and Standards workstreams, containing specifications for widgets used for common functionality. As a result of this approach, the Client Experience team became the central point for maintaining consistency across the entire portal project in terms of both design and requirements.
Axure was the easy choice as the primary design tool, to a large extent based on its shared project, masters, and UI specification generation features. Had we used any other tool, the project would likely have required at least 2-3 additional designers to just support distribution and integration of common design elements.
After the design of the first release was done, we explored ways to integrate the functional specification content into Axure, in order to provide a single point of reference for the developers building the application. We piloted and then rolled out a process whereby the Business Systems Analysts (BSAs) would enter their content into the shared Axure file in a separate set of annotations through a customized view. The BSA annotations were published in the UI specification in a separate table following the annotations entered by the Client Experience designers.
This approach was limited to those parts of the functional specification that related to the UI, but provided a single point of reference for the developers building the user interface. It had the added benefit of lowering the overhead around maintaining consistency between the functional specification and the UI specification; prior to establishing this process, the Client Experience and the BSA teams spent a significant amount of time reviewing each other's documentation to make sure that they were in alignment and that there were no conflicts.
The shared project feature enabled the team to use the same set of masters, which meant that we could centrally update designs common to all workstreams. The custom widget library provided designers with an easy option to use widgets that complied with the standards. We regularly re-factored the custom widget library to reflect modifications made to the user experience and the visual design standards, so that they always had an up-to-date version available to them. Other Axure features that helped streamline the design process were:
Access to wireframes across workstreams: As every designer had access to every wireframe, they could easily refer to another team's design to prevent duplication of functionality and drive consistency across the application.
Wireframe categorization and navigation: We used the tree in Axure's left navigation to categorize our many wireframes. Each team had a node, and as we had established a numbering and naming convention for wireframes, masters and dynamic panel states, it was easy for us to find each other's wireframes.
Page Notes: These enabled us to provide a categorized overview of each screen, and the sections we established within Page Notes served as a template to prompt designers to enter critical information.
Integrated specification generation: It drastically reduced the overhead related to maintaining the UI specification, especially as we ended up with multiple versions of each specification related to point releases. Had we been forced to use a separate tool for managing and generating the UI specifications, it would have doubled the level of effort for the project, at the very least.
Restore feature: On a number of occasions, Axure's restore feature saved us many days of rebuilding screens. Coupled with the fact that the subversion instance was backed up centrally, we were able to reduce our file management overhead as well.
The single biggest downside to using Axure (Version 5.6 and earlier) on a project of this size is that the project file got extremely large, creating significant latency in checking files in and out. It was not unusual for it to take up to 5 minutes to check a screen in or out. This was a source of frustration for the team and became a drag on productivity.
An easy way to mitigate the check in/out latency would have been to break the file up into separate projects for each workstream. Unfortunately, Axure does not have an "include" feature; there was no way to store, maintain, and share common elements outside of the main project file. For this reason, we maintained a single project file and lived with the frustration.
While we loved the custom widgets library feature, it didn't update when the library modified; each time we updated the library, it had to be published and imported manually. It would have been much better to be able to push custom widget library updates out to all designers automatically, through the project file.
The functionality associated with the Specification Generator not as robust as other features, however, Axure was very responsive to our feedback. We sent the company a list of new features and upgrades that we thought would significantly improve the utility of Axure for us. When we met to review the list, we indicated that the Specification Generator feature upgrades were of the highest priority for us (Axure 6 addresses many of those requests).
Despite all of these issues, Axure was a huge boon to the project. Given the scale of the effort, if we had not selected Axure as our design tool, each workstream would have required an additional designer just to manage the distribution and integration of the common design elements, significantly adding to the overhead of the project. After leading a team through the design of four releases using Axure as our design tool, I think we made the right choice, and would do so again without hesitation.
Axure can promote, but not enforce, consistent design; ensuring a consistent design still requires a governance process
It is critical to construct wireframes properly and consistently across all teams
Create a naming convention for wireframes and dynamic panels; validate proper naming during governance reviews
Agree on a common structure/organization of wireframes and enforce that organization across all teams
Allow time to train new users in the finer points of using Axure
At the beginning of the project, pilot a number of ways of using masters and dynamic panels, and then settle on a common approach; validate the implementation during governance reviews
Be sure to bake time into your project plan for maintenance of the Axure file:
Refactor the project file at strategic points in time—between completion of wireframes and writing the spec, and after the completion of a release
Plan to have one wireframe structure for prototypes and another for specifications
The world is getting smaller, and I think that UX plays a small role in getting people from all over the world closer, by propagating good user-centered design patterns. I am curious about the practice of UX, and the use of Axure, as a design tool around the world. I have posted the question to the AxureWorld group on LinkedIn (see here: http://lnkd.in/52g3h8). You can read the responses from practitioners in Brazil, the Netherlands, India, Israel, the UK, and many other countries...and please add your comments as well!
As a more in-depth response, I have asked Richard Tsai, Chief Information Architect at UserXper Digital Consulting Co., to share with us the perspective on Axure's use in China and Taiwan, and this is what he has to say:
My first experience with Axure RP happened in 2006. This all started from a colleague who observed that lots of prototyping tools, which I had never heard before, were introduced by the Western UX bloggers. After downloading and using Axure RP v4.0, I immediately realized that this is exactly what I want. It is highly valuable in managing large-scale website projects.
In 2007, I left from my ex-company and setup UserXper Digital Consulting Corporation. Our major business is focusing on providing the service of information architect and website planning, including prototyping. At the same time, UseXper became the Sales & Training Partner with Axure Company and stared to promote Axure RP in the Greater China Area.
The obvious advantages of Axure RP itself and word-of-mouth advertising by users took effect better than our promote activities; therefore, many famous and top-class enterprises such as Internet company (Yahoo! Taiwan, Alibaba, Baidu,...), software companies (Trend Micro,..) , even hardware companies have used the Axure RP and taken it as the first choice of UI prototype tool.
How the users in Great China area apply the Axure RP to their job? There are three different usages from beginners to fabulous users.
First are beginners using Axure RP, nonracially identity as freelancers or small teams. They would simply use basic function such as wireframing and lo-fi prototype to concretize their ideas. These users may not employ themselves in Axure RP's complicated interactive design; however, they still make a good thing of communicating accurately to reach the requirements.
Secondly, advanced experienced design team design the ui & interaction via Axure RP which tends to mockup the system flow to verify the interface usability as soon as possible.
Last one would be fabulous team. These people would process the "Design Management plan" by using Axure RP. For instance, team members can coordinate UI design pattern through the Widget Libraries function. More important thing is to create excellent user experience by using the linked-up company standard with design guideline.
Except dot-coms, there are more and more MIS departments of traditional industries and hardware manufacturers start to using Axure RP to design the interface of Mobile App or Tablet PC UI.
Furthermore, there are some interesting and creative examples about using Axure RP. For example, a IT team in Beijing use Axure RP to control SA(System Analysis) and Specification approval. Another example is a company in Taipei generates the system operation handbook by Spec generation function. Moreover, one of my colleagues loves Axure RP so much that he uses Axure RP for making training contact to replace traditional PowerPoint.
More and more industries pay attention to User experience in Great China area. Famous UX events in Taipei such as HPX party & UiGathering used to taking Axure RP prototyping as the main lecture. There was about 700-800 persons attending the User Friendly Conference, the biggest user-experienced conference and held in SuZhou, China. One of workshops in User Friendly 2011 was Axure RP Prototyping this year.
As this is a book on prototyping with Axure, it made a lot of sense to approach the company about the vision for the future. There are several considerable challenges that the company has to deal with:
The more Axure can do (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, however, freeing ourselves from the dependency on developers, and the ability to quickly and easily create interactive prototypes, is exactly the goal Axure set out to achieve, being a tool for non-developers. So, here's how the company can balance these two extremes:
Prototype versus specifications: The demand for high-fidelity vision prototypes is on the rise and is becoming a norm. The turnaround on such prototypes is fast, 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. The refactoring effort can be substantial, and yet—often not planned for—budget or schedule wise. Clearly, there are some challenges around reducing the gap between the prototype construction and specification generation. How would Axure try to address this in the future?
The rapidly changing landscape of UX: Apple, for example, with its iPhones and iPads and its integration of the mobile operating system iOS with the desktop operating system OS-X, has changed the user experience in profound ways. As a result, the syntax of interaction patterns is evolving. New multi-finger gestures are a good example. How will Axure support the creation of prototypes for the next generation of devices?
I have asked Victor Hsu, who, together with Martin Smith, started Axure back in 2002, to share some of his thoughts:
When we started Axure, we set out to build a tool that would reduce project costs and timelines by introducing interactive prototyping into the process. Axure RP 1.0 was built, and it was a flop. It was difficult to use and had a lot of features that overlapped with existing tools that did a better job. Looking back, it just wasn't a tool many people would want to spend their day using. Luckily, the user experience profession was about to take off. And we discovered a new approach to designing Axure RP.
Instead of thinking about the project, we started focusing on you, the people actually using Axure RP. We prioritized features that made it faster and easier to use and gave you the prototyping capabilities other tools did not. We trusted you to take advantage of those capabilities to reach better designs and to communicate with your teams. It worked. You delivered cost savings to the projects and helped build better software. Axure RP is now the standard for software prototyping tools.
Time and time again, we've seen your successes lead to recognition, and recognition lead to more responsibility. This is a great thing. The Axure RP roadmap is evidence of the increasing demands on UX professionals and your increasing influence. Turnaround times need to be faster. The prototypes are getting richer as user testing becomes more prevalent. They need to be presented on the target devices like iPhones and iPads. And your prototypes are replacing requirements lists and documents as the reference for visual design, copywriting, development and testing.
We will continue to help you take advantage of these opportunities and at the same time make Axure RP more enjoyable for you to learn and use. You will find excellent resources from prototyping and Axure RP experts like Ezra to help you along the way. And all we ask of you is to produce great work and accept the credit and influence you've earned.
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 development stakeholders, user research, business requirements, and various constraints. At the end of the day, our goal is to find the pragmatic balance, opportunities, and innovation for the best user experience possible. In order to visualize and document our vision, a specialized UX tool is invaluable, and in recent years, Axure has become the tool of choice for many UX designers who feel it has the right balance of features, complexity, and cost, and is the right tool to demonstrate their vision.
The coming 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 the various perspectives of the stakeholders and partners you are collaborating with. At the end of the day, Axure is just a tool, and it is through true collaboration that we can develop a successful and hopefully innovative prototype.