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.