Domain Agnostic Naming Convention for Axure Based UX Projects [part 1]

Introduction

The following naming convention scheme is domain agnostic or in other words - appropriate for any type of software UX being modeled. Aspects of the convention are specific to Axure but I think they could be easily modified to fit other UX prototyping tools.


This convention is offered for review, discussion and adoption by others in the UX community in the belief that there is no need to reinvent the wheel for each new project and that we could all benefit from some standardization. Comments and suggestions are most welcome.

Benefits:

1. Identify each element of the wireframe with a unique identifier and help:
1. The UX team: troubleshoot interactions and quality of wireframe construction: It is inherent in the process of naming things that one needs to consider aspects of structure: hierarchy, placement and efficiencies which consequently yields well-formed wireframes.
2. Developers, BAs and other stakeholders who consume the Word specification document or the CSV output.
2. Quickly determine when reading the Word spec or CSV output if we are looking at a page, master, dynamic-panel or state - just by the ID.
3. Consistency, which is critical for large shared project with multiple designers working on a shared project file. Eliminating 'Tower of Babel' syndrome where each UX labels items
4. Avoid the "Unlabeled" plague that makes it extremely hard to create advanced interactions, or to make sense out of the specification document
5. Internationalize - Greatly improve the process of localization. Instead of relying on a label which may not be unique, ids makes it easy for teams across the globe to make references to any item of the UI with confidence.
6. Productive - When used from the project get-go, save the UX team significant amount of time in downstream consistency enforcement and tons of reworking.
7. Transferable - Use on any type of UX project.

Throughout this post I will use a simplified UX project example to contextualize and clarify some of the concepts. The project example: An electronic Medical records application (EMR) that is being developed by a team of UX experts and is divided into 4 workstreams:

• UI Framework (all shared UX widgets, patterns etc.)
• Medical Staff Portal (doctors, nurses, etc.)
• Patients Portal (Charts, lab results, prescriptions, etc.)
• Pharmacy Portal (Prescription Tacking, etc.)

The Namespace

1. Workstream Prefix

We'll start by assigning each workstream a 2-letter code prefix:

• UI Framework = FW
• Medical Staff Portal = MD
• Patients Portal = PP
• Pharmacy Portal = RX

The process of coming up with the 2-letter prefix should be straight forward, although it is

important to keep in mind:

