TandemSeven

How do you show on paper something that is dynamic? This is the challenge faced when designing rich internet applications (RIA) or very complex applications with many business rules.

TandemSeven has developed a technique which makes it easy to design and document a RIA: Object-oriented approach to design (OOd). Since OOd is a visual language used to document rich interactions or conditional user interfaces, it allows the designer to communicate in their strongest medium: visualizations. It also exists within a structured framework that is valuable to the technology teams. The technique turns out to have many additional benefits, including:

• A clear means to document all interactions in a lightweight manner 
• A built in mechanism for design reuse 
• A design process whose path of least resistance is a consistent user experience 
• A mechanism that facilitates code reuse by the front-end developers 
• A language and a grammar that allows all levels of the application stack to talk about the functional requirements in an unambiguous manner 
• A means to cleanly and clearly use a design library 
• A system that allows a team of designers to all work on the same project, even the same screen, without stepping on each other.

But why document the design? Why not have the designer build it or prototype it? Dozens of tools exist which merge requirements, UI design and prototype development. Why not use a tool and cut out the entire design documentation process? Here are seven good reasons to document the design: 

1. Building a prototype is not equal to creating a design. Design and innovation happen when you explore the design possibilities, eliminating the bad ones and refining the good ones. Prototyping is about taking a single design possibility and making it deeper. 
2. When designing RIAs you may be designing new interactions that are not supported by the prototyping tool you are using. 
3. The design should not be limited by the designer’s ability with the prototyping tool. 
4. If novel interactions are called for, it is more efficient to have developers begin to build the new controls or interactions as soon as possible. By building it, they will be able to:
        a. More quickly determine the feasibility of the design
        b. Better estimate what it will take to build a production quality version of those controls.
5. Documentation will be required at some time. The QA team will need something written down so they can write their test scripts. Not all prototyping tools provide a means to write these functional requirements. 
6. If you want to reuse modules from one page of your site into another page, prototyping tools require a greater depth of technical capability. 
7. If you have a complex page with many different configurations based on different business rules, a prototyping tool requires you to build out each of those pages independently, whereas our documentation technique allows you to quickly document all the configurations.

With that said, situations do exist where it makes sense to use a prototyping tool. The world is not black and white. You may want to use a prototyping tool if:

• You have a team member very well versed in the use of the tool 
• Your prototype needs are not that complex 
• You need to prototype the entire application 
• You do not have a skilled prototype developer available 
• This is a one time only event. You have no plans to retain the design documentation for future enhancements to the application.

More on OOd
The designers (information architects, interaction designers, user experience architects) and the project team have to learn OOd’s visual language; however TandemSeven has designed the language so that it is logical and intuitive when first encountered. The project team only needs some awareness training, opening themselves up to the possibilities on how OOd can be used to improve their processes. The designers need training on the most efficient ways to use OOd.

Click here to see a simple example of an OOd fully documented.

Want to know more?
Give us a call or email us, we would be happy to help your organization. Also, check back here as I continue this introduction and tutorial to object-oriented design.