
The structural design process answers questions such as: What is the most important information or functionality to present up front? How will the user complete his key tasks? How will he move from one part of the application to another in pursuit of his goal? How will he locate and evaluate the information he needs to make decisions on what to do next?
Structural decisions have a significant impact on the usability and desirability of an application, and they often prove difficult to change late in the development process if you get them wrong. For these reasons it’s common practice in HTML application development to spend a significant amount of time creating wireframes, or low-fidelity representations of page structure, and flow diagrams that explain how users will navigate from one page to the next. Structure is equally important in Flex application design, but since Flex applications are organized differently from traditional HTML and desktop applications, thinking through the structure requires a slightly different perspective.
This article covers:
The Designing for Flex series includes the following articles:
I suggest that you read parts 1 and 2 before proceeding with this part of the series.
Download all parts of the FIG series as PDF files that you can print and read offline: adobe_flex_interface_guide.zip (ZIP, 5.7MB)
This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.
Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.