Marty Cagan on the significance and process of product exploration

Navigation is an indispensable part of web design, and it is a quick way for site visitors to get the content they need. Navigation allows the hierarchical structure of the site to be clearly displayed in a structured manner and to guide users to find and manage information effortlessly, to deliver effectively. At the same time, navigation is generally located in the upper part of the Web page, but also in the Visual center area. While maintaining its reasonable function, a good navigation design can often become the crowning touch of the whole web design!

A designer in the layout and overall planning Web page design, navigation is always an important element. We think, what form does the navigation show? Is it possible to maximize its ability to comb the structure of the Web site and deliver information effectively? Can you contrast and match the design style of the whole page? Is it possible to embellish and embody the characteristics of the website without affecting its functionality? is the ability to strive for excellence as a key to the entire web design? So let's share and analyze some of the navigational designs that make the designers think carefully.

The design of the navigation will be based on the site's basic categories, attributes and characteristics of the location. Here, I selected a number of systems, portals and other types, have clear features, user positioning, products and brand characteristics of the brand category, topic-type sites. For these sites, the design of navigation will break through our common horizontal long navigation or vertical navigation, will be more meaningful, fun and interesting, is to allow designers to enjoy the development of creative design and thinking of "a little meaning" of the navigation design!

The material class navigation, is touches the navigation, increases the navigation means the most commonly used design method. In the design of website with special orientation and user point, it is widely used by designers. This kind of quick, simple, effect direct design way, can quickly the product characteristic and the designer's ingenuity presents. and material class navigation design often can not break the basic form of navigation, can be very good to maintain the function of navigation, page layout of the neat feeling. Therefore, the characteristics of the product can be expressed flexibly in the structure and position of the fixed Web page prototype. Designers can carve the internal material, so as to create a different meaning of navigation, a small bright spot in the entire page.

How do you make a page look immersive and integrate into the world of the site's products? So it is necessary to let the user's visual experience really feel the existence of the product characteristics. At this time, a common inflexible navigation, far from meeting the design needs of the page. Even if the product picture is seductive, a cold navigation without the atmosphere, on the page not only let people disappointed more damage should have the atmosphere. Therefore, more and more design, so that navigation into a foil, enhance the web and product atmosphere of the exciting! Quasi-class navigation, like chameleons, in different positioning of the web design, capture and adapt to the characteristics of the environment, so as part of the environment. Quasi-class navigation, can be a drawer, can be cloth, can be trees, can be anything you can think of and creative out of things! Break all the established rules, do not have to be a long quartet, do not necessarily have to uniform layout, quasi-class navigation can be the designer's initiative to play to the extreme! Such navigation design, in the entire Web page can achieve another layer of functionality, that is, to help improve the product to the user's powerful visual awareness, and has not seen the details of its products, you will be able to feel ahead of what it is, what style, what kind of pursuit. Make navigation more than just navigation!

If you ask what navigation looks like, most people will immediately emerge with several basic shapes and styles, top bars, and side columns. Even if you are tall, fat, thin, and have different colors and materials, most of the navigation will not span the basic boundaries. So does navigation have to adhere to the shape of the "rule"? The answer must be denied. Although users are accustomed to the "rules" of navigation, but the alternative form of navigation design has undoubtedly given users a new perspective, the original navigation can also be "no rules and no distance"! So whether you can change the shape of navigation design, the answer is no, designers always have to remember the fundamental nature of navigation and use, so that navigation can never be separated from its design in the core role of the page. If you are a bold designer, and a new design concept and product appeal, then may wish to try to do a land adjustment, change the shape of the design navigation!

There are vigorous and resolute the navigation of the Thunder brother, there will be a low-key attention to harmonious navigation. In some web design, the guidance of demand will require the navigation to a certain degree of weakening, so as to highlight the main content of the product. So what should designers do about this part of the navigation design? Is it a simple list of words? Or do you leave the navigation in the corner? How can the weakened navigation still not lose the design sense, even can assist the main body content to highlight? This time, the navigation of the processing and design can more reflect a designer to macro overall situation control, as well as the details of the local control, so that local obedience to the whole, but not rough treatment, but exquisite is just right! Weakening does not require design, and harmony is not hidden and disappearing. Many excellent design works, in dealing with this kind of situation, usually the navigation and the main background of the Web page to be associated with the integration. From the color of the just, style feelings, background pictures of the association, wireframe and so on many aspects can be processed and designed. Let the navigation naturally present, as if as a part of the main body, and then back to the second, the more visual focus left to the main content. In order to maintain its function perfectly, but also with the overall page "harmony"!

Wen/Marty Cagan translation/Lin Ai, Wang Ye, Ji Xuan

