First: for Web developers like me, Flex is the first rapid application development system exclusively for the purpose of building Web applications, designed by engineers for engineers. And it’s a pretty nice and powerful IDE (Integrated Development Environment, making development easier). Basically it does for us what Microsoft’s VisualBasic 3.0 did in the world of desktop application development. I understand that some of you may argue that Microsoft’s VisualStudio .NET (and earlier its InterDev product) was the first. However, both of Microsoft’s products rely heavily on server-side logic, while Flex produces a self-sufficient application. Self-sufficient in the same sense a pure HTML page is, if you know what I mean. Flex alone is all you need to build modern, web applications. And last, but not least - heck! There finally is a debugger for client-side web application code!

Second, Flex is unusual in a way that it attracts people from two quite different camps - former Flash designers, animators, and Actionscript coders on one side, and the general coder crowd on the other side. Both camps find something useful in making the switch to Flex, which in my view is absolutely unprecedented since designers and coders usually are at odds with one another (case in point, designers often diminish the complexity of code as “SMOP”, Simple Matter of Programming, causing grimaces among the programmers). A somewhat amusing although not totally unexpected consequence of this: The Flex crowd today is basically two kinds of people, and you need both to complete a serious project.

The first kind of person you need is a Flex developer/architect - these are folks who used to code in every imaginable programming language before switching over. They are the people who know programming patterns, understand systems architecture, application tiers, data encapsulation, server-side interaction, blah blah blah. They engineer and code your application. The second kind is Flex developer/animator - these are the Flash folks. They are those people who make your application look “Flashy” - they create cool-looking user interfaces, transition effects, animation sequences and design new UI elements and widgets.

And finally, there is Flex as it relates to the entire line of evolution of programming for the Web. Flex technology, is yet another turn in the never-ending tango between text and binary applications. Here’s what I mean: remember how this all started ? HTML – plain, human readable text. Then we wanted some more interaction on our pages - Microsoft gave us ActiveX (binary). We decided it was against the spirit of sharing on the Web, yet we still wanted that interaction, so JavaScript and DHTML (plain text) was invented. Then we needed more complex Web applications, and Sun gave us Java applets (binary again). Tim Berners-Lee, the father of the World Wide Web came up with Curl – a plain-text based Rich Internet Application (RIA) system. Macromedia releases Flash (do I need to say it is binary?). For a couple years now, Web 2.0 and AJAX are taking over the world - RIAs delivered in plain text form. Well, not for long. Welcome Adobe Flex. The back and forth dance between open systems and proprietary ones continues!

Since nothing stands still, Microsoft is already pushing SilverLight - plain-text (XML-like) data executed by browser plug-in, producing a rich user experience on the client side.

The battle of plain-text versus binary is far from over. Stay tuned for more and visit again because my next blog post will discuss the who, what, when, where and why of Flex. Oh, and How.

Psychological detailing can just as easily apply to websites as well. Checking your web site regularly to find and tweak the various elements of the user interface and resolve other little problems that most people don’t really notice builds an overall sense of a quality web site that promotes repeat visitation. As people interact with the site more and more, they develop an impression that they have had an excellent customer experience — that this is a company that cares about its customers, even if they aren’t exactly sure why.

Iterative design through rapid prototyping can help to achieve this level of “psychological detailing” for your site. The rapid prototyping process consists of creating rough web site mock-ups for your customers’ approval. This helps to reduce the risk of later dissatisfaction, leads to less complex systems, and provides useful feedback and dialog about what your customers really need. With each subsequent prototype iteration, we uncover additional issues. Some of these issues might be considered major problems, but others exist at a purely subliminal level. Leaving them alone might not be immediately noticeable to the user, but fixing them helps to provide that perception of finely crafted detail that is indicative of a high quality product.

Step 2: Decide on the Web Site’s Up-Front Value Proposition and Other Key Elements

Up-Front Value Proposition
Up-Front Value Proposition is one of the most important patterns in this step. This pattern, basically, is the theme that unifies the site. The following figure gives examples of value propositions from existing web sites.

