Web Design Core issues 2:web design process (2)

web| Process | design | problems

Ways to 2.4 Web site projects

In theory, Web site engineering makes sense, but does it work in practice? The answer is completely effective. However, because the web is an emerging area, site development is rarely consistent, such as significant time constraints and the changing nature of the project. Developers should proceed with care. To guide development, a process model should be adopted at the beginning of a project. If the site is new or difficult to add, you should use a waterfall model or a modified waterfall model with a vortex. If the project is about maintenance, simpler and has many unknown factors, then the joint application development method is more appropriate. Regardless of the project itself, the first step is usually the same: that is to determine the overall goal of the project.

2.5 Goals and problems

Many sites fail because they lack clear goals. In the first few years of web development, many companies have created sites that are simple to show that the company has a site. Somehow, a company without a site would be seen as a lack of reform and not a market leader. A competitor with a site would be considered dangerous. Many times, the site is rarely profitable, and the reason for the construction is only to show the existence of the company. With the popularity of web sites, the reason for creating sites is becoming increasingly apparent. Today, the goal of the site becomes more important, and the way it is displayed is becoming clearer. However, it is not possible to assume that the idea dominates the site-many site project development is purely fun or because awareness is at risk, not to solve real problems. It is not difficult to propose a goal for a Web site; The problem is refining the target. Beware of such vague goals as "providing better services for users" or "making more money by developing online markets". These can serve as a reasonable idea or general goal for the project, but the objectives require a more detailed statement. A good goal statement may have the following elements:

• Establish a site that supports users by providing 24x7 response to user questions to improve customer satisfaction, thereby reducing the number of 2 5 of telephone technical support.
• Create an online auto parts store that sells 10,000 of dollars of components directly to users each month.
• Establish a Japanese restaurant site that informs users about time, menus, atmosphere, and prices to encourage users to book or visit the site by telephone. Keep in mind that of the three goals stated above, two are measurable. This makes it very easy to confirm the success and failure of the project when doing the actual budget. The statement of the third site target cannot be measured. This is risky because you cannot convince others that the site is successful or measure the site in some way. In a restaurant information site, it can be helpful to have a predetermined number of site visitors or to use coupons to measure the number of site visits. Consider the following revised objectives:
• Create a Japanese restaurant site that informs 3 0 0 potential users about time, menu, atmosphere, and price information each month to encourage users to book or visit the site by telephone. Simply adding a specific number of visitors will make the goal work. By providing an expected number of visitors, restaurant owners can compare the pros and cons of advertising and operating sites through print or radio at the same rate of efficiency surveys.

2.5.1 Group Discussion

In general, it is a very simple thing to propose a goal. The most important issue is to make the statement of the goal concise and realistic. In many Web projects, there is a tendency to embrace everything in the site. Remember that a site cannot meet all of the needs of all people, and must have specific users and specific tasks in mind. Collective discussion is necessary to set goals. The purpose of brainstorming is to present ideas about the site as much as possible. In brainstorming, a blackboard is very useful and can be used to quickly write down and revise ideas about the site.

Usually, a collective meeting is off, because the participants are too far away or discuss too many philosophical questions about the site. In this case, it is best to focus on issues of common interest. Determine the general design philosophy of the site by letting you discuss features that you don't want to see in your site. It is often easy for the participants to realize that they do not want the site to be too slow or difficult to use. Once the collective unity of the same goal, even if these are only some of the site should not be too slow view, the future of the discussion and about the site should do what the statement will be more smooth.

Note When you instruct a project to redo a site, be careful not to convene a group meeting to reprimand the problems that occur in the existing site unless the participants in the project have no relationship with the site. A foolproof way to prevent a project from straying is to let the original designer of the site defend the criticism it has suffered. Remember, people have to design a site, so it's important to organize an active design team.

2.5.2 narrow the target.

In a collective meeting, all the ideas are great. The main point of the meeting was to tap into the various ideas called "wish lists". A "wish list" is a document describing various ideas about the site that are not priced, feasible, and applicable. However, the final "wish list" will be narrowed down to a reasonable and appropriate part of the site. This is very challenging for sites with a variety of possible goals. For example, consider a company's site, including product information, investor information, press releases, job applications, and technical support. Every person responsible for the relevant part of the relationship will think that part of them is the most important. Everyone wants to put their part of the link body on the homepage. It is really difficult to weigh in so many scenarios.

Another way to narrow the target is to use small pieces of paper or 3x5 cards. Write every idea on a card and pile it up. Then let each individual draw one from the stack of cards, based on importance. Of course, be sure to limit the number of cards pulled from the stack. In this way, it is very promising to pick out important ideas. Unfortunately, depending on the collective, this operation is likely to fail-especially when participants play an important role in their respective fields.

2.6 Visitors

The best way to narrow your goals is to always consider your visitors. A collective meeting is not necessarily consistent with what the user wants. The first thing to do is to accurately describe the site's visitors and the reasons for visiting the site. However, don't look for someone named Joe Enduser on "AOL" or someone who accidentally uses a 5 6 K modem to access your site. For most sites, this type of user is not identifiable, and most users have a specific goal in mind. First consider what kind of people your users are and ask them the following questions:

Where are they? How old are they? What are their sex? What language do they speak? What are their technical proficiency levels? What kind of Internet access devices do they use? What kind of computer do they use? What kind of browsers might they use? Next, consider what users do when they visit the site: How do they access the site? What goals does the user want to achieve on the site? When do they visit the site? How long will they stay on the site? from which Web page do they exit the site? When will they return to the site, is it possible?

