Wireframes – standalone “illustrations” of screens void of graphic treatment, with indications of functionality and screen flow.

Prototypes – interactive versions of screens with varying levels of graphic treatment/fidelity. The interactivity of the screens should mimic the intended functionality of the final product.


original posted on http://www.strangesystems.net

Wireframes serve a central function in the development of a web site. It is a key tool in communicating the content and layout of each web page for internal and client reviews as well serving as a blueprint for graphic designers to produce designs and for programmers develop functionality.

What are wireframes?

A wireframe is a stripped-down visual representation of a single web page, devoid of any graphic treatment. As the name suggests, it is a framework made with wires, which define basic layout and placement of content and page elements such as navigation; header & footer; branding etc.

They are sometimes referred to as “page schematics”, “page architecture” or even “blueprints” (though the term “blueprint” sometimes refers to a more overall site design).

It is sometime helpful to use the architectural blueprint metaphor in understanding wireframes. Architectural blueprints show you the form of the building, define the functionality of the spaces and paths for circulation, while provide the contractor and interior designer specifications from which to build from. Likewise wireframes define areas of content and functionality, navigation strategy while providing a framework from which the programmer and graphic designer can build from.

A full wireframe needs to deliver the following information:

  • Layout: General placement of page elements such as headers, footers, navigation, content area, and often branding; It communicates decisions that as been made as to the navigation strategy of the site; it also shows the prioritization of the content on the page.

  • Content inventory: What content needs to be present on the page

  • Web elements: Headers, links, forms, lists, images etc.

  • Behavior: Notes/annotations may be added as to how elements should be displayed (such as number of elements, default display etc.), or what functional behavior occur when an element is activated (popups, page refresh, link to another page, or external site etc.)

When are wireframes created?

Wireframes as deliverables are developed as a part of Information Architecture phase. It usually follows the “Business Requirements” phase of the project and precedes any graphic design and technical development.

Usually this is the role of the information architect. On smaller projects, this often become the role of the project manager.

Who is it for?

The following table shows the consumers of wireframes and how they are used.

A blueprint with which they can review whether the design meets their needs; a preview to the actual site design; Key deliverable, the signoff of which kicks of design and development phases of the project

Consumer Usage
Project Team A communication tool around which aspects of strategy, technology and user experience can be discussed
Client Stakeholders  
Graphic Designer A guide upon which they can develop mockup designs
Web Programmer A requirements document that details layout, content display and functional behavior of a web page to certain extent

Types of wireframes

  • Content-only wireframes (aka Powerpoint wireframes): Powerpoint is used to define the key pages of the site. Name of the page, and a list of content items are captured on each page without information about layout or placement. This technique can be used to quickly capture client requirements and sketch out a site without having to go through the labor intensive work or creating detailed wireframes. Tools: Powerpoint

  • Block diagram wireframes: This type of wirefames is one step higher than the Content-only wireframes in that it offers basic layout information through blocks of functionality, and content grouping. These wireframes can be used in conjunction with detailed wireframes to provide a high level strategic overview to the wireframes before diving into the details. Tools: Powerpoint, Visio

  • Detailed wireframes: Fully-loaded wireframes with layout, content, web elements information along with notes and annotations on page behavior. Tools: Visio, OmniGraffle

Developing wireframes

Here are some basic steps an information architect would take when developing wireframes.

Gathering information

  • Business requirements: Ideally you would already have documentation from the the Business Requirements phase. This document will spell out major site functionality, key site pages and what content/functionality would need to be presented on them.

  • Content requirements: If there is no documentation from a previous phase it is important to meet with client and sketch out what needs to be presented on key pages of the site. A content-only wireframe is a good tool to do this.

  • Existing design requirements: Additional information such as need to integrate with existing site guidelines or need for consistency with previous site design, etc. should also be noted.

  • Bandwidth requirements Some clients may have to serve a low-bandwidth user base in which case, the design will have to be more text-reliant and less image heavy.

  • Software requirements Some sites are CMS-driven or software driven (such as blogs). Many software packages have layout and navigation rules the design will have to conform to.

