8 Golden Laws of product prototype design

Prototype design, plagued many novice-level product managers of the long-standing. In fact, prototype design is not so difficult, practice makes perfect, Master 8 Golden Law can.

Most of the mistakes that I have encountered, seen, or heard by myself are not due to the wrong tools or methods chosen. Most errors come from the following:

Prototype design is excessive or not enough.

Prototype the wrong thing.

There is no expectation of the prototype.

An effective prototyping design is to find the balance and set expectations. This article will reveal the eight guiding principles we have developed for effective prototyping design, which apply regardless of the method or tool used.

Whether you have a rich prototyping experience or just want to know the following, you can benefit from eight guiding principles.

principle I: Understanding audiences and intentions

This is the first of the prototype design process. is also the most crucial principle. Understanding the audience and understanding the intent of the prototype for prototyping can drive all aspects of the prototype design process. After understanding the audience and intent, the following work can be done better.

Determine what the prototype design needs.

Set appropriate expectations.

Determine the appropriate fidelity.

Choose the right tool.

It all comes from the audience, so we start by solving the problem of the audience. Knowing who the audience is, you can determine what the prototype design needs, how many prototypes to design, and the appropriate fidelity.

If the audience is myself, another designer or engineer, a powerpint prototype, or an emergency or an HTML simulation may suffice. You can use these mediums to work and understand these mediums, and they can communicate ideas without spending too much effort.

But if the audience is a customer or a senior manager, the prototype may need to be more elaborate. A sketch on a cocktail napkin may be out of the blue.

When considering the audience, you should consider what kind of media or fidelity they are suitable for. If they can understand the rough picture on paper, you are confident that the sketch is enough to convey the concept to them. But if the audience does not understand the paper prototype, you can not use paper prototypes to convey concepts to them, you should change a medium or fidelity.

Understand the audience's prototype intent, then go into the planning phase and start prototyping.

Principle II: A little planning--a prototype

Software systems are changing rapidly. A little planning, and then prototype, in an incremental, iterative way to work, so that can adapt to the changing environment.

The more work you do in the planning phase, the better you can start your work. Of course, the return will be diminishing, and must use common sense to judge how much planning work needs to be done.

I'm often asked: "How much planning work is needed before prototyping?" There's no magic number, but I'm going to spend up to 70% of my design time on sketches before I start prototyping.

Why 70%? There are two main reasons. First of all, my goal is to get audience feedback, so the quicker you see the prototype for the audience, the quicker you get feedback. Second, prototyping is a good tool for the design of the search. If you can draw a 70% design concept on paper, the rest of the work can be done with prototypes.

Principle III: Set Expectations

Setting expectations is based on the psychological approach called excitation (priming). If you inspire the audience, you can guide their attention and focus.

By setting expectations ahead of time, there is no bizarre discussion of the detailed interaction or functionality that has not yet been done. Do not say that there will be no such discussion, for it will certainly come up at last. Setting the right expectations at the outset will be easy later-although these things are not part of the prototype, they can be added to the next release.

Inspire audiences and set expectations, and then come up with prototypes and show them. Don't be afraid to talk about what is not in the prototype at this time, but try to focus on what is already in the prototype. Remind the audience that this is just a prototype and tell them that something has not been fully painted.

principle Four: You can draw sketches

If I want to draw a super contingency sketch, and only interested in drawing a functional block on the screen, I will use lower fidelity, and usually only use lines. If you're sketching with another designer or client, I'll take the same approach.

If the actual order of the fields is critical and needs to be communicated in this order, I'll take a slightly higher fidelity, either write the label or open the illustrator software to draw them on the screen.

These decisions are often rooted in the first principle: Understanding audiences and intentions. If the audience is just me, wireframe is enough, do not need to use a label. If other people want to use prototypes, I usually spend a little more effort on the label.

Keep in mind that if you can draw in your child's time, you can paint as well. Your goal is not to draw illustrations for the New Yorker, but to convey your ideas. After all, it's just a prototype.

principle Five: prototype-not Mona Lisa