When you can describe the user's characteristics from the answers to these questions, you should be able to quickly determine that access to your site may not be just a single type of user with a single goal. For most sites, there are many types of users with different characteristics and goals for each type of user.

User characteristics

The best way to know your users is to talk to them. If possible, you should communicate directly with your users to verify assumptions about user characteristics and ideas. A survey may be appropriate, but on-site communication is more likely to provide the possibility of exploring beyond predetermined issues. Unfortunately, on-site communication or survey users are very time-consuming, and it is not possible to consider the user type of each feature or idea. From the user survey, on-site communication or general thinking about the user, you should build a comprehensive but detailed description of the user. Consider at least three different types of users. For most sites, these three categories of users roughly correspond to inexperienced users, users who have Web experience but do not visit the site frequently, and those who have the ability to visit the site frequently. Most sites have three categories of users, and the ability to moderate but infrequently visit the site is the largest group of users. Be sure to assign the right ratio to the appropriate type of user base to consider them in the right amount of weight. Now start naming your users. After each exchange of a real user, you may want to name him, or use the general name of a beginner named B o B, named Irene General user and named P a u l Super user. Then use the questions in the previous chapters to describe the general profiles of the various integrated users. Try to classify every single answer. In this way, if there are very few users with fast access devices, and most of the access devices are slow, we consider the latter as more general. The 3rd chapter will discuss the general user characteristics and personalized features in more detail.

Once you have completed a description of the characteristics of a generic site visitor, you should begin designing the access scenario. What does he do when he is a beginner of B O B to visit the site? What is the task he wants to accomplish? What is his goal? Program design helps you focus on the tasks that each user actually wants to accomplish. From this practice, you may find that your goal statement is inconsistent with what the user wants to do. If so, the design may still need to be repeated. Go back to your initial steps and revise your goals based on the new information.

2.7 demand

Depending on the site's target and the type of visitor, the site needs should be different. What type of content is required? What should the site look like? What kind of programs should be developed? How many servers should visitors need to meet? What are the limitations of the user in terms of bandwidth, screen size, browser, etc.? Wait a minute. The requirements will show the cost of the site and potential implementation issues. Requirements show how many developers are needed and show what is missing. If the requirements are too high relative to future returns, you should go back to the target phase and redefine the visitor type. The first three stages of a process may have to be repeated several times until a site plan or spec sheet is formed.

2.8 Site Planning

Once the goals, audiences, and site requirements are discussed and documented. A formal site plan should be drafted. Site planning should include the following sections:

1 short statement of objectives. You should include a brief discussion of the overall objectives of the site and a basic measure of the site's success.
2) Detailed objective discussion. You should discuss and provide measurable site goals in detail to verify the site's benefits.
3 User program discussion. Discusses user-wide access scenarios. Start with how the user accesses the site until the target is reached. This section includes a discussion of measures, such as the load, the number of pages per visit, the number of forms completed, and so on, as well as the content of detailed goal discussions.
4) content requirements. You should provide a list of text, images, and other media that you need in your site. A matrix that shows the content, form, existence, and potential owner and creator of a requirement is useful because the matrix shows what is important. The simple matrix is shown in table 2-1.
5) Technical requirements. Provides a review of the technologies used by the site, such as H T M L, J a V, c R I p T, c G I, J a V A, insert, and so on. Technical requirements should be directly related to the user's capabilities. More technical considerations can be found in Chapter 1th 3.

6) Appearance demand. The outline of the user interface design should be given. The relationship between the site and the existing promotional material should be given in detail, and the user's limitations in graphics and multimedia applications such as screen size, color depth, and bandwidth should be given. This section should also give details of the use of specific fonts and colors, but the details of the appearance of many sites should remain in the development process for determination.
7) Release requirements. Point out the release requirements, especially the host side considerations. This section should include how many users visit the site, how many pages a typical page consumes, and the size of the typical page. Even if those are just some ideas, it is possible to further brief the bandwidth requirements of the server and the publishing site.
8) Site Structure chart. This section should give a structure of the site or a flowchart detailing the different parts of the site. The appropriate headings and general ideas for each section should be given according to the various user scenarios analyzed in the previous section. The organization of each part of the site is also important and should always be refined. The selection of the site structure is discussed in chapter 4th, but in general, the site structure chart should resemble figure 2-4.
9) resources. The site should give a variety of resources that are needed at run time. Metrics can be expressed in a simple human-hour approach and should be related to four resources: content, technology, design, and management.
10) timetable. The progress of the project should be shown in conjunction with the typical waterfall model described in the previous section and the resources described previously.
11) Budget. The budget mainly depends on resource demand and release demand. However, market costs and content copyrights should also be included in the budget. The actual organization and content of site planning is decided by the designer. Remember, the goal of planning is to communicate the goals of the site among the various people involved in the project. Do not overlook the writing of site planning, although it is frustrating. Without this document, you can only develop projects in an evolutionary or j a D way. Further, you cannot obtain any realistic bids from an investor without a specification. However, a completed plan does not allow you to proceed immediately. Once the normative book is formed, it should be examined once. The completed specification may expose unrealistic estimates, allowing you to fall into the process of repeatedly modifying initial goals and defining visitor characteristics. If not, you can go further and begin the prototype design phase along the waterfall model.