Prioritizing/grouping information

  • Once the information has been gathered, it is important to first group and then prioritize how they need to be displayed on the page.

Navigation strategy

  • Clients may have strong preferences as to how navigation should work and be placed on the page. If there is no strong preference, software requirements and usability should dictate how navigation should be configured.

Drawing wireframes

Wireframes should include:

  • Key page elements & location: header, footer, navigation, content objects, branding elements

  • Grouping: side bar, navigation bar, content area, etc.

  • Labeling: page title, navigation links, headings to content objects

  • Place holders: dummy text (lorem ipsum dolor…), and image place holders

The question often arises: how many wireframes should I create? The answer is how ever many you need to get the job done. (or in our case how ever many we said we will create). Having said this the follow should be included in any good set of wireframes:


  • Homepage

  • Major sub-pages and “portal” pages

  • Key template pages

  • Pages with forms


  • Search results page

  • 404 Error pages

  • Any other pages that provide clarification to the overall development process

The User Interface Editor can be used to specify and set properties for predefined dialog boxes that are displayed during installation on the target computer.

The User Interface Editor is a tree control containing two sections: Install and Admin. The Install section contains dialog boxes that will be displayed when the end user runs the installer; the Admin section contains dialog boxes that will be displayed when a system administrator uploads the installer to a network location.

A default set of predefined dialog boxes is displayed in the editor; you can rearrange or delete these if you choose. The default set of dialog boxes varies according to the type of deployment project.

Predefined dialog boxes are divided into three categories:

  • Start dialog boxes are displayed before the installation begins. Common uses are to gather customer information or to allow the user to change the installation directory.

  • A progress dialog box is displayed to provide feedback on the progress of an installation.

  • End dialog boxes are displayed once the installation has finished successfully. Common uses are to notify the user that the installation is complete or to allow the user to launch the application.

Dialog boxes can be moved between category nodes via dragging with the mouse or via the Cut and Paste commands on the Edit menu.

Installation User Interface Dialog Boxes

Microsoft Visual Studio provides a number of predefined dialog boxes that you can use to display information or gather input during an installation. The following is a list of available dialog boxes. Not all dialog boxes are available for all deployment project types or for Admin installers.

Dialog box Purpose
Checkboxes A, B, or C Presents up to four choices using check boxes. For more information, see Checkboxes User Interface Dialog Box
Confirm Installation Allows the user to confirm settings such as installation location before beginning the installation. For more information, see Confirm Installation User Interface Dialog Box
Customer Information Prompts the user for information including name, company, and serial number. For more information, see Customer Information User Interface Dialog Box.
Finished Notifies the user when the installation is complete. For more information, see Finished User Interface Dialog Box
Installation Address Allows the user to choose the Web location where application files will be installed. For more information, see Installation Address User Interface Dialog Box
Installation Folder Allows the user to choose the folder where application files will be installed. For more information, see Installation Folder User Interface Dialog Box
License Agreement Presents a license agreement for the user to read and acknowledge. For more information, see License Agreement User Interface Dialog Box
Progress Updates the user on the progress of the installation. For more information, see Progress User Interface Dialog Box
RadioButtons (2 buttons) Presents a choice between two mutually exclusive options using option (radio) buttons. For more information, see RadioButtons User Interface Dialog Box
RadioButtons (3 buttons) Presents a choice between three mutually exclusive options using option (radio) buttons. For more information, see RadioButtons User Interface Dialog Box.
RadioButtons (4 buttons) Presents a choice between four mutually exclusive options using option (radio) buttons. For more information, see RadioButtons User Interface Dialog Box.
Read Me Allows the user to view rich text. For more information, see Read Me User Interface Dialog Box
Register User Allows the user to submit registration information.
Splash Presents a bitmap to the user to display a logo or branding information. For more information, see Splash User Interface Dialog Box
Textboxes A, B, or C Prompts the user for custom information using one to three text boxes. For more information, see Textboxes User Interface Dialog Box
Welcome Presents introductory text and copyright information to the user. For more information, see Welcome User Interface Dialog Box

