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.
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:
- Identify each element of the wireframe with a unique identifier and help:
- 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.
- Developers, BAs and other stakeholders who consume the Word specification document or the CSV output.
- 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.
- 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
- Avoid the "Unlabeled" plague that makes it extremely hard to create advanced interactions, or to make sense out of the specification document
- 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.
- Productive - When used from the project get-go, save the UX team significant amount of time in downstream consistency enforcement and tons of reworking.
- 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
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:
4. Masters
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
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.
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.
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
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.
No comments:
Post a Comment