Prototype design is a big problem that plagues many novice product managers. In fact, prototyping is not as difficult as imagined, practice makes perfect, just master the 8 golden rules.
Most of the mistakes I encounter, see, or hear are not because of choosing the wrong tools or methods. Most errors come from the following situations:
Excessive or insufficient prototyping.
Prototype the wrong thing.
No expectations are set for the prototype.
Effective prototyping is about finding balance and setting expectations. This article will reveal the eight guiding principles of effective prototyping that we have developed. These principles apply no matter what method or tool is used.
Whether you have extensive prototyping experience or just want to understand the following, you can benefit from the eight guiding principles.
Principle 1: Know your audience and intentions
This is the first step in the prototyping process. It is also the most crucial principle. Knowing the audience and understanding the intent of the prototype in order to make a prototype can drive all aspects of the prototype design process. After understanding the audience and intent, you can better complete the following tasks.
Determine what you need for prototyping.
Set appropriate expectations.
Determine the appropriate fidelity.
Choose the right tool.
Everything comes from the audience, so we start by solving the audience’s problem. Knowing who the audience is, you can determine what prototyping needs, how many prototypes are needed, and the appropriate level of fidelity.
If the audience is myself, another designer or engineer, a low-fidelity paper prototype, or emergency PowerbPint or HTML simulation may be enough. You can use these media to work and understand these media, they can also convey ideas without too much effort.
But if the audience is customers or senior managers, the prototype may need to be more refined. The sketch on the cocktail napkin may not work.
When considering the audience, you should consider which medium or fidelity they are suitable for. If they can understand the rough drawings on paper and you are confident that the sketches are sufficient to convey the concept to them, use this method. But if the audience does not understand the paper prototype, it is difficult for you to use the paper prototype to convey the concept to them. You should change to a different medium or fidelity.
After understanding the audience’s prototype intentions, the next step is to enter the planning stage and start to prototype.
Principle 2: Make a little planning-make prototypes
The software system is constantly changing rapidly. A little planning, and then prototype, start the work in an incremental and iterative manner, so as to adapt to the ever-changing environment.
The more work done in the planning phase, the better the work can be started. Of course, the returns will diminish, and common sense must be used to judge how much planning work needs to be done.
People often ask me: “How much planning work is needed before prototyping?” There are no magic numbers, but I will spend up to 70% of my design time on sketching before I start prototyping.
Why is it 70%? There are two main reasons. First of all, my goal is to get feedback from the audience, so the sooner I show the prototype to the audience, the faster I can get feedback. Secondly, prototyping is a good tool for walkthrough design. If 70% of the design concept can be drawn on paper, the rest of the work can be completed with a prototype.
Principle 3: Set expectations
Setting expectations is based on a psychological method called priming. If you motivate the audience, you can guide their attention and focus.
Set expectations in advance, and there will be no weird discussions about detailed interactions or features that have not yet been prototyped. Don’t say that this kind of discussion won’t happen, because it will definitely happen in the end. Set the right expectations at the beginning, and it will be easy later-although these things are not part of the prototype, they can be added to the next release.
Motivate the audience and set expectations, then take out a prototype and demonstrate it to them. Don’t be afraid to discuss 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 some things have not been fully drawn.
Principle 4: You can draw sketches
If I want to draw a super emergency sketch, and I am only interested in drawing the functional blocks on the screen, I will use a lower fidelity, and usually only use lines. If it is sketching on site with another designer or client, I will use the same approach.
If the actual order of the fields is critical and the order needs to be conveyed, I will use a slightly higher fidelity to either write out the labels or open the Illustrator software to draw them on the screen.
These decisions are often rooted in the first principle: understand the audience and intentions. If the audience is just me, the wireframe is enough, and no label is needed. If someone else wants to use the prototype, I usually spend a little more effort to write the label.
Remember, if you were able to paint as a child, you can also paint now. Your goal is not to illustrate the New Yorker, but to convey your ideas. After all, it’s just a prototype.
Principle 5: It is a prototype-not the Mona Lisa
The prototype is essentially an imperfect, abbreviated version of the final product. The prototype is not perfect. There is no need to be perfect. The original intention of the prototype is not to be perfect. In fact, a slightly rough prototype often gets better feedback.
If the prototype is not completed, it is easier for the tester to give feedback. Because they uhui feel that everything is certain, it is useless to say more.
It is true that in many cases more elaborate prototypes are required. A brief prototype at a business show may not be of much use. The CEO cannot describe the final product with a sketch or a black and white prototype version. Therefore, it is necessary to use common sense here to judge what level of refinement the prototype needs to achieve.
But I can tell you with confidence that in most cases, the prototype does not have to be the Mona Lisa-good enough is enough.
The goal now is not perfect-just a prototype. Spend the least time and energy to convey the core concept of the idea to the audience, this is the thing to do now. What is needed is proper fidelity. Don’t overdo it. Don’t be enough.
Principle 6: If you can’t make a prototype, use a fake one
If you don’t know how to write code, or you can’t write code, there are many ways to use fake ones.
Use a series of JPEG interfaces. Use Dreamweaver to create a picture map and link them together. Without writing a line of code, you can get feedback on whether the interaction and the process are reasonable.
Use Fireworks built-in functions to link pages and frames together, and then generate clickable HTML prototypes.
Use your favorite PDF generation tool or Adobe Acrobat to link the documents together, and you can get the same effect.
Use PowerPotint to link static interfaces together.
A series of HTML interfaces are used to simulate AJAX and other interactions.
There are many tools for making fake interactions, and you may have many kinds on hand. Just first motivate the audience, set their expectations, simulate what is described, and you can start.
Principle 7: Only prototype what you need
The prototypes built are part of the entire system. This is mostly the case. There is no need to build a real system to study design or feedback. In fact, building the entire system will lose the inherent advantages of rapid iteration.
If the ultimate goal is to use the prototype for testing, you may have to test five or six scenarios. At this point, you only need to build the required prototypes for these five or six scenarios.
What if the tester clicks on something that hasn’t been done on the prototype? The prototype is the prototype. The prototype is essentially incomplete. If the tester tries to click on a feature that has not yet been created, he can use this opportunity to explore what he expects from it.
Prototyping only what is needed can greatly reduce the investment in many aspects-cost, time and energy. In addition, it takes less time to prototype only what you need, so you can get feedback faster and move on to the next step. If the established prototype works, it can continue. If you don’t get feedback, the loss is not big, you can try other methods.
Principle 8: Reduce risks, start prototyping as soon as possible, and do prototypes often
We let these big companies start creating wireframes too late, developing things, and finding problems.
——Anders Ramsay
Prototype has many advantages, one of which is relatively low investment efficiency. Let’s take a look at two development models-one is the traditional waterfall method, and the other is the rapid iterative prototyping design.
The traditional waterfall method needs to plan the system features and functions before starting to develop. It often takes a planning cycle of six to nine months before the actual system development can begin.
If there is progress or there will be no major changes, this may not be a problem. But for the current Internet industry, nine months may be a lifetime—nine months is enough time to create, buy, sell, or destroy an entire company.
But suppose your entire industry is moving as slow as a snail. At this point you have made a lot of investment, it is almost impossible to change the direction, let alone feasible.
The waterfall model is very expensive. Usually, errors will be sent, and the repair cost is very high, even as high as 100%. . Therefore, these errors will remain in the system, and the end user must work hard to deal with these errors.
The other method takes a more agile approach. Solve a small piece of the problem at a time, and adopt an incremental and iterative evolutionary approach. Using this method through prototypes requires very little investment. Obviously, reducing investment will inevitably reduce risks.
This is where the prototype really shines. The investment is small, but the benefits are considerable. There are positive gains and there are negative gains. If the positive is the benefit, it is even better. If it is negative, the risk is greatly reduced, because in this process, the risk can be found in time and the error can be found quickly. The earlier errors are found in the development process, the easier it is to correct them and the lower the cost.
If you do prototypes as soon as possible and do prototypes often, the risk will be reduced, and a lot of troubles will be reduced, saving time, energy and costs.
Whether it is product design or prototyping, errors are inevitable in the process. Remember the above eight principles, you can easily reduce the probability of making mistakes.