A User Interface Management System (UIMS) is a mechanism for cleanly separating process or business logic from Graphical user interface (GUI) code in a computer program. UIMS are designed to support N-tier architectures by strictly defining and enforcing the boundary between the business logic and the GUI. A fairly rigid Software architecture is nearly always implied by the UIMS, and most often only one paradigm of separation is supported in a single UIMS. A UIMS may also have libraries and systems such as graphical tools for the creation of user interface resources or data stores.

Generally, you cannot easily use multiple UIMS systems at the same time, so choosing the correct model for your UIMS is a critical design decision in any project. The choice of system is dependent upon the system(s) you wish to create user interfaces for, and the general style of your application. For example, if you want to create a web based front end, or just a standalone application or both that would be an important factor in choosing. If you want to deploy to the Macintosh, Windows and Linux, that would further influence your choice of a UIMS system.

The event, “Google Presents User Experience & Mobile Apps, Google user experience designer Leland Rechis started his talk by re-iterating Google’s mission: Organize the world’s information and make it universally accessible and useful. Rechis added that mobility is fast-becoming the key to making information “universally accessible,” but he warned that without a solid user experience, there is no way mobile applications can be useful.

Rechis said that when Google plans to launch a mobile application, it looks at the potential app through six layers:

1. Understanding users, anywhere, anytime

2. Fits in your pocket

3. More personal than the PC

4. Consistency across modes

5. Localization is intensified

6. Integrated devices, modes, products

Rechis then broke out the company’s mobile development and optimization strategy by each level.

Understanding users, anywhere, anytime

Rechis said that Google breaks down mobile users into three behavior groups:

A. “Repetitive now”
B. “Bored now”
C. “Urgent now”

The “repetitive now” user is someone checking for the same piece of information over and over again, like checking the same stock quotes or weather. Google uses cookies to help cater to mobile users who check and recheck the same data points.

The “bored now” are users who have time on their hands. People on trains or waiting in airports or sitting in cafes. Mobile users in this behavior group look a lot more like casual Web surfers, but mobile phones don’t offer the robust user input of a desktop, so the applications have to be tailored.

The “urgent now” is a request to find something specific fast, like the location of a bakery or directions to the airport. Since a lot of these questions are location-aware, Google tries to build location into the mobile versions of these queries.

Fits in your pocket

Rechis stressed the limitations of mobile phones. He pointed out that any mobile application has to be able to fit on a small screen and cannot require complicated text input. Also, since the third screen has no X-axis, layout has to clean, simple, but maintain the basic usability of the parent desktop application. Rechis also stressed that the “density of information” changes on a mobile phone, requiring designers to identify only the most essential parts of any given application. Obviously, juggling all this isn’t easy.

In order to achieve usable mobile applications, Fechis reminded the audience that they have to be willing to test and re-test applications with users. Otherwise you can’t get it right.

Also, building successful mobile apps requires developers and user experience people who are passionate about their subjects. He pointed out one Google employee who went to great pains to make sure that Google Maps gave directions correctly for Japan. Since street signs and markers in Japan are different than in the West, this employee had to go to great lengths to make sure that the app rendered maps and gave directions in ways that are useful for that country.


Google always strives to keep the look and feel of any Google application consistent, both within the type of function (i.e. all blog search results look different than map search results) and on devices (a map search on a desktop looks and feels like a map search on a mobile phone and vice versa). If mobile applications are to be universal, then developers have to maintain patterns and designs across all screens.

What is Strategy

Before we define User Experience Strategy, lets define Strategy. Answers.com says
“Management plan or method for completing objectives; plan of procedures to be implemented, to do something.”