On your site’s home page and throughout the site, we emphasize your site’s value proposition. Doing so communicates the purpose of your site and presents a clear promise about what your site has to offer. Naviscent considers the home page to be the introduction and therefore an advertisement for your site. We understand that it must promise, and deliver, on the unique benefits that your site offers. It must grab your target customers in a way that will make them want to explore, use, possibly make purchases from, and visit again.

Our goal for your value proposition is to explain the web site’s value to someone in a single sentence. Everything on your web site pivots around this single idea; it is the unifying theme that ties your site together. This is why we work with you to think through your site’s value proposition carefully. We might make many drafts before deciding on the best one for your new web site. If you have an existing web site, you may want to reconsider your current value proposition. Our design team can help you with that, also.

Our experience has shown that the following are the concepts we need to present to your target customers:

• A persuasive promise for what your web site delivers
• A unique offering that only your company can provide
• Descriptive wording and images that your target customers can understand easily and quickly

The following figure illustrates how a clear value proposition results in a positive impression.

Site Branding
In addition to the value proposition, we include site branding to help build the identity of your web site. Naviscent believes that site branding is much more than just a logo or a tagline. It makes your target audience view your web site in a certain manner. For example, do you want your target customers to view your site as exciting and fun, or maybe as reliable and trustworthy? Site branding pattern exercises help you and Naviscent’s design team to decide what kind of impression you want to deliver to your target customers.

The brand that your company builds will depend on the audience that you want to reach, and the values that they deem important. Our experience and research has shown that your target customers will assess your web site based on the following five criteria.

1. Content of quality. Does the site provide what I want?
2. Ease of use. Can I find what I’m looking for in a simple and efficient manner?
3. Performance. Is the site fast, or is it slow and sluggish?
4. Satisfaction. Is my overall experience pleasant and satisfactory, or does it leave me feeling like I’ve wasted my time?
5. Brand value. Does the site provide something important and unique, or is it similar to hundreds of other web sites?

The following figure illustrates many of the factors that must intertwine to create a good branding statement.

Personalization
We also consider whether personalization is important to your site. This element tailors web pages to individuals or groups. For example, would showing a customer’s name on your web site be important to your target customers? How about your web site remembering a mailing address that your customer entered previously?

Internationalization
This element considers international target customers. Do you expect target customers from different countries to use your web site? If so, there are many issues you and the design team need to consider such as, currency, icons, layout, and color.

Discovery Deliverables
At the end of the Discovery phase, the Naviscent design team produces three documents: the customer analysis document, the business analysis document, and the specification document.

Customer Analysis Document
This document gives you and Naviscent’s design team a deeper understanding of your web site’s target customers. It describes the target customers, their characteristics, their needs and their tasks. We include the following details in this report:

• The target customers’ motivation to visit your web site. You and the design team must have a clear understanding of what motivates your target customers to visit your web site. This information is important because if the design team doesn’t offer a clear, persuasive description to your target customers about what you are offering on your web site, customers may leave your site before they even look at what you have to offer.
• A task analysis of the target customers. This analysis describes the people who will visit your site, the tasks they perform, the technologies they use, and their organizational issues.

Business Analysis Document
In this document, the Naviscent design team describes your business needs and the business goals of the web site. It explores how your goals tie in with your customers’ goals and tasks. For example, suppose that your intranet site is the primary source for company information and forms. What does this goal mean to an employee who is trying to find a company form to requisition office supplies required to do his or her job?

We usually include the following elements in the business analysis document.

• Business plan. The business plan describes your needs and the business goals of the web site. Some examples of goals might be to bring in new business by enabling purchases online at your new web site, or to bring in new customers by providing online information about your products and services.
• Competitive analysis. This analysis looks at your competitors’ web site features. We identify which features are important to target customers, and which are not. We also discuss the competitive advantages of your web site over similar web sites.
• Metrics for success. How will we measure success for both your business and your competitive goals? For example, how many customers does your site need to draw on a regular basis in order to stay in business? How many will be repeat customers? How many visitors will become paying customers?

