Teresa Ovalle

Welcome to Me


on September 7, 2014

A few years ago, I gave input into a specific web design for a specific purpose. The web designer used wireframes to help show our team to demonstrate to how she suggested the layout work for our new website. I found the wireframes to be helpful. Some things can’t be displayed well in a wire diagram, but our team was able to take the concept from the designer and manipulate it to what we were thinking. The process was very beneficial.

In Dan M. Brown’s “Communicating Design, Developing Web Site Documentation for Design and Planning” explanations about wire diagrams begin on page 166. The chapter opens with a definition of a wireframes, “A simplified view of what content will appear on each screen of the final product, usually devoid of color, typographical styles, and images. Also known as schematics, blueprints.” (pg. 166)

On the next page, Brown talks about purpose, audience, scale, context and format of a wireframe.

The purpose of a wireframe is to “help the project team establish the functionality, behaviors, and relative priorities of content on web pages.” (pg. 167) In other words, a wireframe helps show the team the direction of their proposed website. It helps to get everyone on the team on the same sheet of music to push the project forward.

The audience is everyone on the team. “Developers use them to understand the site’s functionality. Designers use them to drive the UI design process. Business stakeholders use them to validate requirements and ensure the design will meet objectives.” (pg. 167) As a stakeholder, I appreciated being a part of the design process. If the stakeholder isn’t happy, then neither is the design team, so using the wireframe to explain the process works well.

The scale depends on how you plan to use the wireframes. “Using them only to instantiate a design concept can make them a relatively quick diagram to put together. Using them instead to drive detailed conversation about requirements and design can yield much longer timelines.” (pg. 167) The design team that I worked with chose to put time and effort into their wireframes to help their stakeholders, my team, better understand the process and the outcome of the website.

The context of a wireframe – “Ideally, wireframe creation begins somewhere between high-level structural work – like flowcharts or site maps – and screen designs.” (pg. 167)

“Wireframes vary in their format from high-fidelity (looking a lot like a web page) to low-fidelity (looking like a bunch of rectangles).” (pg. 167) Our design team chose to use something similar to a wire diagram. Ultimately, it worked well enough, however, after reading through the remainder of this chapter and learning what other types of format could have been used, I would have preferred something with more fidelity. My team did not know a lot about web design, so having something with more fidelity and detailed would have resulted in a higher quality website.

If you are interested in learning more about wireframes, I strongly suggest reading this chapter. There are a number of formats to look at with explanations and, in some cases, tips to help you get started with that particular format.