Home > Wireframes

Wireframes

Find below excerpts from just a few of the countless wireframes I’ve authored over the course of my career to date.

Click on thumbnails to view the excerpt at full size.

Cursor over each full-size excerpt to view more information on each and a link to review the full document.

What are wireframes?

Wireframes are the type of document most closely associated with the role of UX Designer.

More specifically, though, they represent the output of the subset discipline "Interaction Design (IxD)." Wireframes specify the form and behavior of software interface components. They are typically arranged sequentially by scenario and include detailed annotations.

Wireframes should not be confused with prototypes, which are distinct in being interactive and navigable. Wireframes are static, utilitarian, formalized documents similar in nature and purpose to architectural blueprints. Wireframes are consumed by Developers who use them to write production code and occasionally by Visual Designers to create comprehensive layouts (which in turn are used by UI Developers to code pixel-perfect interfaces).

Wireframes get their name from their often spartan black-and-white appearance, depicting only the outlines of the specified screen components. However, wireframes are occasionally rendered in high resolution when stakeholders besides Developers need to review them.

Are wireframes obsolete?

No.

A recent school of thought holds that because a number of modern prototyping tools enable UX Designers to combine the Interaction Design (IxD) and Visual Design steps, prototypes have obviated the need for wireframes.

While such a strategy might suffice in certain instances and for smaller projects, it just doesn’t scale. For large, complex enterprise solutions, the time it would take to prototype everything would be prohibitive.

And forcing every change through a UX or UI Designer can create an unnecessary bottleneck.

Not necessarily my look-and-feel

As you review these excerpts, please bear in mind that the color scheme, fonts and iconography that occasionally appear in them may or may not belong to an employer’s PRE-ESTABLISHED look-and-feel.

Often the screens comprising a workflow I was designing had to comport with a company aesthetic for the sake of consistency. In such instances, a separate Visual Designer would apply that look-and-feel AFTER I had finalized the wireframe.

Consider judging these wireframes by their manifest clarity and descriptiveness.

Examples of Visual Design I’ve created can be found here.