Specification Document
We also refer to this document as the requirements document. This document identifies what the web site should provide to your target customers when the Naviscent design team is finished. It describes web site functionality and the system constraints. At this point, the design team does not concern itself with how they will achieve the functionality, but only on what they will accomplish. The specification document may contain the following elements.

Project description
This element of the document describes the common purpose and ultimate goals of the project, from both your perspective and your target audience’s perspective. The Naviscent design team gathered this information during step one of the Discovery phase.

List of tasks, scenarios, and storyboards
These three elements flesh out the features and tasks that your web site will offer, which the design team begins to develop during step one of this phase. The design team forms the basis for evaluations of your proposed web site on these elements, which we summarize for you here:

• Tasks are the specific goals that your target customer wants to accomplish on your web site, such as finding the best price for and then purchasing a particular product. The more complex your web site, the more tasks the Naviscent design team will need to develop. For example, a simple web site design may contain ten to twenty complete tasks, but a more complex web site will require many more. At this stage, we label each task as easy, moderate, or difficult to give you and the design team a better idea about the complexity of the design process.
• Scenarios are context-rich stories that the Naviscent design team develops about potential target customers—their characteristics, the tasks they need to accomplish, and the context of their use of your site. These stories focus more on what target customers will do on your site, rather than how they will do them at this point in the design process. The Naviscent team uses these scenarios to help them know and understand the type of target customers who might visit your site. This information helps the team to decide between different ways of carrying out a design. For example, during the design process, they may ask whether your target customers would order business gifts for colleagues from your site. If the answer is no, then the design team knows that offering this type of feature on your web site would be irrelevant.
• Storyboards are a sequence of web pages that the design team creates to give a general idea about how a target customer would complete a specific task. A storyboard can take many forms—the design team may sketch them from hand, or create them using software tools, and when appropriate to the project, the team may include photographs.

Comprehensive list of proposed features
This section lists all proposed features and sub-features, and classifies them in importance as “must have,” “should have,” or “could have.” To gather this information, the design team uses competitive comparisons of similar web sites, target customer surveys, and other market research techniques, such as focus groups. Each feature includes a description on how the design team will evaluation or test it in the final web site design.

Overall design goals
This section lists general design goals that the design team needs to incorporate into your final web site. These goals may include decreasing the time the it takes your target customers to make purchases and to check out from the shopping cart, reduce the number of mistakes your target customers make if you already have an existing site, or making the web site faster for your target customers to use.

Metrics
This section measures whether the design team has reached their specified goals and requirements, such as keeping download time to less than a specified number of seconds for the majority of your target customers. The design team discusses, in general terms, how they will measure each of the listed features in the final web site design.

With these three documents in hand, we can move forward into the next development phase: exploration, which will be the subject of our next entry.

1. Customer analysis document. This document describes your target customers and their needs – for example, the type of people you are targeting, tasks they will perform on your site, technology tools they have at their disposal, and social issues that drive your target customers’ decision making.
2. Business analysis document. This document describes the business goals of your project.
3. Specification document. This document describes the features that the completed web site provides for you.

We break down this Discovery process into two steps, resulting in the creation of the aforementioned three documents.

Step 1: Determine the Overall Goals of the Web Site
In Step 1, we start with a questionnaire that both you and the Naviscent design team work together to answer. This must be done before the design team can begin to create or redesign your web site.

In our questionnaire, we may include questions such as:

• What value do you, the client, expect to provide to your customers?
• What value will the web site provide for you?
• What do you expect to accomplish with your site?
• What role does the site play in relationship to the rest of your company?
• What is your goal—to sell products online, promote products, educate, inform, provoke, communicate, provide a community?
• How will this web site further your goals?
• What is the focus of your web site?
• What are your reasons for wanting to build a site?

With your assistance, the questionnaire helps the design team to define the site. Issues to resolve include focusing on goals, high-level services for the target customers, and preliminary categories. These decisions become the foundation for the rest of the Discovery process.

At this Discovery phase, we may apply a number of additional techniques, including, but not limited to the following.

We maintain an ongoing dialog with you, the customer, to clarify what you expect.

