These are examples of the early hand sketches I was doing for PurchaseSoft, while we refined the functional space and requirements that the UI and IA needed to address. I start with a blank page, as a means of encouraging openness to many ideas. When time lines are tight, these raw sketches can be translated directly into functional concepts or schematics, and then into design concepts.

Personas are structured descriptions of a projected representative user or group of users, serving as a reference for their needs, goals, motivations, and outlook throughout the creative process. Including stock photos of different faces and then hanging the printed personas in a visible location during feature and design discussions can help a User Experience team to keep the eventual customers for and the people who will use what they design and build in mind at all times.

These captures show one subsection of the process flow (site map) for the main requisitioning module of PurchaseSoft's application, and a page from the resulting catalog of interfaces. Interface audits support functional reviews, baseline usability and design assessments, and document the system for everyone involved in the project. For PurchaseSoft, we mapped and captured one example of every type of screen appearing in each of the application's 13 major modules - nearly 500 in all. We assembled module-specific catalogs by collecting the relevant maps, screen shots, and text descriptions, then printed and mounted the process flow maps on full size foam core to use as references in brain storming and walk-through review sessions.

Rather than create hundreds of screen schematics showing each combination of document, input form, or other major information block, I break the system down into a series of core functional objects with which users interact, detail their attributes, and define the relationships of inclusion and inheritance that link them to one another. As the reservoir of detail specifying all the user-accessible handles for the pieces of information in your system, the map separates data field questions from presentation questions. Thus DBAs, architects, designers, and most other team members can use this map to answer questions about the presence and location of specific data fields - as well as the connections between objects - while work on the schematics or wire frames proceeds without interruption. With a an object map, a roles and tasks matrix, and process flows, you can rapidly build schematics templates that allow the programmatic creation of context specific interfaces with controls placed around these core functional objects. I used Erwin for this map because it provides a considerable data management tool set, plus many file export options. These captures show a portion of the resulting functional object map at two levels of detail.

This matrix collects and maps defined user roles to specific objects and tasks; showing which roles are able to perform which tasks on which objects. In the case of a system with 32 defined roles, more than 100 document types and visible information objects, and dozens of distinct tasks, tracking the total number of variations without a mechanism would be very difficult. It's important to keep in mind that all of these permutations must be specified in advance for QA and testing. The benefit of the matrix is that it directly tells IA's and designers what needs to appear on a given interface by cross-referencing defined objects with defined operations. With the objects map and process flows, the matrix defines the vocabulary your entire team will use throughout the project lifecycle. I frequently build basic grammar patterns such as "edit member profile" and use the strings as page label. This helps infer the total number of template types before wire framing begins.

This is a color functional concept combining screen shots from other applications with original elements to serve as discussion pieces in functional reviews and source materials for initial design concepts. As a shortcut around black and white or schematic concepts, color functional concepts answer the need for rapidly assembled higher quality renderings for audiences wanting less actual detail.

Akin to a creative brief in an agency setting, the UI Strategy defines the objectives of the interface team and effort, frames the business requirements, assesses existing collateral and other relevant identity materials, outlines the technology architecture underlying the interface, defines core interaction metaphors and user models , names reference documents, and defines the behavior and types of GUI components anticipated. In toto, it presents the sum of all vision and discovery activities related to the user experience. For this effort, the UI Strategy separates the functional concepts into separate components, providing detail on how those components appear and behave, and the information elements that constitute them.

These concept renderings show how the functional mock ups might translate into a defined palette. Detail elements like synchronized focus indicators and redundant iconic and list based views are visible. Building on the process flows documented in the interface catalogs, we rendered a series of screens depicting the most common user scenarios in this style, to demonstrate how a UI based on the new logical model might look. NB: These concepts were rendered by a designer, under my direction.

Our final activities involved packaging the IA and UI related work done to date for internal review by the Board of Diretors, preview with key customers, and as a showcase for the potential of our application in support of fund-raisfund raisingse purposes.

This is a functional requirements specification I drafted in close cooperation with the Product Manager and client executive team of a collaboration application startup firm based in Israel. Built as the conclusion of a ten-week product and brand definition engagement, this specification drove the architecture and development phases that followed. A version control system like those available from Rational Software makes this deliverable even more powerful.

For Siemens North America's test deployment of IBM WebSphere as their preferred e-commerce platform, I defined a modular IA template and created a set of false color schematics documenting the control components, data fields, and detailed functionality of three 8000+ product catalogs and ordering interfaces. These templates were based on generic use-cases defined across several business units, and eventually supported catalogs in three widely different verticals as part of a $10 million, ten-month effort. In this case, I was able to streamline an eight level navigation system used for a print catalog down to three levels, dramatically simplifying the navigation flow to meet the needs of building contractors using the catalog for rapid access to specific parts while working at construction sites.

As the end result of an architecture and design project, a User Interface Specifications packet combines several of the deliverables shown above into a comprehensive description of the structure and behavior of an information system. Packets are tailored to meet the needs of designers, developers, and project managers.

In the packet, user roles, tasks, and objects derived from use cases and functional requirements are shown within context specific screen schematics. These schematics consist of modular functional, input / output, and navigation elements, that are within reusable templates. Wherever possible, behavior and appearance are defined at the template or component level, rather than on individual screens, allowing programmatic updates and rapid prototyping. The range of possible paths through the system is represented by functional object maps, site maps, and process flows that link together specific screen schematics. Screens are described in verbal and textual fashion, using false color or black and white wire frames paired with detailed listings of the displayed text and data fields. I use a custom notation system for the screen details that indicates repeating (search results and tabular listings) versus idiosyncratic information chunks, and lifts data fields directly from functional object attributes.

As a reference for some of the pieces for PurchaseSoft shown above, here's a look at the existing client interface; outdated, slow and fraught with usability problems. This is what happens when you have no IA, no strategy, and no process.