Marty Cagan is a world renowned product management expert who served as vice president of Netscape and senior vice president of product management and design, ebay. This article is a review of his more than 20 years of experience in the management of software products, sharing the process and methods of exploring products.

Product Development Ningquewulan

Have you ever seen a situation like this? The development team has just finished the project at hand, but the product manager could not sit still if he thought the programmers were at ease. In order for them to start a new project right away, the product manager makes the product requirement document (PRD) for the new Project night and night for a crash. This kind of thing in the product team often staged, become the culprit of product failure.

The development team is like a "starving" baby, with a particularly large appetite, but can't tell which to eat or what to eat. As long as the product requirements of the document in place, regardless of the product good or bad, they non-stop to start a new round of product development. The consequences are conceivable.

Traced to this phenomenon is because the product development team programmers dowry, the company is not willing to see them idle, only "make the most of it", will let the company feel at ease. Can be smart and wrong, this short-sighted behavior, the failure of the product to bury the curse. This behavior also masks the real value of the development team. The development team is alienated by the company into the production code of the machine, rather than jointly explore and create a successful product of the "comrades."
Only developers who are responsible for software development clearly underestimate their value. The right thing to do is to define the basic product through product discovery, make sure the product is valuable, usable, and workable, and then give it to the programmer to develop it. The company that forces the development team to work at full capacity is clearly a problem with the management concept: the code is not equal to the product. Of course, this phenomenon and corporate culture are also off the relationship.

Admittedly, a good project manager can guarantee the delivery progress of the product. But it is not so blindly let project management in the company. A reasonable schedule and optimized allocation of resources do not mean that the product will succeed. In general, I would recommend that the project manager sit quietly in the "audience" during the product discovery phase, and then lead the team to develop the product when they are convinced that the product is worth developing. With this package, the results are good. But if the product exploration phase, the team lacks can unified the overall situation manager, this package plan does not apply (in the future article I discuss this phenomenon again).

What if the development team is idle and the new round of product discovery is not finished? Actually choose a lot.

lets the development team use the "margin (headroom)" To improve the software architecture. Let the development team begin to repair product defects and improve product performance. Involve the development team in product discovery activities.