The Naviscent design team always bears in mind that they are not the customer. This may seem obvious, but some web development companies employ design teams that become so absorbed in the design process that they forget about your needs. We show caution to prevent this from happening. We understand that the design team cannot rely only on their experience and intuition when building your web site. Your conception is foremost in the minds of our design team so that the outcome of your web site will meet your experiences and expectations, not that of the team.

We help to determine your target customers’ needs with the use of interviews, online and offline surveys, and focus groups.

Interviews
During the interview process, we use our techniques to explain your web site’s objectives and then proceed to gather information from the interviewees about what tasks they would like to see at your web site and to explore how they would like to perform those tasks. We may show design scenarios to them to harvest their opinions about the conceptualizations. These interviews often provide us with a lot of useful information to present to you that may affect your web design concept.

We pride ourselves on using proven techniques for the interview process, such as:

• Conducting the interview in a place that avoids distractions. We discourage the use of mobile phones and other distractions that would take away from the intended focus of the interview, which is your web site.
• Starting the process with easy questions and steadily progressing to ones that are more difficult. We feel that this puts the interviewees more at ease with us and so are more likely to be frank and comfortable with speaking to us.
• Asking open-ended questions that avoid yes or no answers. We find that doing so encourages the interviewees to talk about their thoughts in reference to the web site.
• Treating the interviewee without judgment or confrontation. Our job is not to judge or confront the interviewees. We are trying to learn how to make your web site fit your target audience.
• Listening to what they say with very little interruption. We do not consider these interviews to be conversations, and so, as such, we let the interviewees do most of the talking. We make note of anything important and write down follow-up questions, interrupting only when we need to clarify a point or if the interviewees begin to digress.

Offline and Online Surveys
We can offer offline surveys, online surveys, or a combination of both, depending on your needs. Offline surveys usually consist of a combination of in-person surveys, mail surveys, and the use of a market research firm to ask survey questions over the phone. Although effective, these techniques can be expensive and can take longer to yield results than their online survey counterpart.

You have several options available to you for online surveys. If you are planning to update your web site, we can add an online survey to your site. Additionally, we can deliver web-based surveys via e-mail or randomly, in floating windows, to visitors to your site.

Online surveys can quickly give you feedback from current customers about what they like and don’t like about your current site. We use a combination of multiple-choice and free form questions. Each has their advantage. Multiple-choice questions enable us to analyze the data quickly and easily. They also help your customers to move through the survey faster, thus making it more likely for them to complete the survey. Free-form questions enable customers to expand on what is right (and wrong) about your site. However, too many of these types of questions tend to discourage customers from finishing the survey.

Focus Groups
We have found that focus groups can be a good source of information, but are difficult to run well. We keep the focus group to a handful of people – six to twelve – who are representative of your web site’s target customers.

Our moderator asks questions about both your competitors’ web sites and your proposed web site. Specifically, if we are revising your web site, we will ask the group to discuss what they like and dislike about your current site, and what they like and dislike about your competitors’ sites. If we are creating a new web site for you, we will ask them the same questions about your competitors’ sites and your proposed web site.

Before we approach the focus group, we determine the information we need to acquire from them. This helps our moderators to stay focused on the topics that are most important to the development of your web site.

Considering the nature of people in groups, we try to follow certain rules that we have found work best with regard to focus groups.

• The moderator must moderate himself. Moderators that are too controlling can drive to group to conclusions that he wants to see. Our moderators make a concerted effort to let the members of the group offer their opinions without letting their own be known.
• The moderator must make sure that no one person dominates the group. An issue that arises too often with focus groups is that one individual stands out to dominate the group and as a result causes groupthink to emerge – meaning that the other members of the group will defer to his or her way of thinking. Our moderators are experienced with running focus groups; they know how to gracefully quiet the dominating member, enabling them to receive quality information from all members of the group.
• We run more than one focus group. The results that we receive from focus groups sometimes depend on the chemistry of the group. Results can range from very positive to very negative. For this reason, we run more than one focus group, with different types of people. Doing so gives us more information to work with and balances out emotional responses.
• When we gather our focus groups, we try to avoid professional respondents – Professional respondents are people who make money by going from group to group. These people are not necessarily representative of the group of people we need for your focus groups. We do not look for people who happen to be conveniently available. We try to find people who are genuinely interested in your product, and so are potential customers.