That’s a bit vague, so lets try to get some handle here. Strategy is the path between Vision and executing vision or in other words a vehicle to realize vision. hmm so it’s not just a tool but has great importance. It’s a 3 step dance:

Vision > Execution Strategy > Execution

Many organizations tend to go directly from vision to execution, missing this important step in between, perhaps most important one as it is allows for energies and resources to be canalized in the right direction.


For this article I’ll equate Vision to goals even though that’s not entirely correct. But you’ll see why I am doing this.
Goals that an organization has are more or less a variation of:

  • Increase Revenues
  • Reduce Costs
  • Increase Profits
  • Increase customer base
  • Improve brand image


You need to figure out what variation of which goal do you want focus on in the solution you are building.



So now that some context is set for what strategy is and role it plays, Lets dig deeper into it. Strategy can apply to anything with a vision from building a house to marketing a product to anything. So there can be :

  • Marketing Strategy
  • Brand Strategy
  • Pricing Strategy
  • Product Strategy
  • Experience Strategy
  • Innovation Strategy
  • Coding Strategy
  • Combat Strategy


… this list can go on and on..

Important thing here is to understand that more than one kind of strategy can be applied to reach the goals.

Lets take an example – Microsoft v/s Apple – both would have had similar goals, but applied different kind of strategies, Needless to say but Microsoft focused a greater effort on marketing strategy and less on experience strategy, Apple was opposite.

Lets take another example – Google v/s Microsoft (can’t resist this one). If you look at it Google is NOT a search company, it’s brand stands for innovation , that’s the reason we just absorb “any” product they launch.. everyone has to have an account with new products from Google.

A non-tech example would be airlines – Jet blue had experience strategy, they had well developed systems (in non-technical sense) to ‘institutionalize’ ability to provide superior experience

So User Experience Strategy is one of the many that an organization can choose from. Each strategy has a cost and value that it delivers. Also strategy does is relative not absolute. It depends on time, market, and competition.

How to decide on the strategy? Here are some tips, (but this is a subject that deserves a separate article):

  1. Vision: This of course is the starting point, strategy must align with vision.
  2. Industry Direction: Take an example of Hotel industry, the base direction it is taking is experience strategy, which is good, but question to be asked is if you can differentiate yourself on same strategy or something else is needed. Consider Yahoo – it has opened yahoo products like a development platform, because even though industry is moving towards Innovation Strategy, they cannot generate enough innovation in house.
  3. Socio-Economic Situation: Back in 1940-50s airline prices were regulated by government, given this airlines could only differentiate based on service and experience they provide. Once that regulation was removed, price wars started and strategy changed.
  4. Competitive Landscape: This is very much of like Industry, however in case you have specific competitors you are going after, looking at Industry direction alone would not be enough, you competitor might be doing something that changes Industry direction
  5. Your offerings: Last but not the least your capabilities. Sony is putting a great deal of resources on Blue Ray disc (one of the two HD DVD Formats being released). This has resulted in them selling new Playstation boxes at a loss because Blue Ray drives are being shipped in new PS and have added significantly to costs. But with competition from X-Box they cannot increase prices. So look at where is the strength in our offering and adopt the right kind of strategy.


User Experience

Okay, let me take a parallel road and look at User Experience at very high level, and then we’ll converge it with Strategy discussion.

So what is User Experience? Answers.com does not even tries to answer this, so lets take it from Wikipedia:

“User experience is a term used to describe the overall experience and satisfaction a user has when using a product or system.” We should change ‘system’ to service.

In more materialistic terms I would say User Experience is essentially something that resides in User’s long-term memory and has a bearing on decision to transact with the company in future. This could be positive or negative.

You need to ask following questions, and these will map you to User’s experience life-cycle:

a. How do users come to know of their need?
b. How do they find the right product/service?
c. How do they make a decision on that product/service?
d. How do they order it?
e. How does it get delivered?
f. How does it get installed?
g. How are problems with product and service resolved?
h. How is it disposed?