• Domain nomenclature (Pharmacy could be PR, but RX makes more sense)
• Avoiding confusion in the future (Patient portal could be PT, for example, but may be confused with a sub section under MD for Physical Therapy (widely known as PT)
• Naming conventions of other partners in the project that may have started their work before the UX team. Often, the business process team is in place early on. The goal is to gain alignment and reuse confusion.

Why 2 and not 3 letters? To make the overall id as short as possible. As you will see later, the id can become quite long.

2. Workstream Number Range

Each workstream is assigned a numerical range that will be used for issuing unique ID's for pages and masters. Just by looking at the wireframe or widget number it becomes easy to associate the object to the workstream. Note that framework wireframes are assigned the highest range of 900, mostly to strengthen the visual of framework elements - they play an important role as global elements across the whole Ui.

• FW = 900 to 999
• MD = 100 to 199
• PP = 200 to 299
• RX = 300 to 399

Once the prefix is in place, the Sitemap panel should have the following top-level pages that will help each UX workstream organize their pages under the shared sitemap. Axure's sitemap panel (Version 5.6) does not support folders as the masters panel.


Continue to create the corresponding nodes on the Maters panel - Here we can take advantage of folders to structure the wireframes without creating extraneous pages. Note that we add "M-" to all masters to help distinguish between masters and pages.


3: Pages

Pages are wireframes of entire screens and are typically constructed of widgets, masters and dynamic panels. In the context of Axure's html output, pages are the only wireframes directly accessible via the left-nav sitemap.
Names should be meaningful and self-explanatory to provide maximal clarity to all stakeholders. Keep in mind that you need to communicate with others, so avoid shortcuts,  ambiguous names. From our example:
The RX team has a wireframe page with a list of drugs and a detail page of each drug, which is presented when the user clicks a row in the list.


The 2 pages should be named:

• RX-301 Drug List
• RX-302 Drug Detail

Regular briefing of UX team members who work with workstreams about changes to the sitemap. The clarity communicated by the name also helps members of the UX team, for example - when on-boarding new team members who must be able to digest a lot of new material quickly. Use proper capitalization and space words to maximize readability. Remember - the goal is effective communication.


4. Masters

4.1 Workstream Masters
These are masters of limited use - only on pages related to a particular workstream. For example, the MD workstream has several pages related to Board certification of doctors and nurses. These are relevant only to the MD portal, and the ID of masters used there will communicate this fact:

4.2 Framework masters

These are typically global navigation, header and footer elements - masters that are consumed by all pages in the framework template. 
For example: M-FW-900.1 etc. Note that the 3-digit prefix for masters does not advance. Rather, it is an indicator of the workstream and not associated with a particular page of the workstream because masters can be used on multiple pages. M-MD-100.1, for the first master for the MD workstream, etc.

5. Dynamic Panels

Dynamic panels will inherit the prefix of the page or master they were placed on. For example: RX-232_1 DP Name, which references the first dynamic panel on page 232, which is part of the RX workstream.

6. States

States inherit the prefix of the dynamic panel they are part of: RX-232_1.1 State Name.

Note that the IDs of masters and dynamic panels are very likely to change: Masters may often start with one of the workstream, but might later be used across other parts of the UI, and become part of the UI Framework. Dynamic panels may initially e used on a single page, but then converted to a master. It is important to rename those ids ASAP to reduce confusion.
Unfortunately, Axure does not allow page notes for dynamic panels and their states. AAs a result, the ability to reference with accuracy any element of a dynamic panel is important, and can be done on the master level, which can be cumbersome, but allows documenting those elements.

7. Nesting

Nested masters and dynamic panels are unavoidable and we can easily extend the naming convention to account for nesting: RX-232_2.4_1.3 State Name - we are looking at the wireframe associated with the 3rd state of the 1st dynamic panel that 'lives' in the 4th state of the 2nd dynamic panel that 'lives' on page RX-232. The naming convention thus communicates the construction structure of the wireframe in addition to providing a unique reference and ownership association by workstream.

8. Widgets

Widgets are associated with the page, master or dynamic panel they live on.

Axure Built-In Widgets

For the built-in widget in Axure use the abbreviations listed here, or create your own.

Image= IMG

Text Panel= TPNL

Hyperlink= LNK

Button= BTN

Table*= TBL

Text Field= FLD        

Text Area= TXTA

Droplist= DL

List Box= LBX

Checkbox= CBX

Radio Button*= RBTN

Horizontal Line= HR

Vertical Line= VR

Image Map= IMP

Inline Frame= IFRM

Menu Vertical= MNV

Menu Horiz= MNH

Tree= TRE

Widgets inherits their parents 's ID and look like this:
M-PT-305-BTN.1 Button Name, or more complex....
M-RX-211_1.3_1.1-DL..2 Quantity

Keep in mind that if you named widgets on a dynamic panel that later became part of a master, renaming will be required. While tedious, it will pay of f when generating a specifications  document that enables clear communication between developer, UX and all other stakeholders involved in consuming the documentation.

----------
To be continued in part 2.

------

Portions of this convention were developed in collaboration with my colleagues and friends Elizabeth Srail and Katrina Benco.

Evaluating Axure RP - Talking Points

I'm often asked by colleagues and clients about my experience with rapid UX prototyping tools in general, and Axure specifically. I always preface by saying that I’ve been using Axure as a primary wireframing tool for the past 3+ years, and, although I occasionally evaluate new prototyping tools, such as ProtoShare or Sketchflow , I don’t have the hard-core experience that comes from daily work with a tool.

The landscape of rapid prototyping is changing rapidly, with frequent announcement of new players, some that look very promising. These are very exciting times for our profession because finally, user experience architects and designers can master a specialized UX tool instead of tools borrowed from desktop publishing or app developers.

So one must be open minded to change and to take advantage of whatever does the job. Yet any tool is a strategic investment - of our time, our ability to successfully execute and deliver demanding challenges. In other words - the stuff needs to really work when a large team of UX designers, spread all over the country needs to collaborate under tight schedules. Making things change colors on mouse over is not enough.

So here is a deck I created recently and used in several occasions to help guide an evaluation process. It is of course in favor of Axure, and not because the product is perfect or because the company pays me to promote the product (They don't!). It is their uniquely amazing customer support that won me over.

Download the PDF.


Comments are most welcome. 

Inital thoughts on Agile with Axure

Part 1: 

The Settings (Or, making software is like making sausage - you don't really want to know how it is made, but you should)

Immediately one faces the fact that there are way more flavors of Agile than Baskin Robbins ice cream...So perhaps we should begin with the key drivers that lead to typical UX projects. Typically it is the business side of the organization that drives the change, with IT group either resisting change, locked into a technology flavor mindset (.Net, Java, etc.) and in many cases the communications between the two part of the organizations are poor.There are many exceptions, but I want to address realities of large scale projects. In established organizations, despite the desire to use Agile, there are still hard wired protocols and bureaucracy around traceability, change management and sign-offs.

Axure, like the typical UX team, sits in the intersection of messy cultures and is being used as a communication tool to articulate, 'sell' and specify both vision and reality - this is where some of the key risks and opportunities are for us as UX practitioners. By that I mean that the initial Axure prototype is probably very aggressive about rich interactions, features and functionality.  The business end gets excited because customers who are exposed to the new vision are pressuring for improvements. The sales department is always hungry for a better product to sell.

Thus, strategic plans and budgets are set around unrealistic delivery targets and often, with very little awareness of the full UX development process. In fact, the UX team is often engaged after the project plan, budget and delivery dates were set (What?! we need to pay for usability tests?!). Moreover, large projects are often broken into phases, which means you can not expect a clean process of creating a prototype, finalizing it and go to the beach, because work on following phases often begins before coding of the previous phases ended - which means that everything is in flux, and the Axure file should be well formed to handle change. 

So who are the players, and consumers of Axure output now the the project is in flight?

• The UX team (or perhaps you are a single practitioner) - The organizational association of the team is critical - is the team part of the business unit, or part of the IT organization. I've seen both, and, I've seen the team floating with no clear association, which can be worse.

• The business owners - and depending on the organization, they may be spread all over the US or worldwide, often with conflicting motives and requirements. - The UX team must make sure that UX requirements are captured in a very formal way - Axure can be used for that, but there are some issues around managing the requirements in Axure. While Axure is not a requirement gathering tool it makes so much more sense to capture UX requirements in it that we may get tempted, and have to live with the consequences later on. Not a big deal if we planned for it, a mess if we did not.

• The IT team - In large organization this may be a Hidra, with sub units that are in charge of some aspect of the technology, they may not like each other, or for that matter, even communicate much on a regular basis. And off shore teams are the norm these days, so we have to keep in mind that the output of our Axure project may be consumed by people for whom English in not a native language.

• The BAs - In some organizations each group might have their team of BAs - so the documents that are produced include business requirements and specifications, technical requirements and specifications, etc. The UX team typically adds UX requirements and specifications -- All mentioned are often extremely long documents that none really reads because everyone is busy trying to beat the unrealistic deadlines mentioned above. So an opportunity that Axure affords, is generating specifications that are easy to consume, which s is not so trivial, and I'm looking forward for the upcoming resale for some enhancements. Agile does not mean that specs and requirements are not needed - in fact the issue becomes worse - how to track and mange changes from scrums and sprints such that developers and business partners don't get lost in the sea of documentation?

• The QA team - this team (if it exists beyond being a place holder) has the worst job - testing scripts are often rendered useless because changes happen all the time - so they need to be able to follow up the rapid changes, and update the testing library in time for testing.

This post was originally posted on the Axure Discussion board.

Comparing Apples to Oranges - The NYT Bestsellers Lists and Kindle

The June 7th issue of the New York Times Book Review, print edition, had the following Amazon ad on page 21: An arrow pointing at the bestsellers list and the text:
"in the time it takes to skim the bestseller list, you can wirelessly download an entire book." A couple of inches Below that text was an image of the Kindle accompanied by the text:
"Choose from 275,000 of the most popular books, magazines and newspapers. Free wireless delivery in less than 60 seconds."

In the print edition of the Times the bestsellers list is spread across 3 pages:

Page	Bestseller Category	List Category	# of Books
18	Best Sellers	Fiction	15
18	Best Sellers	Nonfiction	15
20	Paperback Best Sellers	Trade Fiction	20
20	Paperback Best Sellers	Mass Market Fiction	20
21	Paperback Best Sellers	Nonfiction	20
21	Advice, How-To and Miscellaneous	Hardcover	10
21	Advice, How-To and Miscellaneous	Paperback	10

# Pages	# Bestseller Category	# List Category	# of Books
3	3	6	110

---

The Amazon ad suggests that the act of downloading a single book is equivalent to the act of browsing a list of books  (perhaps to determine which book to purchase). But it is really a comparison between (a) A pre-decision activity of browsing the list of books, and (b) A post-decision activity, since the download is done after one chose, purchased and clicked the 'Download' button - it is the device that does the work.

Let's consider Amazon value preposition which is divided into 2 phases:

1. Choose from 275,000 of the most popular 
1. Books
2. Magazines
3. Newspapers
2. Free wireless delivery in less than 60 seconds.

In phase 1, the ad touts a clear quantitative advantage for Amazon: A choice of 275,000 bestseller books compared to the meager 110 books of the NYT. In fact, the ad is positioned on page 21 which only lists 20 books, compared to page 20 which lists 40 books and page 18 which lists 30 books - the quantitive advantage is visually enhanced.

But as Barry Schwartz (not a relative) suggests in his book 'The Paradox of Choice', 'More is Less'.

In the print edition, one only has to choose between books. Indeed, making the choice even in this short list is confusing. What's odd about the NYT bestsellers list is its classification confusion in both the Bestseller category and the list category: Format (paperback, hardcover) is intermixed with genre (advise, fiction, nonfiction), and sales channel (mass market, trade).

This list is clearly not organized with the user (the reader) in mind. It is hard to imagine a reader pondering which a mass market fiction book to get for her Summer holiday. But at least the choice is among books. The Amazon ad offers, in addition to the large quantity of books, also a range of publication types - books and magazines and newspapers -- clearly a scope beyond that of the print list, but also a completely different type of choice and context of choice.

Finally, the interface of the NYT list in print requires the reader to read. Each item includes:

• Title 
• Author, 
• Publisher, 
• List price and 
• A short blurb. 

There may be a bias to select the top ranking books thinking that they are also the best books, but because the lists are short and easy to read, it is not an effort to cover all.

Now, the user interface for browsing the same NYT bestsellers list on Amazon's Kindle section does not require one to read. Rather, one may be compelled to make the choice by the covers, ignoring the wise proverb 'Don't judge a book by its cover'.

Here, each item includes:

• Cover photo (title and author quite visible)
• Title
• List price
• Kindle price

and here is the interface of all the bestseller books (54) in fiction category:

So, how many books could you download by the time you finish browsing the NYT bestsellers list on the Kindle website?

What We Learn From Animators About Prototyping

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

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

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

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

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

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

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

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

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

Choosing a Prototyping Tool

It seems that only yesterday the mainstream prototyping option favored by user experience practitioners was Visio. Also common were heated arguments on the greatness of paper, Power Point and other low fidelity tools and techniques as the main prototyping instruments. I recall a 2007 uphill battle with colleagues around use of Axure for a large RIA project, where I was met with skepticism and concerns about the validity of the approach. They favored Visio.

Fast forward to 2009 and there seems to be an influx of new tools and with them, potential possibilities to express ourselves to our colleagues, business and development partners. This trend signals that finally the practice of user experience has matured and is large enough to attract software developers. This trend happened with word processors, desktop publishing, illustration, video editing, browsers, web authoring and many others. Eventually the market settles on a couple of applications that become the de-facto tools of the trade, at least until a game-changer enters the field. From this perspective, Axure is a game changer, emerging when pressures on UX to simulate rich interaction rendered tools like Visio useless.
A few points to consider:

• What is our interest as a professional community? I would argue that as information architecture and interaction design are getting more complex yet deadlines continue to shrink, we want our prototyping tools to be powerful yet easier to use: We need demonstrate our value in expressing complex applications correctly - and fast. The tools needs to handle the various facets of our work products: As we know, there is a lot more to user experience design than just mocking up screens and simulating rich interaction. Our deliverables include extensive documentation that is consumed by a range of stakeholders.
  
  
• Features and complexity. I would argue that the successful tool must be feature-rich and fit the granularity of prototyping throughout the design process. By that I mean that we typically start with high-level concepts - fast wireframes and flows. Gradually and with feedback from research and stakeholders, more depth and details are added to the prototype, including interactions and detailed annotations. While we want to simulate rich interactions, I think that it is desirable to avoid becoming programmers, or at least, minimize the need to relay on a scripting language such as ActionScript or JavaScript. A concern is that the more effort is spent on making the prototype interactive, the less flexible the design becomes because we are getting involved in development instead of design. It is possible to create fairly complex prototypes with Axure without ever using raised events and variables, but these features are available to power users. Few of the new tools offer this flexibility. Finally, beyond dragging and dropping some UI widgets on a canvas and simulate RIA interaction, it is the proven ability to fuse team work, richness of interaction specifications, reuse of visual and interaction patterns (to name some key capabilities) that sets a tool like Axure from the new crop of tools.
  
  
• Proficiency and professional benefits. This is especially relevant to situations where a team of interaction designers is assembled and is required to conceptualize, test and document (fast...) a large, complex application. It makes a great difference if all team members can - in addition to quickly get up to speed on the prototyping tool - master it and maximize its potential. For example, Axure seems to be gaining awareness in the UX community so it is easier to find UX professionals who are familiar with it and can 'hit the ground running' . Another important aspect is that practitioners want leverage expertise gained in one project when moving to another employer or project. If one uses tool A in one project, tool b in another and tool c in the next, there is little benefit in terms of best practice and expertise from a professional perspective.
  
  
• Shared projects, regardless of the prototyping tool, are not trivial and best practice is still evolving as knowledge around this new, emerging capability is spreading within the community. Developers of prototyping tools that do not support sharing miss on the experiences gained from having to deal with the challenges of collaborative work, especially issues that relate to management of assets, management of multiple releases, etc. Keep in mind that implementing solutions into the tool take time and feedback form practitioners - see the list of desired functionality for Axure to get an idea of how much more we want...
  
  
• Cost. As others and myself noted elsewhere in this forum, cost plays a major role for the acceptance and adaptation of any tool. As we know, cost is not just the price of the application, but also the time invested in getting to proficiency, dealing with work-arounds if the tool lacks the features needed, or if it is buggy. There is also an interesting phenomenon with price: If the tool is too inexpensive it tend to be dismissed by IT organizations. From this perspective Axure's price point makes it affordable to single practitioner and also makes it a palatable purchase for large teams.
  
  
• Community and Customer support. Last but not least - The prototyping application and files become critical to our ability to deliver on time. As I wrote elsewhere, the confidence that Axure will respond to an urgent crisis is a major, major point of differentiation for me. I know that postings on this board or direct mail to Support will be addressed. I also learn all the time from reading the tips and techniques that other practitioners post regularly. In fairness to the developers of the new tools, they will have an opportunity to prove their commitment to the their customer base. Ultimately, the success of one tool over another can be often attributed to the strength of the community formed around it.

To be continued here.

This post was originally written as a response to another post in a thread on Axure's discussion board.
---------------------------------
Disclaimer: I am not an employee of Axure nor am I compensated by the company in any way, shape or form. Rather, I have a vested interest in its continued development as an avid user of the application on a daily-basis. (Disclaimer text by Dingle)

High Fidelity and Low Fiedelity Prototyping

Magritte's painting "Ceci n'est pas une pipe" ("This is not a pipe") continues to be the source of delicious musings on art and semiotics almost a century after Magritte created the series of paintings called The Treachery of Images .

The point here is that the prototype is not the application, and keeping this in mind can guide the user interaction team in developing a prototype that is rich and effective, yet not so involved as to introduce complexities to the project.

We are witnessing a dramatic change in the landscape of prototyping tools available to practitioners, and with the tools, business acceptance of and demand for increased visualization of the proof of concepts before development begins.

Ideally, the prototyping process should be continuous and evolutionary, meaning that it is possible to increment the prototype file increasingly adding depth and specifications. So it is a matter of developing a prototyping process that is effective and appropriate to the point of project. Typically, low fidelity works well at the very early days of the design process:

• Sketches on paper, cards, post-its, etc.
  
• Sketches in Powerpoint, Visio, Illustratior, etc.

The purpose of these quick sketches is mostly to provide the designer with an initial handle of the concept, quickly experiment with approaches.

To be continued here.

* As a side note, a search for 'this is not a pipe' yields a result set that demonstrates some of the issues Walter Benjamin brought up in 'The Work of Art in the Age of Its Technological Reproducibility'. Which image is the pipe of 'This Is Not A Pipe'?