We find that focus groups are more useful in the beginning stages of web design because although these groups give us insight into your target customers’ attitudes and perceptions, they don’t give us much insight into what those customers will actually do in practice.

In the event that the project involves redesigning your existing web site, we evaluate your existing web site, and review and evaluate competitors’ web sites, to help differentiate your site from theirs.

We recruit some representative customers and observe what they say they need to do on your web site and on competitors’ web sites, what they actually do, and what steps they take to do it. From this observation, we make note of the types of mistakes they make when they perform specific tasks. We note and pay particular attention to comments they make about what they like and dislike about your site and competitors’ sites. If helpful at this point, we will ask them to fill out a questionnaire that will give us information about their demographics, their interests, and their subjective ratings.

In our next entry, we will discuss the second step in the discovery phase.

Don’t expect the design process to always run as smoothly in your own development projects as it is described in the next few entries. The process sometimes repeats phases and jumps back and forth, depending on the requirements of the client. You might find that the process presented here is not all-inclusive for your design teams because it doesn’t resolve all of your issues. In this respect, you may have to tweak the process to fit the needs of your own teams.

We always consider the people with whom we are working. For example, formal procedures might be an absolute necessity for larger teams, but this might not be the case for smaller teams. E-commerce design teams and art-centered design teams may require different techniques altogether. This is why we suggest that, at minimum, you should include the first four phases of development in your design process.

Seven Phases

The development of a Web site is broken down into the following seven phases.

1. Discovery
2. Exploration
3. Refinement
4. Production
5. Implementation
6. Launch
7. Maintenance

The First Four Phases

We refer to the first four phases as the design process. This part of the process emphasizes the overall Web site design and specifies which tasks the customers can perform and how they perform them. During this design process, each of the steps moves the design closer and closer to a Web site that is tailored specifically to the client’s needs.

Our design team makes presentations to the client at each of these stages to obtain approval for the work they have performed. In addition to these presentations, we communicate with the client on a regular basis to ensure that the team is on the right track. Always bear in mind that there are several parties that have a stake in the design process, including the client and their intended customers. The client is in charge, and our design team considers their requirements on a regular basis.

The Last Three Phases

Our design team does not necessarily perform these last three phases. In some cases, the design team hands off all documentation and interactive prototypes to another team at this stage. This new team may be a part of the client’s organization or it might be an entirely different third-party firm, which the client has engaged to finish the remainder of the work.

Detailed planning is not included at this stage of the process. We have two reasons for this:

• Each organization has procedures for handling issues such as scheduling, budgeting, and risk management. This makes the client the best candidate for performing such tasks.
• The process in this final stage is not linear. For example, a team might be in the Production phase, and discover that it needs to perform more Refinement activities. Another team may be in the Exploration phase and discover that they need to revisit the Discovery phase to revamp documents they created during that phase. Going backwards might be frustrating and seem like a personal defeat, but we always bear in mind that we are saving time and money by making these changes now rather than at a later time.

We hope that this overview gives you a glimpse into the development process. Future entries will discuss each of these phases in more detail, starting with the Discovery phase.

Simply put, a pattern describes a problem that you might need to solve, in this case a web design problem, and then provides one or more possible solutions for it. However, the solutions that patterns provide are more conceptual than concrete; they provide ideas that you can use in your own ways, incorporating them into your own personalized designs. At Naviscent, we frequently use the same patterns to design web pages for different clients, but we use the patterns to solve the problems in different ways each time. The pattern does not provide a single solution, or a snippet of code, or a software recommendation. Instead, it offers a strategy for the resolution of the problem. Although we use the same patterns, the results are very different from each other.

You are probably already familiar with many of the design problems described by the patterns in Design of Sites, and some of the solutions, as well. For example, you’ve almost certainly used a sign-in process to log on to a web site, purchased a product using a shopping cart checkout, and clicked an action button. These are all design elements that are familiar to the average web user, and after a few experiences, you become accustomed to them, and expect them to look and behave in a certain way. The patterns that describe these elements present them in the form of problems, such as the following:

