As a interaction design consultant wandering the world from project to project I found it necessary to innovate implementation processes to save time and give me an edge over competing user experience teams. This innovation took the form of abandoning processes that were not delivering value and adding detail to others that were.
The final result after five years of refining processes for implementations is what I have called UI Formula Methodology. I believe this approach balances the opposing forces that interaction designers must always deal with – speed and context.
The need for speed
As most interaction designers will attest, the time between being handed the job and the delivery date for recommendations is getting smaller. The few weeks normally needed to analyze and develop a comprehensive set of recommendations seems to be a luxury few clients will afford.
Add to this the popularization of development techniques such as agile, extreme and scrum are increasing the number and speed of design cycles. All this is applying pressure on interaction designers to cough up recommendations at a rapid pace or in some cases these recommendations are pushed out of the development loop altogether.
In large companies, to make sure user experience issues are not overlooked, UI review gates are added at each stage of delivery. While this is good in principle, the result is a general perception by developers that user experience is a weight slowing down the pace of development. This of course adversely effects the sacred cow - speed to market. In this way user experience typically ends up looking dated or old world – a long way from typical interaction designers internal perception of themselves as cool, hip and socially progressive folks.
In some cases product management will look to counter any slow down by getting permission to go outside the standard development process – often by proposing outrageous delivery deadlines that negate the possibility of any interaction design inputs at all.
What is needed is a more efficient method to allow those providing the user experience input to keep up with the acceleration of software development process.
Recommendations need context
However delivering recommendations on time is not enough. Providing clear context for design decisions is increasingly a pre-requisite. Stakeholders are becoming more sophisticated in user experience-based issues and not as easily led as they once were. In many cases this is for good reason with many project managers having a failed application or two due to bad user experience advice in their pasts.
To some, a design recommendation can look to be superficial - purely a matter of taste rather than good business sense. In this situation recommendations can be quickly given low priority or even worse, disregarded altogether. However the very same recommendations when presented with clear context can be a logical business choice and promptly added to high priority list.
Quite simply for recommendations to be successful they need to be presented with logical backup. The problem is that while coming up with the recommendations themselves is an effort, developing the context with which to back them up can be a significantly larger effort.
Deliver fast and often
This is a nightmare for interaction designers. Not only is development speeding up requiring us to deliver recommendations faster but now we must also provide solid documented evidence to back-up the very same – more than doubling the total required effort.
Over time to reduce the workload associated with providing this context, I developed the UI Formula approach which looks to solve the issue of delivering recommendation quickly and while at the same providing clear context for those recommendations.
UI Formula Methodology enables delivery of your recommendations and their associated context in a logical series of stages, dealing progressively from higher to lower level issues. This staged approach allows you to deliver quickly and often, each delivery adding detail to the previous.
Making a customer wait is never good. It is better to deliver staged logical packets of recommendations that can be easily digested. Each packet can be followed up by another, until the process is complete. In the end you are left with a single document providing a list of recommendations, each clearly justified.
The methodology
It is the premise of this methodology that good user interfaces are highly consistent. UI Formula Methodology documents a user interfaces underlying structures (or formulae) in a view to promote their consistent implementation. Divining these formulae is achieved by dissecting the interface into multiple levels.
The Anatomy of a User Interface
The UI formula methodology divides the user interface into five discreet levels from high to low:
- information architecture
- screen architecture
- site furniture
- tile architecture
- presentation logic
In keeping with the UI Formula Methodology approach I will post a description of the first level “Information Architecture” and descriptions of the other levels in posts to follow.
Information Architecture
In this case the term information architecture (IA) is used to describe only the high level breakdown of screens within an application and the navigation system used to access these screens.
N.B.
The emergence of RIA technologies is radically reducing the required number of screens in comparison with that of PIAs . However it is expected that RIA’s of any significant size will include separate screens for logical functional silos. As such while we are likely to see a considerable simplification in information architectures going forward, only time will tell if this level is still worth the effort of analysis.
A Hero Deliverable
An effective way to analyze the information architecture of an application is with the creation of a diagram. In my experience such diagrams can be very effective with stakeholders – in some cases you will even see them print out and put it up on the wall.
The following is an example of an IA diagram utilizing the “visual vocabulary” approach described by Jesse James Garret. In this case an oval shaped object has been included to represent menu items
In a green field situations
The IA diagram is an excellent briefing tool, providing in a single view of the distribution of functionality across an application. In my experience it is invaluable initially to walk stakeholders through a proposed application. Such a walk through can quickly communicate:
- Included functionality
- Missing functionality
- Local cultural associations with menu item names
Skipping this step and diving straight into individual screens can make for bad meetings. It is not uncommon for individual stakeholders to have different functional focus areas. In this case wading through screens at an early juncture can result in bored and sometime disruptive clients. However by starting with an IA diagram immediate context for the entire footprint of the application is displayed and can be efficiently discussed.
The IA diagram can also be leveraged to provide positional context of an individual screen before displaying that screen – especially important with complex applications.
In legacy situations
This highest level of analysis can also be very powerful in exposing problems with legacy applications.
It tends to be that either very flat (lots of items at the same navigation level) or too tall (lots of navigation levels) diagrams are more difficult to use. In these situations time can be spent with the customer to look at ways to change the navigation system to something more balanced.
By looking down on groups of screens, any inconsistencies in repeating screen clusters (e.g. add, edit, delete) are obvious. In this case a decision can be quickly made as to the preferred approach so it can be applied consistently across the application.
Information architecture patterns are a particular interest of mine that I believe are often be overlooked. When comparing the information architectures of competing applications it is my experience that it is often the case that they are standardized. As such by preparing the IA the diagram of your customers competitor can be a very revealing exercise both for you and your stakeholders.
Common IA formulae
The following is a list of some commonly occurring formulae that result from information architecture level analysis
A min/max number of levels of navigation
My current rule of thumb is a maximum of three levels anything deeper can give user the feeling of crawling into a cave.
A min/max number of items at any one level of navigation
In my experience the optimal maximum number of items within any one level of navigation is five or six. By stipulating the minimum or maximum in a formula you simply contain the possibility of tab blowouts.
A max number of words per navigation item name
Really long navigation names look bad – rule of thumb is three words maximum.
Standardized words for menu items
The words used to describe different functional areas different from culture to culture. It makes sense to work out what these are and document them – as a bonus the process of working these out displays close alignment with your customer
Standardized ordering of menu items (from first to last)
The process of working out what is the most important functionality can be contentious but in the end can be valuable in creating easier to use applications.
Standardized screen flows (e.g. for add, edit, delete operations)
This is an area where looking at the market leaders can be very useful. But in the end what is more important is a solid consistent approach.
That’s it for this installment of the UI Formula Methodology - I am looking forward to your comments. The next will be a rundown of the Screen Architecture and Tile Architecture levels.
