OAD is a wireframing and specifications technique for documenting complex business logic and interactions. OAD allows the designer to decompose a screen in a manner that reduces complexity. Even if the screen has millions of variations, OAD can document the design in just a few pages.
What is complexity in UI design specification
In the context of UI design specification, the number of variations of a screen measures complexity. For a complex screen, the designer has four options:
- Design and build it
- Design all screen variations
- Design and document a suggestive UI that the team extrapolates to all variations
- Decompose design to reduce complexity
Design and build it
When you design it and build it yourself, the final quality is no better than your weakest skill. Also, for anything sufficiently complex, implementation decisions begin to distort design decisions.
If you are working on a project within a domain familiar to you and you have done similar applications many times, then this option may work for you. Otherwise, consider a different option in designing your complex application.
Design all variations
It is possible to design all variations for simple screens. However, once the number of variations exceeds 5 to 10 screens two things happen; one, the effort of maintaining the design over iterations becomes burdensome; and two, the project team begins to get confused on what is causing the variations and why.
Document a suggestive UI that the team extrapolates
Documenting a suggestive UI is a valid option in many cases. A suggestive UI is a design that shows a few variations with notations on how to extrapolate those variations. The designer is suggesting to the project team what the UI should look like and how it should behave. If the designer and project team have the time and proximity to work closely together, then this approach will work with moderately complex UI designs.
Decompose screen
Reducing complexity through decomposition is the core of OAD.
An example of a complex screen
The image below was taken from the project that inspired OAD. It is a wireframe made up of 10 modules—a module is shown as a grey box encompassing a group of UI controls. The first module on the page has 4 different forms it could be in—e.g. 4 different module states. The next module has 26 different forms. The next 8 modules have 10,6,3,5,3,7,3 and 3 module states respectively. Given that these module states are mutually exclusive, we have over 17 million different possible variations for this screen.
When looking at the design and development options outlined above, it is obvious that OAD is the best approach for a screen this complex. All the other methods will either be too time consuming or leave too much to interpretation.
What is meant by Object-oriented
When you hear the term Object-oriented, you are likely to think of object-oriented programming. While this technique was inspired by that approach, it is not a programmatical approach at all. Objects are meant in a metaphorical way as illustrated in the image below.
While I have never used OAD in the manner suggested in the image above, it should help you form a useful mental model for OAD. When designing and specifying with OAD, think like you are building an UI with a series of objects that you can stack, rearrange, or show different aspects of.
Origins of OAD
OAD is not unique in its approach. Over the course of interviewing hundreds of potential hires, I have seen many variations of a method of reducing complexity through decomposition. What is unique about OAD is how long it has been in use and the number of projects and people using it.
OAD in its current form has been used to design and document hundreds of projects since 2005. It came about when Matt Hanson and Mark Hines from Orbitz worked with Nick Iozzo, JoAnne Wang, and Kal Kalotai from TandemSeven. At the time, they each had over 10 years experience designing and documenting complex UIs and interactions. They combined that experience with Contextual Inquires performed with developers and QA analysts to develop this technique.
Since then, the technique has gone through two major revisions based on the joint experiences of all the IAs using OAD. What is presented hear is a generalized non-proprietary approach. This is being shared in an effort to help create a unified approach in UI specifications in order to assist with training, recruiting, and to support the development of tools better able to support design through decomposition.
Next: Syntax of OAD (estimated March 4th)
