This phase is dedicated to the effort of getting the structure of our site or application mapped out. The more complex our project is, the more important it will be to spend the time required to map out the page structure and task flow before we move onto other steps. If we are creating a simple brochure-style website or small application, it lessens the need for a thorough investigation and task flow documentation. Nevertheless, it is a good habit to get into and it helps communicate our plan to the client and/or team. If we are working on a complex website, web app, or other applications, it is absolutely critical that we first map out the task flow and interactions the user will face when attempting to complete a task.

We should consider the creation of a holistic task flow diagram or site map of the product, one of our first primary concerns. If need be, we can shut our office door and produce this map alone based on research we have completed to date. There are situations wherein it is better to shut out the noise of opinion so that we can process everything to come up with a recommended solution. However, I would recommend calling the stakeholders and important team members in for a brainstorming session. I have found it expedites the mapping process immensely when we have everyone in the same room talking over possible solutions.

It can be difficult to give proper credit to the originators of certain commonly used UX techniques. However, we know the flow process chart was originally developed by Frank Gilbreth Sr. and presented to the American Society of Mechanical Engineers in 1921 (http://en.wikipedia.org/wiki/Frank_Bunker_Gilbreth,_Sr.).

Mr. Gilbreth has a particularly fascinating history. He worked at refining the physical world as UX designers do in the virtual world. His charting methodology has since been adopted and modified for use in many different industries. The first standardized flowchart methodology specific to UX design was invented by Jesse James Garrett in 2000. More details can be found online at the website of Mr. Garrett (http://jjg.net/ia/visvocab/).

If we were to search the Internet for the meaning of flowchart shapes, we would find thousands of examples and possibly a few different interpretations for what each shape and line quality mean. Adopting and applying a deeper visual vernacular can greatly expand the amount of information we can pack into our interaction maps. That being said, we shouldn't consider it a requirement to adopt these charting languages in their entirety. It is good to be familiar with the industry standards for creating flowcharts, and whether we adopt or modify is perfectly acceptable, as long as the flow of information is clearly mapped out and easy to comprehend at a glance. Understanding the basic principles of task flow creation should be enough to get us started.

Here is an example of some of the most common flowchart shapes and their meanings:

Here is an example of a simple task flow diagram:

This flowchart example documents the experience expected when installing a piece of software. The primary task here is to determine if the end user has an existing account or if they need to create a new account.

As we can see from the preceding diagram, each rectangle represents a page or task. It starts at the uppermost part of the diagram with Download & Install of the application. The reader of the document simply has to follow the arrows to view the options available to the user and the subsequent steps they encounter as they make decisions and enter data.

Here, we can see the experience branch out when the user is asked if they have an existing account. If they do, they are asked to sign in and are taken to their dashboard. If they do not have an existing account, they will be asked to create one. They are then taken to a tutorial to learn how to use the application. It appears that the tutorial consists of multiple pages, and the user will be given a chance to skip and go directly to their dashboard. By using a dashed line, the chart appears to hint that skipping the tutorial is not the preferred path they wish the user to take, but it is available.

Though just a small snippet of a larger experience, we can begin to see how much information can be conveyed at a glance. This is particularly significant when it comes to the branching of decisions. The more options we offer, the more complicated our map becomes. The experience starts to complicate exponentially if each answer to a question leads to more questions. Add a few of these branching questions in a sequence and our experience would be extremely difficult to convey with a text-based explanation.

Let's examine the mundane experience of entering a home in the following flowchart:

We start by entering the house. Once in, we immediately have many choices to make. They all hinge on which direction we choose to move in. Once we have made our decision, we have another set of unique choices awaiting us. Take a moment to think about how we would describe the same experience using only text. Certainly, it can be done, but it would take far more time and mental processing for the reader to understand. The preceding figure offers a visual solution that can be understood at a glance.

I recently received a functional specification document from a co-worker who was managing a project that my design team was expected to work on. He explained, in moderate detail, how the product would function using only text. Though not a particularly long document, it took us half a day to read through it in an attempt to understand the process he was describing. In the end, none of us had fully grasped the process he was attempting to express. We ended up giving up on the experience and decided to meet with him to talk it through. After some discussion with him to get a clear picture of the task flow he intended, we charted out the same experience on a single page. We cut out about 80 percent of the text, and ended up with an easily understandable document weighing in at a fraction of the size it initially was.

Once the project stakeholders have seen our task flow diagram and agree that it is the model they wish to proceed with, it is time to move on to the wireframe stage.

A wireframe is the basic blueprint that illustrates the core form and function found on a single screen of your web page or application. The fidelity of these wireframes will increase in detail as we refine them. However, our first version is likely to just utilize basic black and white outlines and shapes to hint at where navigational elements, text, and graphics will be placed on the screen. The collection of these wireframes should give a comprehensive skeletal view of our entire product.

Here's an example of a first draft wireframe of a website home page:

As we can see by examining the preceding wireframe, the content of the page supports one primary task: to direct the user to find the product they would like to learn more about.

To support this task, we have created what we will call "access points" to the different products, shown here as images, headers, and links. However, we don't know what the text will say, what the navigation bar will contain, or what the graphics will look like. All of this requires more discussion and exploration, so we will just block out a space for it and move on.

This process can be much easier if we are redesigning an existing site or application because much of the content can usually be reused. However, if this is the first version of our product, we should not bother ourselves with too much detail to start with. Just imagine the type of content that will be required to support the tasks that need to appear on the page.

As we start to iterate progressive versions of these wireframes by defining and entering page content, the fidelity and detail of our wireframes will increase. As the wireframes progress, we will begin to see where we need to request or create content. We will also need to define and include the optimal navigation model and content taxonomies in our wireframe refinements.

Now would be the time to meet with the development team to explain the current project plan details and any special technical considerations or unusual features. At this point, we will need to figure out if we plan on having our site optimize it's layout for the specific device it is being viewed upon (desktop, tablet, phone, or other mobile devices). This is known as responsive design. It has become the standard method for creating websites. It means we are likely to define how our page content and layout will shift to display for each screen type.

The example website I have included in the following chapter is designed with the traditional desktop computer in mind. However, the rise of mobile device usage has many focusing their design efforts on a "mobile first" methodology. This means they start by creating a design optimized for a mobile device and then expand their designs for desktop optimization second. This method will only become more relevant as mobile device usage increases. Regardless of your choice of which to pursue first, you are likely to consider responsive design when designing your wireframes.

There has been much written on the topic of responsive design and a similar technique called adaptive design in the past few years. There are many online walkthroughs and video tutorials on the subject that can help you better understand the topic. A search for "responsive design techniques" should get you started on learning more.

Though often saved till after mockups have been generated, now is the time to start testing the usability of our designs. Whether we decide to test our efforts with paper prototypes (see Chapter 5, Information Architecture and Visual Design Techniques for more details) or something a bit more formal, it's important to vet our ideas while there is enough time to change them. If we wait to test our designs until after they have been fully fleshed out in mockup form or fully developed, there is often very little we can do to change core functionality.

Some commonly used, effective wireframing techniques are mentioned here (see Chapter 5, Information Architecture and Visual Design Techniques for more details):