The Product Manager reserves a task of one months for the development team. So even if the project at hand is stuck in the shell (such as the user's feedback is bad in the prototype test), your development team has something to do before you think of a new solution.

The development team has nothing to do and may be the result of a disproportionate imbalance between the developers and product managers and designers in the project team. If there are too many developers, the product design team will never be able to keep up with the progress, the development team is bound to "schedule" dissatisfaction.

Keep in mind that the Product manager's mission is to ensure that the team develops valuable products. It is also a waste to let development teams blindly develop unproven products.

Product Discovery Program

To keep programmers out of the way, product managers spend their time on product discovery in a hurry to write a product requirement document. But this kind of product exploration is worthless. Time is no more pressing, and it cannot be sacrificed to the key steps that create value. And some companies attach great importance to product exploration, but did not make a reasonable plan for the process, can not guarantee that every day is a diligent, natural can not quickly develop the basic products. So, precious time is wasted in vain.

Product exploration planning is detailed, depending on the company's cultural atmosphere and the ability of the product explorer. In many companies, especially in large companies, the team needs a product discovery plan, a clear idea of what the project must achieve, the resources it needs, and a rough schedule.

I will list the components of the common product Discovery program. But this is not a template, do not follow the contents of the text mechanically, do not need to do things. Each part of my list solves different problems, and you can choose the right exploration plan according to the problem you want to solve. As a product manager, you have to review the plan and make sure the team executes as planned.

Core Exploration Team: Identify project product managers, lead designers, and master programmers, and make sure that these people are on call during the exploration of the product. Explore the extended team: who will support this core team? Do you need visual designers? Do you need the help of a prototype designer? Do you need a usability test resource? Need a developer with specific development experience? Need a QA team to provide staff? Do you need support from the marketing department? Key participants: Who has the approval for this project (i.e. who has the "veto")? In addition, you can write a list of smart people you think will be able to give a unique insight into the project. Customer Development Plan: Does this project require a special user? Who is the lead person if needed? If not, which customers (users) would you ask to verify your product philosophy? Main risk: What are the main risks of this project? How will you solve these problems? User Research tools: Does this project need to create personas? Need to do site inspection and business analysis? User test Plan: How are you going to get the actual user to test the product? What is the preliminary test plan? Product Strategy (Vision): Do you need to consider the long-term development of the project area before making the project details? Product principle: Does the product's field need to be original some product principle? The extent to which documents are supported: The core team needs to agree on what additional documentation is required and how much needs to be done in this project, including user stories, use cases, test plans, and so on.

Planning is only one step in product development, and it is more important to ensure that product exploration is really to meet the basic requirements of the product direction. In addition, when you combine these two steps, it is critical when you can really start building your product. The supervisory work of this process consists of two parts.

First of all, I think that the person responsible for the product (such as Product Manager or Chief user experience) needs to be responsible for the activity, and their active supervision will play a positive role in defining the product. The point here is that "oversight" means asking questions at least once a week from the product discovery team.

How do you communicate with customers and users this week? What did you learn from your discussion? Is there anything that surprises you when you know them? What new insights do you have? Have you encountered a potential key point? "Note: See Http://www.svpg.com/your-business-plan-is-wrong" What new attempts will you make next time, based on what you know? When was the last time a developer evaluated product design and customer feedback? What are the comments and feedback from developers on project feasibility and possible solutions? Do users recognize the value of this idea? If not, then why don't they approve? What are the main usability problems of the current prototype? How are you going to correct these problems? From a feasibility perspective, what aspects of the prototype are the developers most concerned about? What contingency measures do you have to address these problems? Finally, what do you think is the likelihood of completing a product that meets the minimum requirements within two weeks? If there are difficulties, should the team continue to work or consider developing other products?

Secondly, the product manager also has the responsibility to supervise other affairs, such as in project management, need to ensure the implementation of the Product exploration plan, and do all the preparation work of the development. Specifically, this includes ensuring that the development team has sufficient resources to work, understand project time constraints and manage time, ensure good communication between developers, product managers, and designers, drive progress as a whole, and ensure that time in the project is effectively utilized.

The project manager can actually urge you to complete the project, but make sure you identify the basic product first, not just the development documentation.
Regardless of the implementation plan, if the company is open-minded and allows you to spend time exploring the product rather than just writing the requirements document, then I hope you don't waste every day of the product exploration. If you've spent a lot of time, but still feel it's hard to develop a good product, you should try to develop a product exploration plan.

Product Discovery Diary

Product managers and designers abandon the original linear, waterfall development process, in turn, I advocated this more iterative, exploratory process, usually take some time to adapt to its fast-paced, grasp the rhythm of product exploration.

This article will reproduce the product exploration scene and let everyone know its core content.

Because the product development process involves too many factors (such as product type, effort, etc.), it is not easy to generalize. I try to use more typical and popular scenarios. To cover as many points as possible, I conceived the following scenario.

First week

Monday

in order to clarify the business objectives, I worked with the project's leading stakeholders in the product opportunity Assessment and discussion. Start the first meeting with the project's lead designer and master programmer to develop product principles. Then we had a brainstorm and thought of a lot of good ideas. Work with the lead designer to create the first round of key personas.

Tuesday

and the lead designer continue to optimize the user roles completed the previous day, identify the primary and secondary roles, discuss the scenarios where the user uses the product, and list major and secondary scenarios. Work with user researcher to identify potential clients and select candidates through telephone contact with special customers. The lead designer quickly created a product prototype based on the results of the discussion.

Wednesday

me, the lead designer, and the main programmer together to check the prototype of the product that was completed the day before to see if it matches the few user stories we initially simulated. The discussion was so intense that the prototype was far more complicated than we had imagined. We look back at the product principles we've put forward, once again, with a clear focus, and then dramatically simplify the product prototypes.

Thursday

me, the designer and the project's main owner to view the product prototypes. This prototype is still in its infancy, but it already contains three of the most important usage scenarios. Through the discussion, we realized that we were somewhat disconnected from the idea of the project manager because the two sides had different understandings of the user. Continue to contact the target customer by phone, confirm 6 companies become our special customers. Best of all, they seem to have a great deal of interest in the problems our products will solve, because none of their companies have found a good solution. If our products can solve this problem, they will be very optimistic about our products.

Friday

We work with the main programmer to evaluate the modified prototype. He was cautiously optimistic about the viability of the main function and raised two important questions. First, the cost of developing one of these features can be quite high and slow to execute. He needs some time to study the problem. Second, he thinks we can save some data collection because the data we need can be extracted from the database. Consult the legal person and show him the prototype to ensure that the model does not conflict with the law. They think one of them needs a detailed evaluation and the results will be given next week.

Second week

Monday

In the morning, I, the lead designer and the project leader visited the first customer and asked four potential users to try out the prototype. The test was quite fruitful. Unfortunately, there is still a big gap between the performance of the prototype and our expectations. We found that our previous understanding of the user was superficial and the project manager's understanding was not entirely correct. Now we have a step-by-step understanding of the user, and reached a basic consensus. When we get back to the company, we immediately discuss how to modify the prototype. We simplify the scenarios that we think are important, modify the terminology, and eliminate the advanced features that are not used at all.

Tuesday

The main programmer, after studying the technical issues of high risk, was certain that his previous fears were justified. He proposed a new approach that would achieve the same effect and be less difficult to develop. So we adjusted the prototype according to his opinion. In addition, he confirmed that the data we were going to collect could be found in the database, further simplifying the prototype. In the afternoon we visited another customer and asked three users to participate in the test. The situation today is much better than yesterday. We are still unsure whether the prototype interaction design is good enough, but at least the user can do the main task. The move to get rid of advanced features is certainly right because users don't care about them. I am glad that we have adhered to the customer-centric values. There are two test users who want us to be notified of their product completion at the first time.

Wednesday

meets with the lead designer and the main programmer to discuss the current results and the rest of the work. The master programmer has also put forward an optimization proposal for key processes that just solves several thorny issues facing the chief designer. My chief designer and I presented our vision design ideas to visual designers. After previous user testing, we decided that the two basic concepts in the product must be communicated to the user in some way and given the critical state and the actions that the user might make. Visual designers say she already has ideas to express these concepts and improve the value of their products. She will give us some specific plans in the next day or two, and then we can make recommendations for them.

Thursday

We are still trying to define basic products. We believe that we have already covered the most critical features, but we are not sure if we want to add a cool feature to it. We plan to temporarily remove this feature from the model to see how the test works. In the afternoon, we visited another customer and asked three users to test the product prototype. The usability of the prototype has been great, but after removing the previously mentioned feature, the prototype did not get a warm response from the user. We showed the previous version, and this time they showed great enthusiasm. We have come to the conclusion that this function is indeed very important. Our prototypes have eliminated all the unwanted parts as much as possible, but they still inspire the desire to buy. We have removed many advanced features, simplifying key processes, and should be able to complete development tasks within the time the master programmer estimates.

Friday

I, the lead designer and the visual designer discussed her design, and we particularly liked one of the options. After a little adjustment, we used it on the prototype. The master programmer estimates the cycle of product development based on an existing (or possibly final) prototype. This time is acceptable, and the risky technical issues have been eliminated.

Third week

Monday

we will include the latest product prototypes to the project leader, and summarize the final product design (including the latest interface design) and all feedback from the test customers. She loved the product and wanted to sit on the afternoon test. She also wants to ask customers about prices and positioning. In the afternoon, I, the lead designer and the project leader came to see another customer with the final prototype. We asked the 4~5 user to test and get the ideal feedback-no problem with usage, good response to function and value. All users are looking forward to the advent of this product and are willing to recommend it to friends or colleagues.

Tuesday

continues to refine the prototype and will be aware of the key points these days into the project wiki. Presented product prototypes to more project participants, including legal advisors, marketing, product management and engineering VP. They have raised a number of questions, but have accepted the feedback of user testing.

Wednesday

me, the lead designer, and the main programmer to discuss how to write the product documentation to facilitate the work of developers, testers, and deployment personnel. I work with the chief designer to write the document, we wrote the respective parts to the project Vikiri, and added some links and comments to the product prototypes.

After reading the above diary, I hope you can clarify the following 10 points.

At the beginning of the project, make sure you have a clear understanding of the goal (product opportunity Assessment). Work closely with the lead designer and master programmer from the beginning of product discovery. Focus on real collaborative communication, not just writing about documents that nobody reads. Quickly integrate key product concepts into prototype production. Try to verify your assumptions about the product and don't talk about it as quickly as possible to determine which assumptions are correct and which are incorrect. Provide product prototypes to target customer testing as early as possible and identify problems early. Remember to determine the basic product. Product exploration goal: To determine the product is valuable, usable and feasible. In the process of product exploration and constantly maintain and related departments of information exchange, to show you constantly updated product prototypes, let them understand progress. Don't spend your time writing a document for a developer, until the product is OK.

Of course, the actual project doesn't have to be exactly the same as my description, and I want to convey the idea that it should not take two weeks to write the product documentation, and not three weeks to produce the initial product prototype before presenting the product concept to the real user.

Product exploration has a specific rhythm and discipline that is based on conceptual product design, prototyping, user testing, and, most importantly, iterative learning. If you haven't yet experienced the process of exploring products, then I hope this article will give you a general idea of what product discovery is, and how it differs from the way you start writing product documents directly.

Design is in constant progress, with the user experience, the development of user awareness, product demand diversity, the concept of continuous exploration and update, we believe that navigation design will have more possibilities! Perhaps the next new form of design will be born between you and me! More and more research and exploration on navigation design will bring new visual and use experience to users!

Source Address: http://www.programmer.com.cn/10290/