• How will users know that they are expected to supply a user name and password to gain access to the site?
• How should the site gather the information needed to complete an e-commerce transaction in a secure and methodical way?
• How will users know what screen elements to click and what the effect will be?

Creating Action Buttons

The pattern begins by stating the problem.

Let’s take for an example of a design pattern a screen element that all Internet users have seen and used many times: three-dimensional action buttons. The purpose of action buttons is to make something happen, such as add a product to the shopping cart. These 3-D buttons solve a common problem that you might not have considered to be a design element, but which web users encounter on sites every day: how do they know what screen elements they can click on? Web designers have traditionally based the design of action buttons on three-dimensional physical buttons that are already familiar to the users and which they already know how to use, like the following.

Figure 2-1

After describing the nature of the problem and providing some background, the pattern proceeds with details on various types of solutions.

Designers typically create the three-dimensional visual illusion of an action button through the use of shading and color. The action button color should differ sufficiently from the page’s background color so that customers can locate it without too much effort. This effect makes the action button stand out, so that it looks as though you can press it. The end result is a 3-D button that attracts more attention to the function than a simple text link can. Therefore, to add to the appeal of your site, and to compel your web visitors to perform a specific action, such as ordering a product, a three-dimensional image is preferable to a flat action button or a text link.

Figure 2-2

The pattern also discusses implementation issues that affect the problem and its solution, such as button placement and size, in this case.

Try to place the action button near the object to which it is associated. Traditionally, the best placement is either above or to the right of the object. This makes the button immediately visible to users without forcing them to scroll through the page looking for it. Here is an example of action button placement in Amazon.com’s quick-flow checkout page. Notice how the buttons are located mostly to the right of each object, and how you instinctively associate them with their functions.

Figure 2-9b

There are two types of action buttons: HTML action buttons, and graphical action buttons. Because HTML buttons are created by the client browser, based on text codes, you have little control over how they appear. An example of a gray 3-D HTML action button appears in the following figure.

Figure 2-3

The next figure uses Amazon.com as an example of a web site using graphical action buttons (Find Gifts and Web Search) on its homepage. Because they are graphics embedded in the page, the designer has full control over the appearance of this type of button. At Naviscent, we typically use graphical buttons when designing an interface, so we can gave each site a unique style that best suits the image the client wants to project.

Figure 2.5

Size is a further consideration for action buttons. You want to make sure that your buttons are not so small that users will overlook them, and no so large that they take up more room on the page than is necessary. Additionally, you might want to consider how using images as action buttons can affect the speed at which the page loads. In terms of file size, graphical buttons should be as small as possible, especially if your pages require a lot of them.

Using Patterns

The types of issues included in this discussion about action buttons are examples of the forces that you should consider when you use design patterns. Forces are the goals and constraints that come into play when you are attempting to solve a particular design problem.

This example includes all of the essential elements of a pattern. Each pattern in Design of Sites includes a discussion of the basic problem, an explanation of the forces that exert themselves on the design and general guidance on how to resolve the problem. Notice, however, that patterns do not include specifics on how to create action buttons. The book is about design in its purest form; it contains no code or specific techniques for creating graphics. It is up to you to decide what method, language, product, or technique you want to use to realize your action buttons. Design of Sites concentrates more on how they should look and how you should situate them on your web pages.

In future blog entries, we will discuss in greater detail how to use patterns and how patterns evolve over time.

>> Download Web 2.0 Design Patterns Presentation.

You will learn when new interaction capabilities make sense, and how they might apply to your situation. We encourage you to bring real life problems you face in your site designs so we can review them, and you can receive recommendations directly from Douglas.If you find your site suffering from complexity and poor usability, this introduction to Web 2.0 Design Patterns can help.

The show itself will be broadcast over the air on Saturday, January 6. I’d invite you to call in and heckle, but it’s not one of those audience participation-type shows.

(UPDATE: You can now listen to the recorded interview here.)

Maybe after the interview we can help Alan redesign his site.