Prototypes are essentially imperfect, abbreviated versions of the final product of the city. The prototype is not perfect. There is no need to be perfect. The archetype is not meant to be perfect. In fact, slightly coarser prototypes tend to get better feedback.

If the prototype is not completed, it is easier for the tester to give feedback. Because they uhui that everything is OK.

Admittedly, more sophisticated prototypes are needed in many cases. It may be useless to have a brief prototype at a commercial exhibition. CEOs with sketches or Black-and-white prototypes cannot describe the final product. Therefore, it is necessary to use common sense to determine what kind of sophistication the prototype needs to achieve.

But I can tell you with confidence that in most cases the prototype doesn't have to be a Mona Lisa-enough good is enough.

The goal now is not perfect-it's just a prototype. Spend the least amount of time and energy communicating the core concepts of ideas to your audience, and that's the thing to do now. What is needed is the proper fidelity. Don't overdo it. Not enough.

Principle VI: If you can't make a prototype, use a fake

If you can't write code, or you can't write code, there are a number of ways to swap fake.

Use some of the column JPEG interfaces. Create picture maps with Dreamweaver they are linked together. Without having to write a line of code, you can get feedback about the interaction and whether the process is reasonable.

Use the fireworks built-in feature to link pages and frames together, and then generate clickable HTML prototypes.

Use your favorite PDF generation tool or Adobe Acrobat to link documents together to get the same effect.

Use Powerpotint to link the static interface together.

Simulate Ajax and other interactions with a series of HTML interfaces.

There are a lot of tools to make fake interactions, and you may have a lot of them on hand. Just start by stimulating the audience, setting their expectations, and simulating what the demo describes, and you can begin.

principle VII: Only make prototypes of what is needed

The prototypes are all part of the whole system, and most of them do not need to build a system to study design or feedback, and in fact, building the entire system loses the inherent advantage of fast iterations.

If the ultimate goal is to use prototypes for testing, you might want to test five or six scenarios. At this point, you only need to set up the required prototypes for these five or six scenarios.

What if the tester clicks on something that the prototype hasn't done yet? The prototype is the prototype. Prototypes are inherently incomplete. If the tester tries to click on a feature that has not yet been created, you can use the opportunity here to explore his expectations.

By prototyping only what you need, you can significantly reduce the amount of input-cost, time, and effort. In addition, it takes less time to prototype only what you need, so you can get feedback faster and take the next step. If the prototype is built to work, it can go on. If you don't get feedback, you lose a little, and you can try something else.

Principle VIII: Reduce risk, start prototyping early and often prototype

We let these big companies go too late to create wireframes, develop things, and find problems.

--anders Ramsay

The prototype has many advantages, one of which is low input efficiency. Let's take a look at two development models-one is the traditional waterfall method, the other is the fast iterative prototyping design.

The traditional waterfall method must first plan the system characteristic and the function, then starts to develop. It often takes 6-9 months for the planning cycle to begin the actual development of the system.

This may not be a problem if there is no significant change in progress. But for today's internet industry, nine months can be a lifetime – nine months to create, buy, sell or bring down the entire company.

But suppose your entire industry is moving at a snail's pace. At this point you have made a lot of effort to change direction is almost impossible, even more not.

The Waterfall method model is very expensive. Errors are usually sent, and repair costs are high, even to 100%. As a result, these errors are left on the system, and end users must try to deal with these errors.

Another approach is to take a more agile approach. Solve a small problem at once, and take incremental, iterative evolutionary approaches. This method is used in prototypes, with little input. Obviously, reducing the investment will certainly reduce the risk.

This is where the prototype really shines. The investment is small, but the income is considerable. Positive gains and negative benefits. If the positive is income, it is better. If it is negative, the risk is greatly reduced, as the risk can be discovered in time and the error can be detected quickly. The sooner an error is found in the development process, the easier it is to correct the error and the lower the cost.

If you make prototypes early and often make prototypes, the risk will be reduced, and you can save a lot of trouble and time, energy and expense.

Product design or prototype design, in the process, errors are unavoidable. With the above eight principles in mind, you can easily reduce the probability of making mistakes.

Article source: Webmaster's Home