Why wireframe?

By Jonathan FalknerSoftware Developer, former Fynyddian

Wireframes, wireframes, wireframes... they are the foundation on which traditional website development is built. We design the underlying data architectures, build an example of what a site will look like, and that document ends up being the foundation for the design team, the development team, and the data architecture team. Wireframes are essential, core aspects to the development cycle for a new website, or are they?

Let's briefly review the history of wireframing. Humanity has been "wireframing" for centuries. We've drafted designs of physical buildings, sketched out ideas for a new invention, and orchestrated large organized cities with vast networks for travel and communication; stone carvings for construction design, then paper drafts, and finally modern 3D computer aided design systems. The process of building a structure has always depended on a representation of the final product that enabled the builders to work in tandem to create the final structure. A similar progression has occurred with the "construction" process for building a new website. Traditional designs were sketched out on paper, and then digital systems came into play. The concept of a wireframe became an integral part of website design in the same way a 3D computer aided design became an integral part of building a new skyscraper.

The move to digital wireframes really didn't change the process much. Designers still designed in static files using static sketches, and the end result was manually broken up and stitched together using HTML and CSS.

Then javascript made its appearance.

Interactivity with the page! Alert boxes telling the user when they made a mistake! The excitement could be felt back then. The possibilities were endless. But endless possibilities put a bit of a wrench into the works with regard to wireframes. How do you show real interaction within the construct of a static wireframe? Annotations detailing actions sufficed for simple interaction, but what about more complex interactions that require the use of technologies like AJAX?

Are wireframes still the right solution for determining the user experience and site architecture? AJAX-rich applications and websites require hundreds of annotations on user experience and interactivity, and can be misunderstood easily. Usability can't be tested within the confines of a wireframe, and building an entire application or site just to see if drag and drop is a good interface for a portion of the project is extremely inefficient.

A "rapid development" process requires starting user testing as quickly as possible to ensure the UX design works. Wireframes served their purpose, but it's time for them to grow up. What is needed now is "rapid prototyping".

"But wait," you say, "we already do prototyping. It's part of the standard SDLC process." Yes, but in standard development, the prototype is usually created after wireframing and often after design approvals. This is inefficient. If user testing shows a UX feature to be non-intuitive, removing or changing it may impact the designs, requiring considerable rework, and the client has to approve the new designs. What if, instead, you build the prototype as your wireframe step? What I'm saying is that you need a little Fynesse.

Fynesse is the design and development philosophy crafted at Fyndd to ensure fast-paced iterative development still maintains direction and focus, with consideration for the actual end-users. The Fynesse process cuts out unneeded cruft and gets the UI/UX prototype in front of the user as quickly as possible, in interactive wireframe form. To develop with Fynesse is to get the user to interact with the wireframe; to get feedback on the usability before spending time building the actual code base. Balsamiq, Dreamweaver with AJAX plugins, and Axure are just a few examples of systems out there which support this development style, and there are numerous others in the open source community.

When you can get something in front of the user in weeks instead of months or years, the feedback can change the course of development long before the graphic artists start their first rough drafts. Innovation is no longer a major risk. With the Fynesse mindset you can build an innovative user interface concept, present it to the users while the project is still in its infancy, get feedback, and know that your new UI/UX widget idea is a smash hit (or a total flop). And the impact to the long-term project timeline is greatly minimized.

Rapid prototyping is the new wireframe, and the innovative possibilities that nearly instant UI/UX user feedback provides is really exciting. So, let's get prototyping!