Am sure some questions here are new and do not form a part of current experience design discussions, but all are important opportunities.

Now map your user’s path across these stages and rate your and competition’s performance at each stage. I like to follow a 5-point scale as it brings enough granularity, and at the same time has limited subjectivity. I do not recommend using 1 to 5 scale, instead use (-) 2 to (+) 2, i.e. –2, -1, 0, +1, +2

-2 Significant problems with experience
-1 Mild problems with experience
0 As expected
+1 Mild improvements to expected experience
+2 Significant improvements to expected experience

So now you have some assessment of User Experience at high level

Bringing the two together


So now you know which places the experience fails. Next Step is to “Identify Critical moments”. These are moments where users decide to move to next step or not. For e.g. lets say you are doing this for Parking Garage and experience of finding the garage was significantly negative, but once they find the garage they might go ahead if other parameters are fine. But if at this stage attendant’s approach is not right and if customer place high value on attendant’s attitude making it “critical” for customer, she might decide to look further.

So identify such critical moments and those are where you start to focus on. With this you have now narrowed on 2-3 such critical points and start to go deeper.

How do you find what’s critical and what’s not – User Observations are the most reliable method. Go in the field see what goes on and you’ll know what’s important what’s not. In addition talk to people. Do this for your product/service as well as competition product/service

A general principle for all user interface design is to go through all of your design elements and remove them one at a time. If the design works as well without a certain design element, kill it.   — Jakob Nielsen, author and consultant on user interfaces

A good website should have at least the usability and usefulness of a good book. But, although rarely fully exploited, it has the potential to be far more usable, largely because of the availability of hyperlinking.   — a Bellevue Linux Users Group member, August 2005

A well-designed and humane interface does not need to be split into beginner and expert subsystems.   — Jef Raskin, human-computer interface expert and a designer of the first Macintosh

Computer science departments have always considered ‘user interface’ research to be sissy work.   — Nicholas Negroponte, founder and director of the Massachusetts Institute of Technology’s Media Laboratory

Computing has gone from something tiny and specialized to something that affects every walk of life. It doesn’t make sense anymore to think of it as just one discipline. I expect to see separate departments of user interface, for example, to start emerging at universities.   — Nathan Myhrvold, former Microsoft executive

Don’t make me think.   — Steve Krug, usability expert

If the user can’t use it, it doesn’t work.   — Susan Dray, usability consultant

Most websites today fail basic tests of usability.   — Forrester Research

No matter how good your backend systems are, the users will only remember your front end. Fail there and you will fail, period.   — Tristan Louis, writer about the Internet

The Interface is the system.   — unknown

The only ‘intuitive’ interface is the nipple. After that, it’s all learned.   — unknown (but often attributed to a Bruce Ediger)

Usability cost-benefit data shows that including usability in product development actually cuts the time to market and increases sales because usability and ease of use build quality into products and catch many expensive problems early on in the cycle when they can be addressed at lower cost. Finally, working with users from the beginning of a product cycle ensures that the product is being designed so that users will be satisfied.   — Claire Marie Karat, human-computer interface researcher at IBM

Usability is critical for any application, but for mass-market software, usability spells success or failure more clearly than any other feature.   — Jerrold Grochow, Chief Technology Officer, American Management Systems

Usability really just means making sure that something works well: that a person of average (or even below average) ability and experience can use the thing – whether it’s a web site, remote control, or revolving door – for its intended purpose without getting hopelessly frustrated.   — Steve Krug

Usability rules the Web. Simply stated, if the customer can’t find a product, then he or she will not buy it.   — Jakob Nielsen

User interfaces have to do with people, and computer scientists don’t like to work on problems involving people. The classic work on user interfaces that sets the current paradigm was invented outside of universities in industrial research laboratories and government-funded institutes.   — Stuart Card, interface researcher at Xerox PARC

… when folks read news online, their eyes go for text first, particularly captions and summaries, and graphics only later.   — Bryan & Jeff Eisenberg, usability consultants and authors